frog moonjump: kuscofrog's mid-air code rises while padaux bit 0x800 is set, nothing on pc ever sets it (verified in game by poking the bit)
This commit is contained in:
1 parent
15ad050005
commit
b5b6e22957
2 files changed
+39
No files matched your search
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
@@ -76,3 +76,42 @@ Level select / unlock-all is the save editor's job (`--unlock`), not duplicated
|
||||
loss (`img/mods/cheats_fall.jpg`).
|
||||
* `rewards` (bit 3) decoded only, not played through to a chapter end.
|
||||
* Diagnostics: file written, game runs normally.
|
||||
|
||||
## Frog moonjump (PS second controller)
|
||||
|
||||
Question from speedrunners: is the frog moonjump (PS: needs a controller in port 2) reachable on PC?
|
||||
Answer: **the logic is in the PC data, but its input can never be set on PC without patching.**
|
||||
|
||||
Strat side (all 34 level WADs disassembled, 2026-11-08). Property 88 `padAux` (DAT_005FCF58) is read
|
||||
only by Llama (23 WADs), LlamaChase (t1l2m003), KuscoBunny (t1l7m004, t1l8m001, t1l8m002), KuscoFrog
|
||||
(t1l4m003, t1l8m003) and CheatTeleport (26 WADs, also `padAuxPressed`). Everything except the frog's
|
||||
air handler is additionally gated by property 258 (0x102), which the exe getter hard-wires to 0
|
||||
(jump table 0x552684[0x102] → 0x55231B `push 0`); CheatTeleport removes itself when it is 0.
|
||||
|
||||
KuscoFrog (t1l4m003 unit 44), airborne handler L_136c – **no prop-258 check**:
|
||||
```
|
||||
if (self.padAux & 0.5) { ; bit 0x800
|
||||
g22 = 0.055 ; vertical speed upward, every frame while the bit is set
|
||||
v31 = 1.0
|
||||
}
|
||||
self.y = max(self.y + g22, v44)
|
||||
```
|
||||
Ground handler L_1d6c (take-off): `(padPressed & 4.0 /*jump*/) | ((padAux & 0.5) && prop258)` → the
|
||||
aux bit alone cannot start a jump, it only keeps the frog rising once it is in the air (= moonjump:
|
||||
jump normally, then hold the aux button). Llama/Bunny/LlamaChase have the same code (Llama: g22 = 0.0698)
|
||||
but behind `prop258`, so they never moon-jump.
|
||||
|
||||
Exe side: 0x5FCF58 is referenced exactly 3× in groove.exe (all 4-byte immediates scanned): 0x425B93
|
||||
`mov dword [0x5FCF58], 0` (end of the pad poll FUN_004256C0, only if pad count 0x5FCF6C > 1, i.e. a
|
||||
DirectInput joystick is present), 0x425C1E (edge detect → 0x5FCF60 `padAuxPressed`), 0x551403 (strat
|
||||
getter, prop 0x58). It lives in .bss → always 0. No keyboard key, joystick (1st or 2nd), debug key or
|
||||
demo (.dem) playback writes it. Under Wine without a joystick: pad count 1, padAux 0 (read in game).
|
||||
|
||||
Verified in game (apptest :25, t1l4m003 Jungle day ch. 3, teleported onto PotionPadFrog → FrogPotion
|
||||
→ frog): `set {int}0x5FCF58 = 0x800` via the winedbg gdb proxy. Frog on the ground: nothing happens.
|
||||
Frog jumps (X): it keeps rising – y 13460 → 41617 (~2 s) → 59842 (~4 s), far above the level; clearing
|
||||
the bit makes it fall back. Same write as the llama: normal jump, no effect (prop 258 = 0).
|
||||
`img/mods/frog_moonjump.jpg` (top: normal frog jump, bottom: bit 0x800 set).
|
||||
|
||||
To enable on PC a patch is required, e.g. make the pad poll map a key to padAux bit 0x800. Which PS
|
||||
button of pad 2 feeds bit 0x800 is not known (no PS binary analysed) – hypothesis only.
|
||||
Reference in new issue
Block a user