RF455-090 RF 4.55 : every quest shows another quest's text (the server sends "quest world 0", so the client loads the wrong Quest.edf)

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

With the supported Taiwan client, every quest's briefing, goal, completion and step text in the Journal belongs to some other quest, and the quest tracker shows _ 0/20 instead of "Hunt <monster> 0/20" (for example Q004040).

The enter-world result (01/02) tells the client which quest file to load. GoMMO sends "quest world 0", so the client loads plain DataTable\Quest.edf. That file's text indexes were built for a different NDQuest.edf and point at the wrong rows of the Taiwan zh-tw\NDQuest.edf. Quest_1.edf, in the same client, holds the same quests with indexes that do fit, and the client's own log shows that the official Taiwan service sent "quest world 1".

How each part is known:

• Client code and data: read in RF_Online.bin (disassembly) and the decrypted Quest*.edf / NDQuest.edf.
• Server: read in the stock v0.3.1 gameserver.exe with a Go symbol disassembler.
• What the official service sent: read from the client's own NetLog\rfclient.log, which came with the archive.org client. That those 2025 sessions were on the official Taiwan service is inferred (they predate GoMMO in that log).

1. How the client picks the quest file

• The 01/02 enter_world_result_zone handler (0x56a960, called from the dispatcher 0x562f50) reads three {u8 flag, u16 index} pairs from the body: cash shop at +3/+4, NPC shop at +6/+7, quests at +9/+0xa. A non-zero flag stores the index (quests: mgr+0x6a75c, 0x56aa4b–0x56aa55). A zero flag stores −1 (0x56aa60). It logs Quest world : %d, selectQuestindex : %d (flag, index; format at 0xab32d4).
• The table loader 0x605d90 opens DataTable\%s.edf for −1, or .\DataTable\%s_%d.edf (0xad8f4c) otherwise. So flag 0 loads Quest.edf, and flag 1 with index 1 loads Quest_1.edf.

2. What the server sends

protocol.EnterWorldResult (0x1406520e0) builds the 01/02 body from its three arguments and then constants:

• +3 = 0, +4 = 0 (cash shop: plain ItemCash.edf);
• +6 = 1, +7 = 1 (NPC shop: Store_1.edf; 0x140652275, 0x1406522a5);
• +9 = 0, +0xa = 0 (quests: plain Quest.edf; 0x1406522e5, 0x140652320).

rfclient.log agrees: every GoMMO session logs NPCshop world : 1, selectNPCshopindex : 1 and Quest world : 0, selectQuestindex : 0. The 2025 sessions in the same log (660 enter-worlds) log Quest world : 1, selectQuestindex : 1, and the same 1/1 for the cash shop and NPC shop.

3. Why Quest.edf shows the wrong text

Quest records are 424 bytes; rows 0–2789 are the server's quest rows in the same order in Quest.edf and Quest_1.edf. Each record holds NDQuest row indexes: step long/short text (+0x24/+0x28, +0x44/+0x48, +0x64/+0x68), completion +0xf0, briefing +0x144–+0x14c, goal +0x158.

• Q004040's step 0 short text: Quest.edf → zh-tw row 3968, another quest's _ placeholder. Quest_1.edf → row 4562, 0x11000004 "獵殺%MONSTER。" (Hunt %MONSTER).
• Over all 2,790 server quests, Quest_1.edf's step texts resolve to a step template 3,672 of 3,672 times, and its briefings, goals and completions resolve to the same quest 81–88% of the time. Quest.edf scores close to 0 against every locale's NDQuest.

4. Quest_1.edf isn't only different text (effect inferred)

Besides the text indexes (and a flag dword at +0x08 in 106 rows), the two files differ in:

• the NPC-event section (336-byte records): 216 rows in Quest.edf, 204 in Quest_1.edf, 198 of the common rows differ. The server's questnpcevent has 207 rows. All 207 of its NPC codes appear, in order, in Quest.edf's section (it has 9 extra rows); 199 of them in Quest_1.edf's.
• the three trailing u32 lists (375/332/328 entries against 413/412/408).

The other event sections are identical. Inferred, not checked: if the client uses the NPC-event rows (for example to decide which NPC offers which quest), loading Quest_1.edf could change what NPCs offer. A live check after the fix would settle it.

Expected

The quest tracker shows the step ("獵殺<monster> 0/20" in Taiwan text) and the Journal shows each quest's own briefing and goal, as on the official service.

Suggested fix

Either:

1. Server: send quest world 1, index 1 in EnterWorldResult (+9 = 1, +0xa = 1), as the official service did and as GoMMO already does for the NPC shop. Then check NPC quest offers in game (section 4).
2. Client data: ship a corrected Quest.edf with the client: Quest.edf with only the text-index dwords above copied from Quest_1.edf. This keeps the NPC-event section that matches the server. We've played with this since 2026-10-03 (1,370 of 2,895 records change; every other byte of rows 0–2789 is checked identical) and seen no quest problems.

How to reproduce in game

1. Take any kill quest, for example Q004040.
2. The tracker shows _ 0/20; the Journal's briefing and goal belong to a different quest.

Local workaround

Option 2 above, applied by hand to RFOnlineTW\RFOnline\DataTable\Quest.edf.

Where to look

• Server (v0.3.1): protocol.EnterWorldResult 0x1406520e0 (quest flag 0x1406522e5, index 0x140652320).
• Client (for checking): 01/02 handler 0x56a960 (quests at 0x56aa40), loader 0x605d90, format 0xad8f4c; NetLog\rfclient.log lines Quest world : ….