Bug Fixes

Player

Hammers in 1.92/2.10 quests reach one tile further when facing up b9354acc0f

In 1.92 and 2.10, the combos affected by a hammer pound were found at fixed offsets from the player. Later versions derive them from the hammer sprite, which sits lower when facing up, and 2 pixels lower still in dungeons. When the player is standing halfway between two tiles vertically, such as after walking up against a solid combo, the old versions pound the tile beyond the adjacent one while newer versions do not reach as far.

End of Time DX (Level 6) and Link's Birthday Deluxe (Super Bomb Dungeon) both have post puzzles that require this extra reach.

A new compat rule controls this behavior: when enabled, the 2.10 pound positions are used when facing up. It is enabled for quests made before 2.11.

Regressed in 2.50.0.

ZScript

String switches under JIT never worked, crashed in web 42e91a9572

A switch on a string compares the key against each case with a string comparison. The native JITs left that comparison to the interpreter, so the branch that followed tested whatever the processor flags happened to hold, and every string switch fell through to its default case. The web JIT could not compile the branch at all and aborted while compiling the script.
printf printed garbage decimal digits for -214748.3648 2efcdc78e3

Formatting the most negative number with %d or %f produced non-digit characters after the decimal point on some platforms, since the fractional digits were taken from the absolute value of a number that has no positive counterpart.

Regressed in 2.55-alpha-112 (626db20707).
Modulo by a power-of-two constant wrong for negative numbers under JIT d376c3caaf

x % d where d's raw value is a power of two (-3L % 4L, or x % 6.5536) returned a wrong, non-negative remainder for a negative x when the script was run under JIT. The interpreter gives -3 for -3L % 4L; the JIT incorrectly gave 1.
Comparisons of a comparison could be folded wrong by ZASM optimizer 7a5f568be7

Code like if ((x < y) == true) never ran its body, <int>(x < y) != 2 behaved like !(x < y), and <int>(x != 0) == 1 was always false. The optimizer's comparison folding modelled a comparison result as 1/0, but a result is 10000/0 (and comparing a bool against true compares truthiness), so it folded these to the wrong constant or the wrong condition.

Bug introduced when comparison reduction was added to the optimizer in 3.0.0-prerelease.2+2024-07-24 (419aac8040).

Web

Dividing a negative number by zero gave wrong result under JIT a25d053b5e

Dividing by a runtime zero yields sign(dividend) * 214748.3647 in the interpreter and the native JITs, so a negative dividend gives -214748.3647. The web JIT incorrectly produced the positive value.

Tests

ZScript

Differential test of script arithmetic under the JIT f130faae9a