The Hazards of Zan's AutoPurge (Unexpected Purging of Disabled Things)

[Athelbras]

The issue that I am about to describe may be quite obvious to more experienced modders. In fact my approach may even be a known bad thing to do. But it had never dawned on me before. So if nothing else, this is an FYI to others not yet in the know ...

 

The Essence: "disabled" thingies [EDIT: with an active script] can be unexpectedly purged/deleted without your knowledge or desire if a player uses Zan's AutoPurge (or a similar data flusher). Zan's minimizes out-of-memory conditions by periodically forcing the game to flush "old" data from memory, and does so much more aggressively than the game engine normally would. This potentially causes problems.

 

For example, if a mod has an NPC set to Disabled in order for it to be both inactive and invisible until triggered (perhaps with its own scripted Enable springing it into action), that NPC could then be unexpectedly flushed/purged/deleted before coming into play.

 

One such circumstance is the Player character being outdoors and nearing that lurking NPC, but suddenly ducking into a building to check for other enemies before proceeding onward, then coming back out again. In doing so, that zone/cell transition invokes a purge by Zan's which causes the lurking NPC to cease to exist. And flagging the NPC as Quest Item / Persistent does not prevent it.

 

With Zan's removed, the encounter plays out successfully, regardless of the player's actions, movements, and transitions.

Knowing that behavioral characteristic of Zan's, one can of course use an alternative implementation to entirely avoid the issue. It is the mods (and modders) having no knowledge of Zan's behavior that are at risk.

 

So modders beware.

 

- * -

 

Caveat: I have exactly the situation described as a test case. Fully reproducible at will. But of course am willing to learn that I am misinterpreting results if someone else has better insight into what is taking place.

Edited April 9, 2015 by Athelbras

[Jokerine]

Hm. This could seriously break my upcoming mod if disabled things get deleted. I may have to put a warning in the description... Thanks! :thumbsup:

[Fallout2AM]

Zan doesnt' do anything different from what you could do via console. So if you want to double check what you're stating, make this simple experiment. Jump in game. Take a random named npc / Cheyenne for example. PRID it, so its ID will be cached in your console memory and you will easily access to it pressin up arrow. Disable it. PCB. Change cell. PCB. Fast travel. PCB. Go back. PCB. Prid it again - Enable. If it's not there, Player.MoveTo <ID> and see where it went.

 

My guess is you'll always find it. Even MarkForDelete references are not erased when they're persistent.

[Athelbras]

I am able to recreate the problem manually.

 

In essence, issuing a PurgeCellBuffers command while in a separate zone/cell results in the disabled NPC (which has an active script) no longer being "functional" when you return to the outside world where it is positioned. It is not clear whether it has been "deleted".

 

Since scripts do intentionally run on disabled thingies, I inserted passive message calls within the NPC's script as a kind of "I'm still here!" notifier. So as long as the NPC is present and "active" (as in still disabled but also still running its script), the message is seen in the upper left-hand corner of the screen.

 

Without Zan's, once the messages begin to appear, I can step into that nearby building to transition into a new cell, and the messages temporarily stop - because I am no longer in that NPC's world space; which is correct behavior. When I step back outside, the messages resume. I can repeat the step in and step out as much as desired, and then walk over to be within trigger range and the encounter occurs.

 

If I step into the building and issue the PurgeCellBuffers (PCB) console command, then step back outside again ... the messages do not resume. And the encounter won't trigger.

 

If I do the step in and out with Zan's enabled ... the messages do not resume. And the encounter won't trigger.

 

Creating a circumstance where the game issues its own PCB has the same negative results. This can be done by travelling to a sufficiently distant location (via COC or regular map travel). Upon return the NPC is again no longer responsive: the messages do not resume and the encounter won't trigger. Note that relatively local travel via COC and the map does not necessarily result in the game issuing a PCB, and so the NPC may still be active.

 

Note also that issuing PurgeCellBuffers while simply remaining in the area has no effect. It only matters when in a different cell location.

 

So my current conclusion is that disabled thingies that are executing their own scripts can't be absolutely relied upon, because a PurgeCellBuffers call (either via the game's own mechanisms or via a mod like Zan's) can potentially render them non-responsive/non-functional. Less so with Zan's because it issues PCBs in situations where the game itself would not.

Edited April 9, 2015 by Athelbras

[Fallout2AM]

"So my current conclusion is that disabled thingies that are executing their own scripts can't be absolutely relied upon, because a PurgeCellBuffers call (either via the game's own mechanisms or via a mod like Zan's) can potentially render them non-responsive/non-functional. Less so with Zan's because it issues PCBs in situations where the game itself would not."

 

Now this sounds better than saying that "disabled things are deleted by PCB", or that mod would have tons of reports of broken vanilla quests :)

 

In general it's not a good behaviour relying on a script attached to a disabled npc, and not because of Zan autopurge: you can have issues like that randomly on any cell change or quit / reload. You can't foresee when the game purges the cache.

