RF455-068 RF 4.55 : Dying in siege mode leaves the server's siege state set ("Already in siege mode" until relog)

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

Summary

If an Accretia player dies while transformed with a siege kit, the server never clears its siege state. The client leaves siege mode by itself on death, so the next use of the kit sends 1C/01. The server refuses it with code 3, and the client shows "Siege mode : Already in siege mode". The player can't transform again until they relog. Until then the server still treats them as sieging:

• every skill attack wears the siege kit down;
• the siege defence factor still applies.

How each part is known:

• Server side: read in the stock v0.3.1 gameserver.exe (with a Go symbol disassembler).
• Client side: read in RF_Online.bin.
• Server log: the sequence below.
• What the screen showed: reported by the player; the text is the client's string for code 3 (read).

1. Server log (our history.log, 2026-10-11, one player)

16:39:50 recv {"op": "1C/01", "body": "2100"}
16:39:50 siege transform {"kitSerial": 33, "kitIndex": 1, "visualVer": 18}
16:39:53 recv {"op": "05/37", ...}
16:39:54 monster killed a player {"monster": "07B0B", ...}
16:39:54 player died {"serial": 3162}
16:40:01 player resurrected by potion
16:40:43 teleport recall ...      16:51:34 portal use ...
16:51:54 recv {"op": "1C/01", "body": "2100"}
16:51:54 siege transform rejected {"code": 3, "kitSerial": 33}
16:51:55 siege transform rejected {"code": 3, "kitSerial": 33}

There is no "siege release" between the death and the rejections. Every other transform in our logs ends with a 1C/04 "siege release".

2. Only release and an empty kit clear the flag (read)

• The state is client+0x18 → siegeState (under the mutex at client+0x10); byte +4 = in siege mode. isSieging (0x1409225a0) returns it.
• armSiegeState (0x1409223c0) sets +4 = 1 on a successful 1C/01.
• +4 goes back to 0 only in:
  • handleReleaseSiege (0x140923e00, 1C/04);
  • forceReleaseSiege (0x140925e60, called from consumeSiegeKit when the kit's durability runs out).
• onPlayerDeath (0x1407fea00), revive (0x1407d8ac0), actResurrect, teleportTo, handleMovePortal and enterWorld don't touch it.
• checkSiegeTransform (0x140923260) refuses with code 3 when isSieging:

140923506: call  isSieging
14092350b: test  al, al
14092350d: jne   0x140923565        ; -> code 3

3. The client leaves siege mode on death (read)

• The 03/17 handler (0x5661d0), for your own Accretia avatar, calls the leave-siege routine (0x44cac0) at 0x566424.
• From then on the client thinks you're out of siege mode, so using the kit sends 1C/01 rather than 1C/04.
• The server's code 3 maps to string 0x61A "Siege mode : Already in siege mode" (the 1C/02 error table at 0x593750).
• The player has no way to release from the UI: the client sends 1C/04 only while it believes you're in siege mode.

4. Side effects while the stale flag is set (read)

• handleAttackSkill and structureSkillAttack call consumeSiegeKitOfActor when isSieging, so skill attacks keep using up the kit after death.
• (*client).defenceFC keeps applying the siege defence factor.
• Radar, fire crackers, lost-EXP recovery items and the soccer ball are refused as "in siege mode".

Expected

Death ends siege mode on the server too, as it already does on the client.

Suggested fix

In onPlayerDeath, release the siege state the way forceReleaseSiege does:

• clear +4 (and the kit fields);
• send 1C/06 to the players around, so they stop drawing the siege form.

The dead player's own client has already left siege mode, so it may not need a 1C/05.

How to reproduce in game

1. As Accretia with a launcher, transform with a siege kit (1C/01).
2. Die (to a monster or a player).
3. Resurrect, then use the same kit. You get "Siege mode : Already in siege mode", and the log shows "siege transform rejected" code 3.

What I do locally (not a fix)

A server byte patch jumps from the top of onPlayerDeath (0x1407fea1d) to a small routine in the function's int3 tail. If [client+0x18] isn't nil, the routine sets its +4 byte to 0. No 1C/06 is sent.

Separately, the client keeps the kit marked as in use in its inventory window after death (+0x8bc). The client's own release clears that mark with 0x477fc0, but the death path doesn't call it. So using a different kit after death is refused locally with "Another siege kit is in use". That one is a client issue, and i patch the client for it.

Where to look

• Server (v0.3.1):
  • siegeStateLocked 0x140922280, isSieging 0x1409225a0, armSiegeState 0x1409223c0;
  • checkSiegeTransform 0x140923260, handleReleaseSiege 0x140923e00, forceReleaseSiege 0x140925e60;
  • onPlayerDeath 0x1407fea00, consumeSiegeKitOfActor 0x1409255a0.
• Client: the 03/17 handler 0x5661d0 (the call at 0x566424), the 1C/02 error table 0x593750, the kit use 0x4759e0.