<div dir="ltr"><div><div>I just noticed something I wasn't aware of before: there is a special case that if you talk to an NPC which shows a textbox, then visnpc is not called if either a textbox sets a tag or the NPC has a onetime tag, until the whole chain of textboxes is over. This is so that if you're talking to a onetime NPC they won't disappear until after the end of the textbox chain. (The npc_visibility argument to tag_updates does this)<br><br></div><div>This can be a nice feature actually (if it works). Unless you want a NPC to disappear at a certain point in a textbox chain.<br></div><div></div><div>This is a very delicate kludge, because a huge number of things could cause an additional call to tag_updates. But the fact that a battle, for example, causes NPC visibility to be updated will often be desired anyway.<br><br>And in r4586 (2011) in particular I added many extra calls to 
party_change_updates or tag_updates where they were missing. As a result
 I expect NPCs now disappear earlier than they used to in various circumstances, perhaps causing glitches in various old games. I don't see any way to achieve backcompat except for making a whole lot of a bunch of tag_updates calls conditional on a backcompat bit, which is a mess, a pain, and probably just going to end up diverging anyway.</div><div>I was just documenting this behaviour on the NPC and textbox conditional help pages but then thought maybe I shouldn't because it's not reliable.<br><br></div><div>Putting aside backcompat, it looks like users don't have enough control. Just recently two people in Discord have complained about the timing of NPC disappearance.<br></div><br></div><div>I don't know what to do, and it seems like a distraction, so maybe the best solution is to not mess with the code further, document it as it is, hope r4586 didn't cause too many problems, and in future provide more options for control, like the option for textbox settag conditions which happen when a textbox is closed instead of when it is opened.<br></div></div>