[Athelbras]

I guess I am not convinced by your view. Although I may indeed be mistaken.

 

According to the wiki, disabled things remain in memory until their delete flag is set, for example via MarkForDelete. Otherwise they continue to exist and should not be destroyed by anything, even PurgeCellBuffers. See the accompanying information about disabled items embodied in the MarkForDelete description.

 

So instead I am wondering if this is actually an unintended occurrence as the result of an underlying game bug.

 

As for "In general it's not a good behaviour relying on a script attached to a disabled npc", can you cite a particular reference that supports that belief?

Edited April 9, 2015 by Athelbras

[Fallout2AM]

they remain in memory, this doesn't mean that their script must work. If you rely their existence by the script attached to them, you risk a lot. It's not a Zan's mod issue, it's the way the memory is purged.

Let's make a couple of examples, let's see if I can explain better what I mean.

 

- Take your script ("I'm here!" on console when the npc script is running), attach it to a npc and set him as Disabled, on its panel, not via script, the reference must be disabled via GECK, stop.

Now go in game, go in the cell of that npc, you won't see it because it's disabled. Following what you said, the script should run. Is it running? No, it will start if you PRID the ref and enable it.

 

- Now take the same script, reproduce the same "issue" you experienced, ok? Your npc is enabled, you disable it, "I'm here!" is still on console, ok? Save the game, quit, re-open the game and reload. Is "I'm here!" still on console?

 

I hope this explains better what I mean. Understanding when the cache purges helps you a lot when you use certain NVSE functions which are not persistent and you must refresh them periodically

Edited April 9, 2015 by Fallout2AM

[Athelbras]

Let me cite you another reference: " Disabled references are not rendered, and disabled actors will not process their AI. Scripts will run on disabled references." See the description for Disable. Revisit the description on MarkForDelete.

 

One possibility is that the sentence means that I can have a script that refers to / interacts with that object, versus meaning its script actually runs. I am interpreting as the latter, where assigned scripts do run: everthing I have created thus far gives evidence that it is so, without fail.

 

My actual implementation seemingly counters what you posted: my NPC is defined as "Initially Disabled" via GECK/FNVEdit. I do not disable him via script. He has an assigned script. I create and position him. His script is now running. He is not visible and does not appear on my radar and does nothing because he is still Disabled. But, again, the script is running and the messages appear. When I approach him he self-Enables via that script, which causes him to appear and is then actively mobile and on my radar and attacks me.

 

Doesn't that invalidate the example you gave which indicated this should fail?

 

As for Zan's ... my follow-up reply (as the result of further investigation) explained fairly clearly that it was not after all a Zan's issue per se, but rather a PurgeCellBuffers issue. So I acknowledged that fact. Zan's merely exacerbates the problem by performing PCB in situations where the game ordinarily does not.

 

Cite a reference for this opinion you stated? "In general it's not a good behaviour relying on a script attached to a disabled npc". I don't mean this as an antagonistic rebuttal, but rather a further effort to discover the truth as best we can.

 

So ... from what I have read and experienced first hand, it still seems valid to conjecture that this "problem" is actually an unintended occurrence as the result of an underlying game engine bug which clobbers disabled objects when it should not. Alternatively, it is perhaps an undocumented fact that the game engine will deliberately remove disabled objects at some point, even when their Delete flag has not been set.

Edited April 9, 2015 by Athelbras

[Fallout2AM]

Or you could simply try this esp:

https://drive.google.com/file/d/0B9H0W8lI6DR-MkM3OGZ0QVVCa1E/view?usp=sharing

 

Go in doc mitchell's house and see what happens in console

[Athelbras]

I suspect that the difference is in your approach versus mine. You have your NPCs statically positioned. Mine are put in place by means of a PlaceAtMe and then a MoveTo. My approach clearly allows the scripts to run. Yours does not. Why, I don't know.

 

Look. This is silly. My approach works. Period. It has been in a companion mod for many months, with many such automated encounters throughout the game, and they have all worked flawlessly ... up until this recent discovery concerning PurgeCellBuffers. So telling me that what I am doing does not really work is non-productive. You are welcome to experience my implementation yourself: Buddy Bot. Once Buddy joins you, just proceed up the long road up the slope that leads up to the Mojave Outpost; that is the easiest one to readily trigger. There will be three separate encounters along the way. All of them have "Initially Disabled" and only become enabled via their own assigned script; ergo they have running scripts while disabled.

 

To get the discussion back on track ... the real issue is whether or not PurgeCellBuffers should validly clobber Disabled objects (in this case with their own scripts) which do not have their Delete flag set. If so, that is not documented and is seemingly contrary to various descriptions in the wiki; see Disable and MarkForDelete. Meaning either the wiki is wrong, or there is a game bug; or maybe my interpretation of what is written is mistaken. My hunch - and it is no more than that - is game bug.

Edited April 9, 2015 by Athelbras