Paid Support / Searching / Recruiting
Post your problems or searches in this forum, only if you want to pay.
Are you looking for a collaborator in your team? Tell us your request in this forum.
Also, consult our sellers within the Marketplace to search for a third-party service.
Search for paid services and search for collaborators only!
1861 topics in this forum
-
- 0 replies
- 1.5k views
-
-
- 1 reply
- 1.5k views
-
- 3 replies
- 1.8k views
-
- 3 replies
- 1.4k views
-
- 0 replies
- 1.5k views
-
- 4 replies
- 2.4k views
-
- 0 replies
- 1.6k views
-
1 reaction
- 1 reply
- 4.6k views
-
-
- 1 reply
- 1.4k views
-
- 0 replies
- 1.6k views
-
- 2 replies
- 1.7k views
-
Current Donation Goals
-
Activity
-
-
15
Granny 3D SDK - The Source Code - v2.9.12
Well. it implies a lot of research and understanding. not just blindly asking AI to do it.. the point should be that you should know what or how the source is working in regards each aspect.. so it easier to have the sdk atyour hand first. -
15
Granny 3D SDK - The Source Code - v2.9.12
granny source is not a must, actually its sub-par nowadays. you can easily swap it for ozz-animation with claudino i should take no more than an hour -
-
0
[FIX] Multiple TAKE quests on the same NPC – wrong QUEST_SELECT / stuck cinematic bars
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.- 1
-
-
13
The 2004 client has been recovered: 倚天II second Chinese closed beta
Thank you for sharing this. It’s wonderful to relive these beautiful memories again!- 1
-
-
0
⚔️ ZEROMT2 — OLD LORD STYLE, THE REAL METIN2 SPIRIT! ⚔️
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 -
337
[M2Dev] Advanced Files To Build Your Server: Src & Server Files & Client [x64 / DX9Ex / CMake / Python3.14 / FreeType / XChaCha20-Poly1305]
DX9Ex related, i'll just leave this here for the interested ones: Github Pages - Friendtm -
5
Shinsutest Map Finished
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) -
2
Rendering Limit Correction
I believe that NPC shadows work the same way, they only render at 2500 units distance.
-
