RF455-045 # RF 4.55: after every potion, the client's HP/FP/SP bars jump to garbage (07/08 packs u16, the client reads u32)

Game: RF 4.55 (Dragonborn), server v0.2.0, Windows build (stock gameserver.exe, SHA-256 96452fbd…). Client: the supported Taiwan build, RF_Online.bin SHA-256 46528aac…2bbc558 (2025-07-16), Language=Taiwan.

Summary

• Each time you drink a potion, the HP, FP and SP bars jump to nonsense for about 2 seconds. HP shows millions, and FP shows millions or billions. Then the next 0B/02 pools update puts them back.
• In a fight, while you drink HP potions, it looks like FP and SP are "draining" or flickering each time a monster hits you.
• Cause: the potion reply 07/08 (use_potion_result_zocl) is packed with u16 HP/FP/SP, and the client reads u32s.

Steps to reproduce

1. Be in a fight with HP below max (anything that lets an HP potion heal).
2. Drink an HP potion, e.g. ipcsb28 (+7777 Premium Potion) or the starter HP potion.
3. Watch the HP/FP/SP bars right after: they jump, then snap back at the next 0B/02.

What the server sends

(*Server).handleUsePotion (0x140865dc0) builds 07/08 in 13 places (e.g. 0x1408677db, 0x140867e25), always as a 12-byte message:

u8 ret, u16 item serial, u16 HP, u16 FP, u16 SP, u8 left        (10-byte body)

What the client reads

CNetMsgProcessor_Item 07/08 handler (0x584a90 in RF_Online.bin). On ret 0, at 0x584bca–0x584bfb:

mov ecx, [body+3]  -> set HP  (0x41b540)
mov ecx, [body+7]  -> set FP  (0x41b720)
mov ecx, [body+11] -> set SP  (0x41b8f0)

That's the layout u8 ret, u16 serial, u32 HP, u32 FP, u32 SP (+ u8 left), 16 bytes. With GoMMO's 10-byte body the client takes:

• HP = HP | FP << 16;
• FP = SP | left << 16 | (2 bytes past the body);
• SP = 4 bytes past the body.

Live capture

A read-only client hook logged the pools the client holds, next to the messages that set them (v0.2.0, Ranger, max HP 3578, FP 126, SP 426):

11/0D HP 1887 (-420)               <- monster hit
local HP 8261114                   <- right after the 07/08 of a +7777 potion: 0x7E0DFA = 3578 | 126 << 16
local FP 28901802                  <- 0x01B901AA: SP 426 | left 0xB9 << 16 | stray byte
local SP 809472
0B/02 HP 3578, FP 126, SP 426      <- about 2 s later, correct again

Suggested fix

Pack 07/08 as u8 ret, u16 serial, u32 HP, u32 FP, u32 SP, u8 left (16-byte body), the way the client reads it. 11/0C–0E and 0B/02 already send u32 pools.

i run a local stopgap that does exactly this: each of the 13 builders allocates 18 bytes instead of 12 and stores the three pools zero-extended to u32. Since then the bars no longer jump.