Programming & Development

Bump!

Description This fix addresses a quest-system problem that occurs when multiple quests are registered for the take event of the same NPC. Example: object/9009/take/fisher.start object/9009/take/eveniment_pescar.start Each quest may work correctly on its own. However, when both handlers are installed, the client can sometimes remain stuck with the cinematic black bars after choosing an option. No additional message appears, the action is not completed correctly, and the player may need to relog. The server usually reports: QUEST ScriptAnswer pid 11475 answer 0 Select: wrong QUEST_SELECT request! : 11475 Please note that answer 0 means the player selected the first option. It does not represent a failed upgrade result. Cause NPC::HandleEvent() executes all quest handlers registered for the same NPC event. For example, when an item is given to NPC 9009, both of these handlers may be executed: fisher.start eveniment_pescar.start If the first handler reaches select(), it is suspended while waiting for the player's answer. However, the original event loop continues and executes the next take handler. If the second handler finishes, it can replace or clear the currently running quest state. The client still displays the selection created by the first quest, but when the player answers, the server is no longer suspended in the QUEST_SELECT state. This results in: Select: wrong QUEST_SELECT request! A when ... with ... condition alone does not fully prevent this issue. The condition is evaluated inside the compiled quest handler, but the handler itself is still called by NPC::HandleEvent(). Source fix Open: game/src/questnpc.cpp Find the following function: bool NPC::HandleEvent(PC& pc, int EventIndex) Inside this function, there are two loops that call: CQuestManager::ExecuteQuestScript(...) Both calls must be modified. 1. Existing-state handler loop Find the call that uses the fMatch structure and replace the bare function call like: CQuestManager::ExecuteQuestScript(pc, fMatch.vdwQuesIndices[i], fMatch.viPCStates[i], fMatch.vcodes[i], fMatch.vcode_sizes[i]); with: if (CQuestManager::ExecuteQuestScript( pc, fMatch.vdwQuesIndices[i], fMatch.viPCStates[i], fMatch.vcodes[i], fMatch.vcode_sizes[i])) { return true; } 2. New-start handler loop Find the call that uses the fMiss structure and replace the bare function call like: CQuestManager::ExecuteQuestScript( pc, fMiss.vdwNewStartQuestIndices[i], 0, script.GetCode(), script.GetSize()); with: if (CQuestManager::ExecuteQuestScript( pc, fMiss.vdwNewStartQuestIndices[i], 0, script.GetCode(), script.GetSize())) { return true; } Do not use an unconditional return. The return value of ExecuteQuestScript() must be checked. How the fix works ExecuteQuestScript() returns true when the quest coroutine is suspended and waiting for player interaction, for example: select wait input confirm select_item When this happens, NPC::HandleEvent() must stop executing additional handlers for the same event. If the quest finishes without being suspended, ExecuteQuestScript() returns false, allowing the loop to continue and giving another handler the opportunity to process the item. In simplified form: if (quest_is_waiting_for_player_input) { stop_processing_other_handlers; } else { continue_to_the_next_handler; } What this fix allows This modification allows multiple take handlers to coexist on the same NPC. For example: object/9009/take/fisher.start object/9009/take/eveniment_pescar.start It does not allow two select() dialogs to run simultaneously. The first handler that suspends and waits for player input owns that event. The remaining handlers will not be executed during the same invocation. Quest conditions should therefore remain mutually exclusive whenever possible. If two handlers intentionally process the same item and both need to display a selection, they should be combined into a single quest flow. Recompile the game source and that's it. Good luck.

Thank you for sharing this. It’s wonderful to relive these beautiful memories again!

ZEROMT2 — THE OLD METIN2 EXPERIENCE IS BACK! LEVEL 70–250 | MID RATE | OLD LORD STYLE Miss the 2008–2010 Metin2 era? Forget complicated modern systems. Jump in, gear up and fight! ━━━━━━━━━━━━━━━━━━━━ WHAT AWAITS YOU? 7-Option Full Starter Gear for everyone Skills start at PERFECT MASTER (P) Fast progression & direct action PvP & VS Tournaments Regular events & rewards Blue Dragon • Azrael • Spider Baroness • Devil Catacomb NO ALCHEMY NO SASHES NO LYCAN NO UNNECESSARY SYSTEMS No Cheats • No Lag • No GM Intervention ━━━━━━━━━━━━━━━━━━━━ START ON EQUAL TERMS. GET YOUR GEAR. ENTER THE ARENA. SHOW YOUR POWER. If you miss the atmosphere of Old School Metin2... ZEROMT2 IS WAITING FOR YOU! JOIN NOW: zeromt2.com #ZeroMT2 #Metin2 #Metin2P

DX9Ex related, i'll just leave this here for the interested ones: Github Pages - Friendtm

Looks like Yohara is based on it, pretty similar concept. But this one appears to be larger, while Yohara looks smaller but more polished (obviously)

I believe that NPC shadows work the same way, they only render at 2500 units distance.

KR Skill Page: CN Skill Page: I also found the old watermill objects from this trailer: https://youtu.be/i2WZp0H8OmA?si=kLi6AQjDoMYkPrg0 These objects have inbuild animation. (maybe if you want to read this: https://metin2.dev/topic/22407-inbuild-gr2-animation/page/3/?&_rid=14335#findComment-169525) Protos:

Yes but the game client is just coded in a horrible horrible way. YMIR hard-coded the view distance as 25600.0f in the source. You can get help from AI to locate those values and correct them by wiring the far fog distance to view distance rather than everything being hard coded as 25600.0f

Is it possible to change how the preview is rendered? Is there a limit? [Hidden Content]