Tactical RPG: Turn-based Tactics Game

0.24.2 — The roster turns the wheel like the battle journal

Build: mod_version is 0.24.2; artifact: tactical-neoforge-1.21.1-0.24.2.jar. Protocol identifiers are unchanged: Tactical 10, skill channel 4, battle-log channel 2. Patch on the ui_remake line; nothing is merged into main.

• One wheel direction for both HUD lists. The roster previously inverted the wheel on purpose; it now receives the raw notch exactly like the battle journal, so a notch down browses towards the newer end and the entries already on screen move up, while a notch up browses back and they move down. The inversion was removed from the roster's single call site and the helper that performed it is gone, so no configuration switch and no second code path exist; the journal's chain and its oldest-first storage are untouched, and the ends still clamp and consume the notch instead of handing it to the quick bar.
• Cross-HUD coverage. The three roster wheel tests were rewritten for the shared direction - up, down, zero, NaN, infinite, both ends and no overflow, over every total of 1..12 rows with every valid offset - and a new test compares the two HUDs directly at a scrollable middle position: the same delta must move the already visible rows the same way in both. A roster that drifts away from the journal therefore fails even while every journal assertion stays green.

Verification (actually executed for this build): :common:test 51 items plus :neoforge-1.21.1:test 540 items - 591 Java tests passed with 0 failures, 0 errors and 0 skipped - and 51 offline tools/test_*.py items passed. tools/check_release.py passed its packaging gate on the 0.24.2 artifact (ca25f7d1acf642292ca9555c3b5156d82de0bce0beb544c3ec7668d08948c9f2, 1 466 845 bytes). Real-game evidence comes from tools/verify_release0242_wheel.mjs in one development client with the real Dungeons Perspective and AgentHelper loaded, 19 checks with 0 failures: a battle with eleven participants whose roster draws four rows and a journal keeping nineteen entries in a body that shows six, both parked away from their ends with real notches, then the same notch delta=-1 given to each HUD - the roster window steps 3 to 4 and the two rows that stay on screen move up one row each, the journal's viewport top grows 142 to 151 px and all six drawn entries rise by 9 px - and one notch up restoring both exactly. Each notch was delivered once through the client's scroll callback, the held item never changed, and the oldest journal end neither moved nor released the notch. Four raw screenshots are stored with the results file. The reviewer, having passed a randomized image-reading check, personally inspected all four and confirmed that both lists move upward on the same down-wheel input and return on the up-wheel input.

Still open (not claimed as passed): only one development client at 640x360 GUI with the default interface size was driven, so other presets, window sizes and a second player are unverified; the wheel was exercised through the client's own callbacks, not the reporter's physical device. Development classes/resources were run; the packaged JAR was checked separately, not independently runtime-tested.