The patch altered the frame size of a call instruction, but I failed
to update the matching argument count on the stack.
This caused Print to receive an incorrect argc and crash the
gymnastics scene in room 920.
See: 4a40ac92ea
Fixes bug #14791
Thanks to @EricTSten for reporting this
Thanks to speedrunner @hitmarty for discovering this.
Thanks to @deckarep for the recent `errorString` feature that
helped diagnose this script bug from a screenshot.
- Fixes stack overflow when `error` is called from kernel function
- Includes most recent pc when `error` is called from kernel function
- Handles script procedures in addition to object methods
- Uses target name to identify game to log variant/fallback info
- Condenses errorString to a single-line header
When clicking "buy clue" in the microscope puzzle, the game could crash with a division by zero in
cartesian:buyClue, depending on the initialization of the puzzle itself. Because the initialization is
random and non-deterministic, this crash would only occur very rarely
QFG4 attempts to copy from a null array/string, and this had no effect
in the original interpreter. Now we behave the same.
Update kFileIOOpen to handle the script's subsequent attempt to open a
nameless file.
Fixes bug #14646
Fixes a crash due to an assertion failure that appeared in Google Play
Console. This would occur if a script somehow called kMessage to get
the next message from the stack before calling kMessage to initialize.
We don't know what game caused this, but I have confirmed that this was
not a fatal error in the original interpreter. I then tested this with
a custom script that calls kMessage in the wrong order.
Now our behavior matches the original and we log a warning.
Fixes bug #14613
Tweak in scriptdebug.cpp disassembler logic because the new logging wasn't quite working how it was expected.
- These opcodes weren't showing up with their selectors in all scenarios
- Improve output formatting
Show additional selector name context when push0, push1, push2 opcodes are used.
Possible matching selector names are always shown for the debugger disassembly when a `pushi` opcode is encountered. This is great as it gives additional context when push is used for call/send related invocations.
It would be nice to additionally show *possible* matching `selector` methods/properties when `push0`, `push1` or `push2` is encountered because selector names start at 0 so the dissassembly never shows selectors 0 through 2 inclusive.
sluicebox
Иван Марчуков
Le Philousophe
Walter Agazzi
Kaloyan Chehlarski
Ralph Caraveo
Eugene Sandulenko