Advanced IC10 Programming
From Unofficial Stationeers Wiki
Flow Control And Data Manipulation
NOTE: This level of coding is NOT needed to play the to game to it's full extent. it's aimed at people looking for custom, self-inspired challenges.
main: jal MyFunction j main MyFunction: ... j ra
A function is just a label we jump to, but using the -al version of branch instructions (jal, beqzal) as they store the return address into the special ra register. When calling a function from another function (or from itself), ra will be overwritten so we have to store it in the stack and take it out when the function completes:
main: jal _MyFunction j main _MyFunction: push ra jal _MySecondFunction pop ra j ra _MySecondFunction: ... j ra
If we hadn't used the stack, the jump at the end of _MyFunction would take us to the call of _MySecondFunction instead of the main section.
alias rIterator r0 main: move rIterator 0 Loop: ... add rIterator rIterator 1 bgt rIterator 3 Loop_End j Loop Loop_End: j main
The challenge with loops is to keep them clean. Relative jumps are a great way to save lines but they can quickly turn code messy and adding lines might break them if you overlook them. If code length is not an issue, stick to labels where possible.
Indexing With Relative Jump
alias rIndex r0 alias rTemp r1 alias rValue r2 main: move rIndex 1 mul rTemp rIndex 2 add rTemp rTemp 1 jr rTemp move rValue 123 #Index 0 j Select_end move rValue 456 #Index 1 j Select_end move rValue 789 #Index 2 j Select_end ... Select_end: j main
Use this to set one or more parameters or call functions using an index number you calculated (or read from a dial button). We multiply it by 2 because we need space for a jump after each move command so we don't run the subsequent ones and we add 1 because for a 0 index "jr 0" would lock up our IC.
Say you have a complex function that manipulates a device (reads/writes multiple parameters, controls timing etc) and you want to reuse it for multiple devices. You could copy paste the whole function, or you could redefine the alias you used and point it to another device, like this:
main: alias dCurrent d0 jal _MyFunction alias dCurrent d1 jal _MyFunction j main
NOTE: This wouldn't work in real languages since aliases and defines are just directives for the (pre)compiler, they're not evaluated during runtime by the CPU
You can combine this with a loop and indexing to run your function on multiple devices automatically.
alias rIterator r0 alias rTemp r1 main: move rIterator 0 Loop: jal _UpdateReference jal _FunctionForDevice add rIterator rIterator 1 bgt rIterator 3 Loop_End j Loop Loop_End: j main _UpdateReference: mul rTemp rIterator 2 add rTemp rTemp 1 jr rTemp alias dCurrentDevice d0 #Index 0 j Select_end alias dCurrentDevice d1 #Index 1 j Select_end alias dCurrentDevice d2 #Index 2 j Select_end alias dCurrentDevice d3 #Index 3 j Select_end Select_end: j ra _FunctionForDevice: #Manipulate dCurrentDevice j ra
Timing And Parameters
Some devices don't react well to having parameters changed while they're performing an action such as import or export. Notable mentions are the stacker, sorter and the vending machine. You can avoid them locking up (or getting jammed with items) either by adding delays (yield, sleep) or by actively waiting for their slots to become unoccupied, or their Activation to become 0.
WaitForDevices: yield ls rBusy dSorter 0 Occupied bgtz rBusy WaitForDevices ls rBusy dSorter 1 Occupied bgtz rBusy WaitForDevices ls rBusy dSorter 2 Occupied bgtz rBusy WaitForDevices ls rBusy dVender 0 Occupied bgtz rBusy WaitForDevices ls rBusy dVender 1 Occupied bgtz rBusy WaitForDevices j ra
NOTE: The slot reader labels slots from 1 but in the IC they start at 0. It is also a good idea to check any device involved in your solution with both a logical and slot reader as the current databases may not list all existing slots or parameters. You should always make use of all data available from devices as they may greatly simplify your project.
Using delays is convenient, but has downsides. You're giving up real-time control over the process and may miss certain events or react too late and cause a device to jam. You also need to consider that code takes time to run, and for example if you have a complicated condition for setting the output of a sorter depending on the item that entered it, it may be better to leave it OFF by default and only turn it on once the output is correctly set. (Devices react differently to being fed items while powered down. ie the stacker will keep it in the Import slot but the vending machine will completely import it, so make sure to manually test everything you can prior to automating it)