You need a term in order to start exercising your decking skills. The primary skills for decking are: Programming, Systems, and Cracking and these skills all rely heavily on your INT stat. A good term will add positive modifiers to any decking skill rolls, a cheap term will not add modifiers.
We use the terminology 'deck' and 'term' interchangeably. Both are acceptable for IC usage.
SCAN WITH TERM
There are three types of things you can scan. Objects, exits, and rooms.
Rooms are scanned in order to generate a geocoded location id that can be used in a program.
You scan a room with 'scan here with term'
Note: You cannot scan dynamic rooms because those don't continue to exist when you are not in them. This includes badlands rooms, and market mazes and things like that.
You can scan devices/exits in order to identify their grid id so that you can use them in programs (or in some cases, on nodes). A device must be networked to the grid in order to scan it. This currently includes: - Security Network Devices (cameras, mics, other sensors, hubs) - Price boards (cybernetics, auto parts, etc) - Some terminals (like the city services terminal) - Some exits (like apartment doors) - Other interesting devices you might encounter
Note: Exits you scan (doors) are treated as devices. Like a Smart Door that is networked to the grid.
Note: No actual decking skills are required to geolocate or scan objects. This is purposeful, so that deckers can hire others to do the sometimes dangerous work of geocoding locations and identifying network devices.
Note: This data is term specific in both cases. It is NOT attached to a grid account.
PROGRAMMING
Programs are written in Brlang (pronounced bur-lang). If you want to develop a program you will have to write commands in Brlang. This is a simple scripting language. There are plenty of examples of how it works available on the Grid.
* Programs can be developed on a term * Terms can store a limited number of programs (depends on term) * Programs are made up of commands, the # of commands you can add to a program is dependent on your programming skill * Programs are parsed after creation and will return any errors or issues * If a program parses correctly it can be compiled * Each command that makes up a program has a complexity score * A program has a complexity score based on the commands used, higher complexity programs take longer to compile * Compiling a program takes time (dependent on skill + term & program complexity) * When a program is compiled it can be run * Anything the program does uses the skills of the programmer that wrote it, and not the skills of the person running it * Programs have a limited # of uses (dependent on skill of programmer) * Running a program consumes a use of it, even if the program fails during runtime * Most programs require the term be logged into an account in order to work
PROGRAMMING COMMANDS
The higher the programming skill, the most complex commands become available.
ERRORS WITH COMPILING AND RUNNING
Please note that when compiling a program any empty lines in between commands are removed. If you get an error, the line number may not match your local source code if you have empty lines in between commands.
EXECUTING PROGRAMS & GRID HEAT
When you execute a program you may generate grid heat. Grid heat is typically only generated when you are executing commands that would be considered illegal, invasive or otherwise suspect. The higher your terms grid heat, the more likely your actions are to be noticed, or even cause an automated system response.
ACCESSING DEVICES / AREAS & IMPACTING THE WORLD
In most cases, getting access to a device is a matter of getting physical access to it in order to scan it. There are ways to find a devices Grid ID and get it loaded into your term without scanning it, but those are much common. For example, certain actions taken on a term (like cracking a node) will add the term that did the cracking to the known devices of the node's owner, if they are logged into their grid account. Or, attempting to crack the ice on a term will also add that term to the known devices of the victim. Similarly, there are ways a decker can crack a terms ICE and remove their term from the known devices list to prevent discovery / retaliation.
In terms of ICE and device protections, most devices are accessible to anyone with the skills to code a program that will access them, and the devices Grid ID. The limiting factor is the effort that went into creating the program, the limitations on a term for how many programs it can hold, the compile time of the program (minutes to days, depending), and the Grid Heat generated by the program executing commands. Excessive Grid Heat will lead to consequences that limit the ability to continue to run programs (find out more ICly). Grid Heat is reduced automatically based on the Cracking skill of the program developer.
The reason we use Grid Heat, instead of allowing ICE that protects every individual device is a matter of fun and impact on the world. Almost every command available via devices or areas is temporary or informational. Temporarily disable a camera, temporarily create or remove a SIC deadzone, gather information on a SIC id, etc. Putting these commands behind restrictions that require a decker to also break the ICE on a device is an extra step that will make decking both less useful and less fun.
Note: You can see your terms Grid ID by typing 'g' while using your term. Your term is ALWAYS aware of its own Grid ID, and can use it in programs run on the term.
ICE & ICE RECOVERY
ICE protects some devices (terms for example) and nodes. See the Brlang documentation on the Grid for more information on how to probe, install, and crack ICE.
Some devices & rodes that have ICE, also have a baseline amount that they will recover to if they are attacked. ICE recovers at different rates for devices and nodes. If a device supports ICE, it will have a probe command that will allow you to check the ICE, and when the next ICE recovery will run (this is a global thing that happens at a set cadence for devices, and there is another global process that runs for node ICE recovery).
ICE is recovered over time in an automatic fashion, up to the minimum, and then it stops. However, better ICE can be installed. If that ICE is whittled down, it can be replaced, but it will only ever automatically recover to the BASE LINE for the device or node. There is no way to increase the base line. However, the better the term you have, the better its base ICE will be.
Not all devices that CAN have ICE (such as security cameras and equipment) will recover ICE automatically. At the time of this writing, only terms and nodes recover ICE automatically. If you secure something without an ACL (Access Control List), everyone, including you, loses the ability to execute grid commands on that device while the ICE is intact. This doesn't prevent the camera, for example, from functioning with its hub, it means no decker can execute a program to do things to that camera, including you.
When you are launching an attack, it is a good idea to understand when the next ICE refresh will be (using probe) so that you can time it correctly. It would suck to whittle down a device's ice only to have it recover on you a minute later, limiting your access.
SCHEDULED PROGRAMS
If you schedule a program, when it runs, the term must be connected to the grid (relevant for QTs mostly). If it is not, then it will fail to execute. However, you need to keep in mind if you go @OOC with your term, any scheduled programs WILL FAIL TO RUN if you have a QT (as there will be no sicnal). For other terms, they will still execute.
DAEMONS
Daemons are long running programs that can be developed on your term. They monitor things for you, and let you know if actions are taken against the devices they are monitoring.
Daemons are developed using the systems skill. More information on developing them can be found on the grid nodes 'BrlangDaemons' and 'BrlangDaemonCreation'.
OOC & DECKING
Due to the nature of terms, if you are OOC with your term, your term is technically still vulnerable to being attacked. We may change this in the future, but for now, your term is vulnerable even if you are OOC with it.
DOING ILLEGAL STUFF
The IC documentation on Brlang mentions that it is illegal (ICly) to do certain things. DO NOT LET THIS STOP YOU. Of course doing crazy decking stuff is illegal in the game world. Please do not read the IC documentation saying it is illegal as the staff OOCly saying it should not be done. It should! We want you to decker-out and have fun. Just be ware that your IC actions can have IC consequences! Cover your tracks as best you can :)
LEARN MORE
To learn more, please do so ICly by heading to the Brlang node on the Grid. On there you will find a detailed programming guide which will teach you everything you need to know.
SEE ALSO:
help grid node 'NodeEditing' node 'BrlangIntro' thread http://sindo.me/SJVlY_Lwxg thread http://sindo.me/HJlVlK_Uwxg *Last Updated: 08/30/25 by Specter*
