Conversation
|
I tested this PR and found another issue. While talking to an NPC with an active dialog, I tried to use a
After this happens, my character becomes stuck. I also tested the same scenario on rAthena, and the same issue occurs there. |
b7d5356 to
daf8e99
Compare
|
Welp, thanks for the report. |
It's working now. The However, the |
|
Great. As for the blessing scroll we'll have to wait for more info and address it when it comes to that. |
|
@skyleo may you be able to confirm the blessing scroll? |
|
@Streusel Scenario
It seems that using an item with its own menu while an NPC menu is already active causes the item script to continue with a menu selection automatically instead of waiting for the player to select an option. 9-20-2026.6-49-57.AM.mp4 |
|
@kyeme Do you have an example of this in official? Is the NPC menu supposed to be dismissed? What's the expected behaviour? Other than the menu obviously being accessible. |
dun_tele_scroll.mp4If the NPC dialog does not have a menu shown, I can use the Dungeon Teleport Scroll normally. The issue only happens when the NPC dialog currently has a menu/selection shown. If I use So it seems this case is specifically related to using an item with its own menu while an NPC menu is already active. I'm not sure what the correct official pre-renewal behavior should be, since I don't currently have access to a pre-renewal Aegis server to verify it. For comparison, on the official Renewal server I tested, usable items cannot be used at all while interacting with an NPC, so I can't use Renewal behavior to confirm how this should work in pre-renewal. |
…action With item_enabled_npc allowing item usage while an NPC dialog is open, using an item attached a second script to the player. The NPC's script was backed up into the item script's bk_st and then reported as a lost "Double continuation", discarding the conversation the player was in. The player is now detached from the running script before the item script is executed, and reattached to it afterwards, so an item that does not open a window of its own leaves the conversation intact. Detaching the script is not enough on its own, because the answer a menu() or input() is waiting for is kept in the session data rather than in the script state. An item script that opened a menu of its own found that pending answer already set and read it as its own, returning a selection the player never made for it, so a dungeon teleport scroll used while an NPC menu was open warped the player immediately instead of asking where to go. The pending answer is now saved and cleared before the item script runs, and handed back only when the previous script is reattached. An item script that does pause to show its own window is a different case: by that point the client is already displaying that window, so the previous conversation can no longer be resumed and its script is released instead. Restoring it there would leave the client showing one dialog while the server expects another, which locks the player out of both. Based on rathena commit: commit 3c93e30 Author: Lemongrass3110 <lemongrass@kstp.at> Date: Wed Oct 29 18:36:28 2025 +0000 Fixed an issue with item_enabled_npc (#9606) Fixes #8625 Thanks to @thanna Fixes HerculesWS#3471
daf8e99 to
b1c063a
Compare
|
Tested the new PR, and it's working now. Thank you! |
3 participants
Pull Request Prelude
Changes Proposed
With
item_enabled_npcset to allow item usage during NPC interaction, using an item that opens a dialog of its own while an NPC conversation is already open printed aDouble continuationwarning and silently discarded the conversation the player was in:pc_useitem()ran the item script while the player was still attached to the NPC's script.script_attach_state()therefore backed the NPC's state up into the item script'sbk_st. When the item script then paused to show its own dialog,run_script_main()reached thest->state != END && st->rid != 0branch, foundst->bk_stset, emitted the warning and calledscript_free_state()on the backup. That freed state was the NPC conversation.The player is now detached from the running script before the item script executes, and reattached to it once the item script is done, so no backup chain is ever created. Whatever state the item script leaves pending is discarded, because it may not take over a conversation that is already in progress. When no NPC script is attached, which is the ordinary case, the added code is inert.
The fix is a port of the equivalent rAthena change for the same bug. The upstream commit is reproduced in full in the commit message, as done previously for other ported changes in this repository.
Testing
Reproduction from the issue report, in pre-renewal with
item_enabled_npc: 0x3:Issues addressed: #3471