Difference between revisions of "Advanced IC10 Programming"
From Unofficial Stationeers Wiki
(→Flow Control And Data Manipulation ==) |
(Somewhat advanced tips for developing code for the IC10) |
||
Line 27: | Line 27: | ||
You can combine this with a loop and indexing to run your function on multiple devices automatically. | You can combine this with a loop and indexing to run your function on multiple devices automatically. | ||
− | [[File:LoopingAlias.png|thumb|left]] | + | [[File:LoopingAlias.png|thumb|left]]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br> |
+ | |||
+ | = Device Manipulation = | ||
+ | |||
+ | == 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. | ||
+ | [[File:Busy.png|thumb|left]]<br><br><br><br><br><br> | ||
+ | '''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) |
Revision as of 13:52, 27 March 2019
Contents
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.
Functions
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:
If we hadn't used the stack, the jump at line 10 would take us to line 9 instead of 4.
Loops
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
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.
Redefining Aliases
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:
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.
Device Manipulation
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.
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)