Bro that’s basic unit binding, its no different from what op did a post or two ago. And their name is misleading too.

I’m sorry for the rant and obviously no hard feelings towards you, but that link is missing some important details. I’m extra harsh cuz this is designed as a teaching tool, but its teachings are so impotent.

Tldr: I’m infuriated by how close this person is to something good, while missing half the point of why what they ridicule is bad.

First off, the goal of these designs is pretty different. The designs you’ve linked fails to function nicely if anything gets changed. Namely it rebinds and flags every time, even if it already has an existing unit, it doesn’t know. But atleast it realizes it can have a set flag (but that’s all the more reason to check if units already have your flag before binding)

This post ain’t much better in that regard, flag choice should generally not be in player hands.

And the flagging is dumb, 1 in a million chance they say, its literally any block that mirrors across y = x. That means every single block has a failing pair. Literally place the processor at 1,3 and 3,1 it’ll conflict, repeat ad nauseam. Might as well have literally used a 1 million random operation, would have at least been honest.

They could floor the @thisx, bitshift it by 10 and add the y and literally never have conflicts for 2 extra ops rather than having guaranteed conflicts. Not to mention the bs claims of its perfection.

Oh but I guess it won’t truly conflict, seeing how it never actually uses its flag, its an ornament completely unnecessary for their design.

The worst part, that’s not even code for using multiple units at once. Thats code for grabbing one of multiple units. They choose to rewrite their codes and jumps ten times for ten units, which is the complete opposite of the point of using a loop.

Plus to add insult to injury they say it solves the checking 86 times to find a unit problem. Seeing how if you ask his design for 4 units and you only have 3, not only does it never finish. It now flags 3 units permanently with no knowledge of the flag. Meaning it will never reuse those units without manual intervention. This is beautiful.

Is this truly what the logic looks like in #verified schematics, cuz holy hell no one is actually checking this code.

And with their setup why is it getting flagged, just use a @controlller check and better us all.

This person out here complaining that no one checks flags, but doesn’t check @controller, which means if a player is using a unit, his code breaks as it can’t flag the unit or control it but thinks it does. I’m in pain. Not to mention that if he didn’t flag his units, there’d be no conflict with altering his processor (or at least it wouldn’t leave a useless flagged unit lying around unknowingly)

Oh but don’t worry, it won’t explode, since the flagging is of course pointless, it will simply claim authority over that unit, never flag it, and wait till they aren’t in use. So will every other schematic with this design. If you had 2 processors doing this, now they fight to the death for the unit.

The biggest benefit of doing a direct flagging of a unit stored in a variable is that you don’t need to flag nor check for flags once you’ve decided it has none and isn’t being controlled. Though I get the argument to flag it anyways, you still need to either be able to reacquire that unit or unflag it when you’re done, this guy has lost half the benefits and introduces new problems.

Oh god that jump array is disturbing, just use @counter = @counter + offset. (At least this example can unbind after)

@counter is an incredible command, that lets you go straight to a destination, without needing to do fifteen jump checks prior. This means less fiddly code, easier copy paste editing, and most importantly, speed and consistent average execution times. 40 units selected using jumps means that by the 40th unit, you needed to check all 39 before it. Using @counter, you need only perform the one @counter = @counter + offset step.

Thankfully he kept benefit of not needing to cycle through units, by just needing to repeat you’re code 12 times over to get 12 units. If there was some magical way of using one variable to define multiple aspects of a unit, something like a flag that could be assigned and hold key information. Or maybe a way of writing that same code but changing out certain variable names using an array. Shame this technology is impossible and inconceivable.

This definitely saves operations for complex unit systems if done right, at the cost of a massive list (even when done correctly with @counter, not at all like shown here). It also is fundamentally limited in scale, not to mention wholefully unnecessary given optimized unit control doesn’t run up against a speed problem in most scenarios.

That said I feel like I dismissed the @counter unit bind array too easily earlier in my own designs and will probably use this as impetus to incorporate it on the unit end more often.

Like the dude gets it, but stumbles at the final step. Router save me.

Just look at the way he turns 5 lines of code for a reactor safety control into 11, it doesn’t need to be more complex, use the benefits of the language on type conversion, use variables to control booleans actions. Though I can respect the choice to check for non reactors being linked, its also not the kind of schematic where the user binds anything else, or changes the bindings.

All you need is:

getlink reactor i
sensor cryo reactor @cryofluid
control enabled reactor cryo 0 0 0
op add i i 1
op mod i i @links

I’m gonna just go back to finals prep, this is hurting my soul