RF455-060 RF 4.55: set bonuses are off after every login (07/2D before 03/01 is dropped)

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

Summary

The client asks for its set bonuses (07/2D set_item_check_request) during the login downloads, before it sends 03/01. The server drops any 07/2D that arrives before 03/01 and sends no reply. Nothing asks again after spawn, so a character who logs in wearing a full set has no set bonus until they take a piece off and put it back on.

• Server side: read in the v0.2.0 code, and confirmed live on our server (see "Live test").
• Client side: read in the client code. A real client logging in with a set on was not captured.

Server (v0.2.0, read)

• handleSetItemCheck (0x1408dcfa0) needs 7 bytes, a non-nil client+0x78, and isInWorld. When isInWorld is false, the jne at 0x1408dd042 falls through to ret. There is no 07/2E and no log line.
• isInWorld (0x1408daca0) returns the byte at client+0x738.
  • Only enterWorld (0x1408dade0, mov byte [rcx+0x738], 1 at 0x1408dae6f) sets that byte, and only handleNewPosStart (the 03/01 handler, which answers 03/02) calls enterWorld.
  • leaveWorld clears it.
• The active sets live in a map at client+0x1a8. Its only writer is putSetItem, called only from setItemCheck, which only handleSetItemCheck calls.
  • putSetItem creates the map on first use (makemap_small).
  • The client struct is allocated per connection (newClient, runtime.newobject), so every login starts with no sets. Nothing loads sets from the database.
• handleNewPosStart runs recomputeCombatStats at spawn. With the map empty, applySetItemEffects adds nothing.

Client (read)

• 03/08 cum_download_result is handled by 0x56d960. At its end (0x56de27) it calls the equipment board's 0x4712d0.
• 0x4712d0 walks the 14 equip slots and compares each one's "unusable" marker with the usability check 0x41ddc0:
  • the marker is the sprite byte at element +0x38, read by 0x676270 (≠ 0xFF means marked) and written by 0x6752d0 (0x2c = marked, 0xFF = clear);
  • a slot counts only when they disagree;
  • if any slot counted, it calls the set re-check 0x41a590.
• At window setup, 0x674cf0 (slot 6 of the board's vtable 0xadd49c) calls 0x7b64a0(elem, 0x40, 0) on every marker. With flag 0 that writes sprite file 0x2c, so every slot starts marked.
  • At 03/08 each usable equipped item flips from marked to clear, so the check runs.
  • That the setup runs before 03/08 is inferred from its role (it sizes and initialises the board); it wasn't traced.
• 0x41a590 passes its guard (avatar +0x459c == 0, which the character reset sets at 0x44a923). It then clears the client's own list of active sets and sends 07/2D (0x587e90) for every set whose worn count reaches a tier (0x41a310).
• The client turns a set on only when 07/2E comes back (0x588060, results 0 and 8). With no reply, the set stays off on the client too.
• The order is real. In a relay capture of the real client logging in (2026-10-05), 03/08 arrived at t = 217.781 and 03/01 went out at t = 219.516, 1.7 s later. That character wore no set, so no 07/2D appears in it.

Nothing asks again after spawn (read)

• 04/19 state_inform (0x5c4270), 03/24, 04/09 and 04/15 reach 0x4712d0 through 0x44dee0. 0B/01 level_up (0x5a62e0) calls it directly. All of them go through the same per-slot flip test, so they re-check sets only when an equipped item becomes usable or unusable. That doesn't normally happen after spawn.
  • So a level-up doesn't restore the bonus unless it changes an item's usability.
• Equipping or unequipping goes through 0x46fe80 / 0x4702e0 → 0x46ee70. That path sends 07/2D directly (0x46f60f, 0x46fab7), with no flip test, so re-equipping one piece should restore the bonus. This is expected from the code; it was not tried live.

Live test (v0.2.0, 2026-10-09)

• Setup: a throwaway account and character, using our scripted client.
• Steps:
  1. Send the follow-up downloads, including 03/07.
  2. Send 07/2D 01 00000000 03 01 (on, set 0 setwb01, 3 pieces, 1 effect).
  3. Wait 3 s, then send 03/01.
  4. Once in the world, send the same 07/2D again.
• Result:
  • Before 03/01: no 07/2E, and nothing in the server log.
  • After spawn: 07/2E 03 00000000 01, result 3 (not enough pieces worn), as expected for a character with no gear.
  • So the handler works once the character is in the world, and silently drops the same request before that.

Suggested fix

Either:

• accept 07/2D once the character is loaded (client+0x78), without waiting for isInWorld. Spawn already runs recomputeCombatStats, which applies the stored sets; or
• at spawn, have the server work out the active sets itself from the worn items, instead of relying on the client's login request.

How to reproduce in game

Expected from the code above; not yet tried with the real client.

1. Wear a full set, for example 3 pieces of setwb01 such as palmas set or ihbwc50 (effect 1 turns on at 3 pieces).
2. Log out, log back in, and note the stats.
3. Take one piece off and put it back on. The stats should rise by the set bonus, which shows it was missing.

Local workaround

Re-equip one piece of the set after each login.