itch.io

I'm not sure, unfortunately - I optimized my Task 11001 code and didn't think to save the original, so I no longer get the error.

Saving the solution for a normal level.

Follow-up to this one, from Bonus Task 1; by far the most persistent bug I've encountered in the game - and by far the most annoying to nail down and report - is the bug where a piece of code causes the program to exit out of the WHILE 1 loop early, reporting "OUTPUTS ARE NOT CORRECT" even though the cursor is only on the second row.  I finally managed to get a minimal example of the bug:

WHILE 1 {
    IF IN[0] {
        RAISE J; 0; 1000 {
        }
    }
    OUT IN[0];
    DOWN 1;
}

As you can see in these screenshots, when the RAISE J clause is present, the program exits out of the WHILE 1 loop early, having only written a single output and read a single input.  However, when RAISE J is not present, the program goes through the loop as normal:

A little testing shows that the content of the IF statement can vary (this still occurs with IF 1 instead of IF IN[0]), the output command can vary (or not be present; I included it for demonstration), and the variable name and limits of RAISE can change, as well as replacing RAISE with LOWER.  It does not occur replacing RAISE with TIMES, however.

What's made this so hard to figure out is that this bug is dependent on the order in which you enter and run code.  For instance, if you first put a RAISE *around* the IF statement, run it, and then remove the RAISE, the program will run correctly.

In this manner, it is possible to have two identical files, for the same task, whose behaviors are entirely different.  Of all the bugs, this one's probably the worst.

I sincerely appreciate you still maintaining this game after all this time, and I would love to play through the bonus tasks and see the game's ending.  I'm playing it on 64-bit WINE for Ubuntu 20.04 (the native Linux build unfortunately segfaults), and would be happy to provide debug logs, system specs, more screenshots, or whatever else would help.

Thank you!

The game occasionally crashes without warning upon saving a file.  The file is wiped in the process.

___________________________________________
############################################################################################
ERROR in 
action number 1
of Other Event: Room End
for object oCodeWrite: 
unable to convert string ";" to number############################################################################################
gml_Object_oCodeWrite_Other_5 (line 31)

On Task 10111, I get two different results depending on if a variable - which is never read - gets assigned.  I suspect the WHILE loop isn't updating properly.

EDIT: And using this same code on Task 11001 (everything above the screen is the code shown above in Task 10111), after sufficiently many steps the output doesn't work:

BEFORE STEP:

AFTER STEP:

My defragmentation files seem to be out of sync.  I got a notification for "Holiday.txt", but it wasn't there when I checked it.  Later, when I got a notification for "Commandments.txt", that wasn't there, but "Holiday.txt" had appeared in the interim.

There seems to be a bug in extended ELIF statements, at least in Task 1101.

Realizing that the inputs for Task 1101 were only 4 bits (which seems an oversight; there are 34 inputs which could potentially be doubled without overflowing the eight-bit register), I hardcoded a lookup table and soared way under the par time for steps, though obviously was way above the par word count:

However, I ran into serious problems and inconsistencies trying to optimize this solution further.  If I end these IF statements with ELIF, the program runs fine.  However, ending with ELSE (which, since I cover all possible branches, should lead to the same thing) leads to the ELSE getting triggered a significant portion of the time.  In this case, the program only succeeds on the last three branches, which doesn't seem intended:

Additionally, and I don't know if this is intended or not, the @ statement overrides long IF / ELIF chains, forcing the program into sections of code under IF statements whose conditions are not met.