RF455-081 RF 4.55: daily (repeatable) quests can be done only once per character, never again after 24 h

Game: RF 4.55 (Dragonborn), server v0.3.1, Windows build (stock gameserver.exe). Client: the supported Taiwan build, RF_Online.bin SHA-256 46528aac…2bbc558 (2025-07-16), Language=Taiwan. Expected (wiki) Credit to RFDB for https://wiki.rfdatabase.net/ : Update 4.15 "Age of Patron": the Captured Keeper's non-battle daily and the HERO's battle daily can each be done once per 24 h, and they earn the Daily Quest Completion Certificates that the HERO exchanges (5 / 25 / 45 / 65 / 85 / 198). 4.151 "reworked" the daily without details. The quest data agrees: these quests have m_bQuestRepeat 1 and m_dRepeatTime 86400.

Summary

• The server never lets a character take a finished quest again (read). Completing any quest adds it to character_quests_done, and both the NPC's offer list and the grant skip every quest in that list. Nothing removes an entry, and m_bQuestRepeat / m_dRepeatTime are never read.
• So all 118 repeatable quests in gamedata_rf455.db are once per character: 72 with a 24 h cooldown (the 4.15 dailies, the Elite training quests), 30 with 12 h, 16 with none.
• The certificate exchange can't be reached. The certificates (iyday01/02/03) come only from the Lv70 and Lv81 dailies, one per completion: four rows per race (two from the Captured Keeper, two from the HERO). Done once each, a character gets at most 4, and the cheapest exchange needs 5.
• The server's own embedded schema notes say so: the original's character_quest_history "carries the repeat-cooldown expiry", and "the repeat-cooldown rules … are not implemented".

Server side (all read, v0.3.1)

• Offer and grant: handleNPCQuestAccept 0x1408bd580 → npcQuestOffers 0x1408bcd80 (which skips any quest for which hasQuest is true: call at 0x1408bcfa2, test al,al; je past the skip) → grantQuest 0x1408fd840, which calls hasQuest first and, when true, logs "quest grant skipped: already held or already done" and grants nothing.
• (*client).hasQuest 0x1408ffae0 returns true when the quest index is in the done map at client+0x1d8 (mapaccess1 at 0x1408ffb72), or in a held slot.
• Completion: retireCompletedQuest 0x1408fb500 (from creditQuestActUsing, completeQuestSlot and gmPassQuest) stores the done row and calls markQuestDoneInSession 0x1408f7d00 at 0x1408fb7c3. There's no repeat check on the way.
• The ledger never shrinks: the only SQL on character_quests_done is the CREATE, INSERT IGNORE INTO character_quests_done (character_serial, quest_index) VALUES (?, ?) (MarkQuestDone 0x1406316c0) and SELECT quest_index FROM character_quests_done WHERE character_serial = ? ORDER BY quest_index (CompletedQuests 0x140631840). completed_at is written by its default and never read. No DELETE.
• The repeat columns are unused: m_dRepeatTime occurs only in the loader's field-name list and in the schema comment. character_quest_history is created but never read or written, and handleQuestDownload sends 03/39 (protocol.QuestHistoryDownloadResult 0x14066de60) with an empty list (xor eax,eax; xor ebx,ebx at 0x140871bce).
• In a real save: our gommo_rf455.db has quests 2320 (Q364300) and 2516 (Q364496), both 86400 s, in character_quests_done since 2026-10-04. By the code above they stay blocked. (Read from the DB; i haven't tried to take them again in game.)

The quests affected (read, gamedata_rf455.db)

The certificates are a reward of Q3r4661, 662 (third item), 701 and 702. The exchange (combinetable2 rows 22833–22850) matches the wiki's counts.

Suggested fix

When a quest with m_bQuestRepeat 1 completes, record the time (the original keeps it in character_quest_history.end_time and sends it in 03/39) instead of, or as well as, the permanent done entry. Then let hasQuest's done test pass once m_dRepeatTime seconds have gone by (or, for repeat time 0, right away), and send the history in 03/39 so the client can show the cooldown.

Local workaround

Deleting the quest's row from character_quests_done while the character is offline should make it available again: the done map is filled at login (seedInitialQuest → setQuestsDone 0x1408f7660, which builds the map at client+0x1d8). This is inferred from the code; i haven't tried it.