Hello reader. This section is cute, but I will delete it later. Basically, in the "Biggest Update Ever," Rocketwerkz threw in some huge changes to core logic just because why not. It will take me some time to incorporate all these changes into the guide, plus I thought it would be handy to just have all the new information in one section for a while for returning players.

The biggest change is that ld and sd are no more. Instead, s and l now work with device addresses automatically. Pretty swag tbh

Remember how we can branch depending on if a device is connected or not with bdns? Well, now we can branch depending on whether or not a certain LogicType is associated with the device with bdnvs and bdnvl.

Linear interpolation is now a one-liner with lerp, and it is now more efficient to pack data into a register with ext and ins.

You can throw away your PID control script now, since there is a dedicated PID chip with parameters that can be tweaked right on the housing.

There are strings now. So if you wanna throw text on an IC housing:

If you've written a script or two, it may be wise to skip this section--we're just gonna control a light with a switch.
But otherwise, let's begin:

At the end of the day, everything a computer does can be reduced to a function of some numbers; but, we can substitute those numbers for names to create assembly code, which is what we use in Stationeers. So, anything our machinery is doing is a function of some named numbers.

Some of these named numbers are LogicTypes (i.e. On, Setting, Activate). When writing a script, we are trying to use numbers from various devices to change the numbers associated with other devices. The better you understand how these LogicTypes relate to the functionality of each device, the better your scripts will be! For starters, try learning the units associated with certain LogicTypes, like kPa for Pressure or kelvin for Temperature.

To access the LogicTypes, we need to communicate with some devices. The simplest way to communicate with any device in Stationeers is to link the device to the housing using a screwdriver. Each housing has six slots: d0 through d5. There is also db, or the housing itself. You can also use the device's reference ID, but this will be discussed much later.

Besides communicating with a device, we also have to store values in variables to change them. To name our devices and variables, we use the alias instruction. This isn't required, but good names make writing code easier. There are only 16 numeric registers for variables (r0-r15), so use them wisely.

The first thing we need for controlling the light is to get the state of the switch. To read a value from a device, we use the load instruction:

If the switch is off, we want the light to be off. This means that we want the Setting of the switch to correspond directly to On for the light. To write a value, we use the store instruction:

Now, we just need to make those two instructions loop forever and our light control script will be done. To jump around to different lines, we can use the j instruction. We can give it a line number, but if we ever change the script, it might change the line number we have to use. Instead, we can create a label to dynamically store important line numbers. So our basic, infinite loop looks like:

The script above will work, but as of right now it runs 31 extra times per tick. A tick in Stationeers is half a second, and ticks are what the game engine uses to synchronize all the logic and physics systems. What this really means is that a device will only change up to twice per second. We can stop and wait until the next tick starts with the yield instruction. To wait even longer, we could use sleep. Or you can just wait for the script to complete 128 lines.

Putting that all together:

I haven't seen many bases with just one wall light, so I assume you have more than one to control as well.

To communicate with many devices of one type at once, we can use the batch and batch name instructions. We can load the switch's Setting just like before, but things get more complicated with all these new lights. The store batch instructions take the form:

To get the prefabHash and nameHash, we can use the HASH macro. This is a function which turns names into numbers. To get the prefabHash, just HASH the PrefabName (which can be found in the stationpedia). The nameHash is just the HASH of the name. So, if we have default wall lights and long wall lights, all named 'autolight' with a labeler, we can control everything with the following definitions:
Note that when we define something we cannot change it. lightName is not a variable in a register, it is a permanent value that is simply substituted everywhere that lightName occurs in the script.

Now, lets make the logic of the On state more complicated. Lets say we want the lights to be on if the switch is set to on, or if a player is detected by an occupancy sensor. This way, we can leave the lights on when we go mine at night, so the monsters can't get under our bed:

To accomplish all this, we'll need to add a device to the script, a new variable, and for consistency, we'll change the name of the existing variable. Putting it all together, we get:
We could even switch the or instruction for an xor (exclusive or), which would allow us to turn the lights off even while a player is in the base by turning the switch on. Then, the lights will turn back on when the player exits the base:
To better predict the behavior of logical statements like or, consider looking up the truth table for the operation.

Load batch instructions are slightly more complicated, as they possess an additional parameter, the BatchMode:
A register can only contain one value, yet we are loading many values at once with a batch load instruction, right? Well, the BatchMode tells the computer how to put all those values together. There are four batch modes:

• Average
  
• Sum
  
• Minimum
  
• Maximum

Let's flip things around and control a single light with a bunch of batteries to demonstrate the load batch instruction. This script will turn a warning light On if the Average Charge of all our batteries is less than 20%:

Let's briefly discuss device slots.

Besides having merely having some LogicTypes, a device may have Slots which in turn have LogicSlotTypes. For example, a hydroponics tray has a plant slot and a fertilizer slot. Stackers have an input slot, an output slot, and an internal slot. A water bottle filler has two bottle slots. To read and write to slots, use:

For the coming water bottle filler script, you will need to understand the jal instruction. The jal instruction is part of the -al family of instructions. All of these instructions save the next line number to a special register, ra. In effect, we can create functions:

Sometimes, we only want to jump if a certain condition is met. A conditional jump is called a branch and there are many branching instructions. Here are a few:

