diff --git a/auto_item_sorter.ic10 b/auto_item_sorter.ic10 index 76821b6..2d47c4f 100644 --- a/auto_item_sorter.ic10 +++ b/auto_item_sorter.ic10 @@ -1,3 +1,8 @@ +# Controls Sorters to sort items based on hash. +# Reads item-hashes from stack to decide if it +# should be split off or passed on. +# Connect one Sorter to each screw on the IC. + alias counter r0 move counter 0 @@ -8,6 +13,7 @@ alias IsItem r4 define INPUTSLOT 0 +# Replace hashes below with the ones you need. push 1724793494 # Coal push -983091249 # Cobalt push -707307845 # Copper @@ -20,12 +26,15 @@ push -190236170 # Lead #push -1516581844 # Uranium start: +# Loops over screws to instruct attached Sorters, +# loops over all sorters every tick. bdseal dr0 sort add counter counter 1 bgt counter 5 reset j start sort: +# Compares Sorter input-slot with hash in stack move sp counter add sp sp 1 peek hash @@ -38,6 +47,7 @@ s dr0 Output IsItem j ra reset: +# Resets counter to 0 zero so we can loop over again move counter 0 yield j start \ No newline at end of file diff --git a/automated_canister_filling.ic10 b/automated_canister_filling.ic10 index 30b445e..273f429 100644 --- a/automated_canister_filling.ic10 +++ b/automated_canister_filling.ic10 @@ -1,6 +1,4 @@ -# automatic gas-canister filler. -# only works with player-made cans, starter-cans -# have different hashes that won't work +# Automatic gas-canister filler. # !!! Remember to set volume pump to no more !!! # !!! than 10l! I have mine at 2l for safety !!! diff --git a/battery_monitor.ic10 b/battery_monitor.ic10 index a24a924..96af199 100644 --- a/battery_monitor.ic10 +++ b/battery_monitor.ic10 @@ -1,8 +1,23 @@ -alias DiodeSlider d0 # Kit (Light) > Diode Slide -alias FirstBattery d1 # The battery closest to your base -alias SecondBattery d2 # Optional second battery type -alias CableAnalyzer d3 # Optional -alias LEDLight d4 # Kit (Light) > LED Light, required if you have Cable Analyzer +# Uses a Diode Slide to show battery-bank fill-level. +# You can add a Cable Analyzer between generators +# and batteries so an LED light can show if system +# is charging or discharging. +# Works best if your batteries are connected in +# series (battery output -> battery input). +# FirstBattery is the battery that faces your base. + + +# Kit (Light) > Diode Slide +alias DiodeSlider d0 +# Battery closest to your base +alias FirstBattery d1 +# Optional second battery type +alias SecondBattery d2 +# Optional Cable Analyzer +alias CableAnalyzer d3 +# Kit (Light) > LED Light, +# required if you have Cable Analyzer +alias LEDLight d4 alias FirstBattCharge r0 alias Type1Hash r1 @@ -19,19 +34,30 @@ define GREEN 2 start: yield +# Checks charge/discharge state if CA connected bdseal CableAnalyzer systemstate l Type1Hash FirstBattery PrefabHash +# Sums current and max capacity of batteries of the +# first type lb Type1Max Type1Hash Maximum Sum lb Type1Charge Type1Hash Charge Sum +# Gets charge-ratio of FirstBattery l FirstBattCharge FirstBattery Ratio +# Gets charges from second type of batteries bdseal SecondBattery t2getcharge +# Creates a ratio from all batteries div Type1Charge Type1Charge Type1Max +# Displays total charge ratio of battery-bank s DiodeSlider Setting Type1Charge -slt FirstBattCharge FirstBattCharge 0.99 +# Turns on Diode Slide light if FirstBattery +# is less than full (danger low power storage) +slt FirstBattCharge FirstBattCharge 1 s DiodeSlider On FirstBattCharge j start t2getcharge: +# Sums current and max capacity of batteries of the +# second type (if present) l Type2Hash SecondBattery PrefabHash lb Type2Max Type2Hash Maximum Sum lb Type2Charge Type2Hash Charge Sum @@ -40,16 +66,16 @@ add Type1Charge Type1Charge Type2Charge j ra systemstate: +# Checks if system is generating more or less power +# than it's consuming s LEDLight On 1 l ChargeIn CableAnalyzer PowerPotential l ChargeOut FirstBattery PowerActual sub r9 ChargeIn ChargeOut -s db Setting r9 -move r10 ra -bgtzal r9 charging +bgtz r9 charging s LEDLight Color RED j ra charging: s LEDLight Color GREEN -j r10 \ No newline at end of file +j ra \ No newline at end of file diff --git a/filtration.ic10 b/filtration.ic10 index 5a21b90..2de3b10 100644 --- a/filtration.ic10 +++ b/filtration.ic10 @@ -106,4 +106,4 @@ beqz FilterHash ra #if you are still here then it is an error so end s filtration On 0 -j start +j start \ No newline at end of file diff --git a/mips-programming-101.md b/mips-programming-101.md index f924c91..c21068c 100644 --- a/mips-programming-101.md +++ b/mips-programming-101.md @@ -10,13 +10,13 @@ In Stationeers you have the following available to you: - Sixteen registers (r0 through r15) - A special address register (ra) - A stack (sp) that you can push 512 values into, and pop values out of. The stack is last-in-first-out. -- A maximum of 128 lines of code, each line has a maximum of 57 characters +- A maximum of 128 lines of code, each line has a maximum of 52 characters The address register (ra) is not meant to be written to by the user, it's only used for branching to code that needs to be accessed from multiple areas in your code (functions). ## Registers? What are they and how do I use them? -Registers are what most programming languages call variables. But where most programming languages let you create as many variables as you want, MIPS has 18 registers, but only 16 of them are intended for regular use. +Registers are what most programming languages call variables. But where most programming languages let you create as many variables as you want, MIPS has only 18 registers, and only 16 of them are intended for regular use. | **Register(s)** | **Alias** | **Purpose** | |-----------------|-----------|----------------| @@ -65,9 +65,9 @@ This ***s***ets ***CeilingLight***'s ***On*** end-point to the value stored in * This may sound a bit cryptic, but bear with me, I'll explain it all a bit further down. #### Setting with boolean comparisons -Boolean comparisons are comparisons made to be either true (1) or false (0). These are great at controlling the on/off state of devices like pumps and lights etc. +Boolean comparisons are comparisons made to be either true (1) or false (0). These are great for controlling the on/off state of devices like pumps and lights etc. -Boolean comparisons are of the type "equal", "equal to zero", "less/great than", "less/greater than zero" and so on. +Boolean comparisons are of the type "equal", "equal to zero", "less/greater than", "less/greater than zero" and so on. If you use one of the operators that compare to zero, you do not need to supply two values for comparison, since the instruction already says one of the values will be zero. @@ -95,13 +95,46 @@ Not all end-points can be written to, this makes sense when you think about it. Aha! But setting Power could be like making a dimmer for the light, right? That would have been nice, but that would more likely be done with an end-point called ***Setting***, which this variant of light doesn't have. To my knowledge, there are no dimmable lights in Stationeers (yet). +## "Moar executions" is not "moar betterer"! + +In Stationeers, everything happens in "ticks", and a single tick is 0.5 seconds. But the code we write in ICs can execute much (***much!***) faster than once per tick. But looping over the code many times in a single tick doesn't make it work better, it just "burns resources". + +What happens is, each MIPS script is allowed 128 lines of exection per tick. If your script executes one loop totalling 70 lines, you will go through almost two loops in one tick, then the execution is halted until the next tick. If you execute 70 lines in a loop, then you execute the remaining 58 lines this tick, and the script will be at line 59 of the loop when it resumes next tick. This can have unintended consequences. Plus, if you read the pressure from a Gas Sensor 30 times in a tick, the pressure will be the same every time since pressure is only updated by the game *once per tick*. + +The solution is to begin or end the loop with `yield`! It doesn't really matter if you put the `yield` as the first or last line in your loop, as long as there is at least one `yield` executed every single tick. This ensures that you start execution at a controlled location next tick. + +Good: +``` +start: +yield +l GasPressure GasSensor Pressure +s GasDisplay Setting GasPressure +j start +``` +or +``` +start: +l GasPressure GasSensor Pressure +s GasDisplay Setting GasPressure +yield +j start +``` + +Bad: +``` +start: +l GasPressure GasSensor Pressure +s GasDisplay Setting GasPressure +j start +``` + ## Making code more readable! > **Code is read much more often than it is written.** > > *- Guido Van Rossum (the guy that created the Python programming language)* -While the MIPS implementation in Stationeers has some limitations (128 lines, with a maximum of 57 characters per line), I've rarely run into problems like running out of room. This is mostly because I try not to write "multi-mega-scripts" that do a ton of things. I'm a fan of the UNIX mantra of "do one thing, and do it well". This also means that I use ***aliases*** and ***defines*** a lot. They take more space than just writing things straight up, but they also make the code much easier to read! +While the MIPS implementation in Stationeers has some limitations (128 lines, with a maximum of 52 characters per line), I've rarely run into problems like running out of room. This is mostly because I try not to write "multi-mega-scripts" that do a ton of things. I'm a fan of the UNIX mantra of "do one thing, and do it well". This also means that I use ***aliases*** and ***defines*** a lot. They take more space than just writing things straight up, but they also make the code much easier to read! Compare these two lines of code: ``` @@ -112,7 +145,7 @@ and slt HeaterOn CurrentTemperature MinimumTemperature ``` -They could do the exact same thing, but the bottom one actually explains what's going on. And it's still shorter than 57 characters. +They could do the exact same thing, but the bottom one actually explains what's going on. And it's still shorter than 52 characters. If you're juggling 10+ registers in your code without naming them, the chances of getting them mixed up increases greatly. And if you do make a mistake somewhere, trying to follow the code can be more complicated than if you used named variables. @@ -149,9 +182,9 @@ This ***define***s ***MinimumTemperature*** as ***20*** (maybe for use as 20 Cel There is also logic for relative jumping in code, and it works by adding an 'r' after the 'b' when branching (so 'b' becomes 'br'). Instead of giving the branch a label to go to, you tell it the number of lines to jump (positive number jumps forwards, negative number jumps backwards). -
SuffixPrefix
- -b-b-als-
DescriptionBranch to lineBranch to line and store return addressSet register
<none>unconditionaljjals
-eqif a == bbeqbeqalseq
-eqzif a == 0beqzbeqzalseqz
-geif a >= bbgebgealsge
-gezif a >= 0bgezbgezalsgez
-gtif a > bbgtbgtalsgt
-gtzif a > 0bgtzbgtzalsgtz
-leif a ⇐ bbleblealsle
-lezif a ⇐ 0blezblezalslez
-ltif a < bbltbltalslt
-ltzif a < 0bltzbltzalsltz
-neif a != bbnebnealsne
-nezif a != 0bnezbnezalsnez
-dnsif d? is not setbdnsbdnsalsdns
-dseif d? is setbdsebdsealsdse
-apif a ~ bbapbapalsap
-apzif a ~ 0bapzbapzalsapz
-naif a !~ bbnabnaalsna
-nazif a !~ 0bnazbnazalsnaz
+
StemDescriptionPrefixSuffix
+ +b-s--al
Branch to lineSet registerBranch to line and store return address
<none>unconditionaljsjal
eqif a == bbeqseqbeqal
eqzif a == 0beqzseqzbeqzal
geif a >= bbgesgebgeal
gezif a >= 0bgezsgezbgezal
gtif a > bbgtsgtbgtal
gtzif a > 0bgtzsgtzbgtzal
leif a ⇐ bbleslebleal
lezif a ⇐ 0blezslezblezal
ltif a < bbltsltbltal
ltzif a < 0bltzsltzbltzal
neif a != bbnesnebneal
nezif a != 0bnezsnezbnezal
dnsif d? is not setbdnssdnsbdnsal
dseif d? is setbdsesdsebdseal
apif a ~ bbapsapbapal
apzif a ~ 0bapzsapzbapzal
naif a !~ bbnasnabnaal
nazif a !~ 0bnazsnazbnazal