I think I found something strange with how the level Storage Cracker works

[Husk]

So I updated my ALU to be able to bitshift so my solution to the storage cracker level was to start by checking if 128 is higher than the code. if its higher than the code I then check 64, and if its lower than the code I check 192 (128 + 64) and this repeats over and over until I get the correct code (or at least I hope) my problem is that every time I send an output its ALWAYS too high. so every time I run my code it checks 128 then 64, then 32, ect ect. until eventually I output 0 and the game says I am correct.

For some reason if I add 2 and only 2 lines of code at the beginning and I set register 0 to hold a value of zero and then to output the value of zero THEN the level kinda works right. it seems like if I check zero at the start of my code then the level always picks 181 to be the correct solution, and if I don't check zero at the start of my code it decides to set zero as the correct solution. also both of the tests always have the same solution for me either zero or 181

[SunCat]

the level checker is "adversary", and does depend on whether you interact with input, and what values you are giving it

[mial.lohmann]

I agree that this "adversary" check is a bit broken (at least that there is no other one): The following program should definitely not succeed in general, but it does for the two test cases

COPYi 128 _ IO
COPY IO _ _ # Read and ignore input
COPYi 64 _ IO
COPY IO _ _ # Read and ignore input
COPYi 32 _ IO
COPY IO _ _ # Read and ignore input
COPYi 16 _ IO
COPY IO _ _ # Read and ignore input
COPYi 8 _ IO
COPY IO _ _ # Read and ignore input
COPYi 4 _ IO
COPY IO _ _ # Read and ignore input
COPYi 2 _ IO
COPY IO _ _ # Read and ignore input
COPYi 1 _ IO # no need afterwards for the read here
COPYi 0 _ IO

(so basically start from 128 and each step half the numbers, in-between you need to load the input though)
Or the same in the loop version

const guess R0
const tmp R1
COPYi 128 _ guess

label loop
COPY guess _ IO
COPY IO _ tmp # read, but don't use
SHR|IMM2 guess 1 guess # half the number
JMP _ _ loop

[BFG9K1]

Yeah I think this is a bug. I also tried to do the same thing and my program never completes. If I make the very first opcode a "send 0 to out", then everything works perfectly. Extremely weird. In fact, if the first value sent is over 127, it seems to break. Spent hours debugging this. Not fun.