Lets say we want to automatically turn a water bottle filler on only when it has at least one bottle which needs filling. We can use Occupied and Quantity from each slot to see if a bottle is present and full:
Well that works, and it demonstrates functions and branches like I wanted, but we can actually make it simpler just by using basic arithmetic. We just need to calculate how much water can be stored and compare it to how much really is stored:
The water bottle filler uses a very small amount of power, so this really isn't particularly useful unless you have space in another, more important script that can also contain this logic. However, the hydroponics station may be automated to turn the growlight off if there are no plants in any of the slots. But be careful not to check the fertilizer slots! This is left as an exercise to the reader.

My computer has spinny rainbow lights, and I like that, so let's put up some spinny rainbow LED's in our space station. I'm going to do this the wrong way first to demonstrate device indexing, then we can see a better way to do it using the stack.

Using the alias'ed name of our device is what we should do 99% of the time, but sometimes you just want d0, or d3, or dX. Is there any way we can say dX in code? Yes! Simply define the device of a register. For example:
We can even do this with registers, and we can do it recursively too!

So let's start with just 4 lights. We want 1 light to be lit at a time, and we want the light to loop around from d3 to d0. We'll need to remember 3 values: the index of the device we are handling, the index of the led we want to be lit next, and finally, we need to remember that there are 4 lights in total, so we can terminate the loop properly:

I did specify rainbow lights and those don't quite cut it. We need to write a different value for Color to each of the LEDs. We could check the Stationpedia to find the right number for the color we want, but we can actually program with an existing Color enumeration:
Using the existing enums can make your code more flexible and easier to read.

Instead of communicating with devices using d0, d1... we can use the reference ID of a device to communicate directly with as many devices as we can fit into the script.
That first value shown with a $ is the hexadecimal representation. This is the one I tend to use, as it is often shorter, since hexadecimal is more information dense. Or you can use the decimal one, it doesn't really matter--its all converted to binary at the end of the day anyway.

The stack is the closest thing you have to an array in basic assembly. The script will start execution with an empty stack, and with the stack pointer sp=0.
We can push an item onto the stack, which will increase sp by 1, or we can pop an item from the stack, which will decrease sp by 1. Do note that pop won't actually delete the value at sp.
Also, if we change sp, then push and pop will exchange with that new position on the stack.

If you want to reduce the line count of your script for whatever reason, you should start using relative jumps to avoid wasting lines on Labels. That will look something like:

Now, let's put that all together to build a stack-based LED controller. Well, without the color enumeration. Because the stack size is variable, it makes sense to treat Color like a normal number so we can iterate through them:

These are advanced, tangential topics.

Sometimes, you may want a device in a script to be optional. For instance, maybe a warning light really isn't required, it's just nice to have. We can do something like skip enabling a device by using bdns or bdse, or we can create logic around a device with sdns or sdse. For example,

Like every other register, the address register, ra, can only hold one value, which means the following code will NOT work as you might expect, and it will never go to SomethingElse:
There are several ways we can handle this limitation. If you're not using the stack for anything else, we can keep pushing ra onto the stack every time we nest, then popping it every time we need to return from the previous address. This example WILL work as expected:
If the stack is occupied, you can simply select some other register to hold the value of ra, and then you move the value of that register back into ra:

Some tasks are so complex that they may require several scripts, spread across several housings, all working together. For example, a recipe chip for a furnace build could request an ore by using the Setting of another IC housing that is responsible for fetching ores. So the recipe chip may contain the following lines:
While the vendor chip may consume the Setting as such:

In the previous section, we used the value of Setting to communicate one value between two chips. We can use the Channel data of any device to communicate and store many values at once.

Referring back to the previous example, lets change it to use Channel data so we can write an ore AND an amount of ore:
And then the vendor chip would load these values like:
Keep in mind that Channel data is stored in the cable network, so if you make any changes to that cable network, any Channel data you wrote will be set to NaN (short for Not a Number, which is secretly just another number).

I lied, we actually can store multiple separate numbers with just a single register. For example, 1,607 is one-thousand-six-hundred-seven, but if we bisect the digits, we can get 16 and 07. A binary digit is a bit (0 or 1), and many bits make up the complete binary number. We can shift these bits left or right to manipulate the digits of a register, effectively fitting multiple numbers into a single, larger number. Also, this snippet is outdated. See "UPDATE STUFF" above.
I hope some of the applications of bit-shifting are obvious in light of the prior section, but the next section covers how to pack a binary number in greater detail for stack instructions.

IC housings are not the only devices which have a stack memory. Fabricators, like the autolathe, and logic sorters also have a stack memory. To interact with a stack outside of the one for the IC, we need to use the get and put instructions. But we can also use get and put on db to manage stack memory without pushing or popping from sp.
We can also clear the stack with clr:
As a quick example, lets write a non-looping block of logic to set a logic sorter to blacklist ice, so it will filter everything else away:
To assemble an instruction, you will need to know where to place what information. All the stack instructions for a device can be found in its Stationpedia page:

*relative branch/jump instructions (i.e. jr, breq,brdns), jump return instructions (i.e. jal, bapzal, bneal), and all zero (-z-) instructions except beqz have been omitted for brevity
**the extent to which a is approximately equal or not equal to b is defined by c. See the Stationpedia entry for the full definition of bap and bna along with the associated s-, -r-, -z-, and -al instructions.

*all zero instructions (-z) except seqz have been omitted.

That's it I think. For more code examples, go here. If you still suck at surviving, go here.