Sclerocephalus

It's now actually working.

Package records, conditions sub-records: there's a "parameter #3" listed by xEdit in each package of condition data (CTDA): It appears that this parameter may have different meanings - or may be totally unused - depending on what target the condition has been specified to run. If that target is a quest alias (i.e. the "RunOn" line will display "QuestAlias"), parameter #3 is always the ID of that alias on the quest that owns the package (I confirmed this myself by playing around with the aliases).

Which ghouls ? The pre-placed DEAD ones or those that you killed (i.e. the bodies of the pre-placed LIVE actors) We only handle pre-placed DEAD ones because they are never cleaned up otherwise. Pre-placed LIVE actors are clened up by the engine eventually after they have been killed. Though, in a very fresh game with few actors loaded so far, this may take a while. Side note: altering the time scale won't change anything because scripts need real time to process their tasks. This time won't change, so the only thing gained by altering the time scale is a longer game time span for scripts to finish running.

Since we cannot disable refs when there is a risk that this could happen in plain sight of the player, we have to wait until the area unloads. More specifically, until all refs that need to be disabled have unloaded. This process doesn't start running until the player owns the respective workshop. Therefore, it usually takes place the first time the area unloads after the player gained control of the workshop. The Sunshine Tidings cleanup missed two ghoul bodies because they are in cells that do not form part of the workshop location, although they're still within the buildable area (Bug #23763). This has been fixed for UFO4P 2.0.4 but that fix was not retroactive (i.e. they won't be disabled unless you start a new game).

It doesn't but that's not the point. A faulty mesh will corrupt the engine code that handles the mesh and you get a crash. Whether everything else in the loaded area is fine or not doesn't matter.

Once the problem occurs, disable the mole rats, then try to leave the cell.

I'm currently using NifSkope 2.0 Dev 7. Used this to change the user version numbers from Skyrim to FO3 (?), 12/83 -> 11/34., then saved (Note: the file had previously been stripped of the collision, the BSShaderProperty blocks and the BSX flags). Upon trying to reload it, I got this warning: [0] Array Properties invalid Pos 376: failed to load block number 0 (BSFadeNode) previous block was NiHeader Failed to load F:/Skyrim Mod Projects/Nifs for Blender Import/dwermsmcolumnfixed01_raw_01.nif Loaded the stripped file in old NifSkope, changed the user version numbers there and saved. This file loads fine (i.e. without that error) in both old NifSkope and NifSkope 2.0.

(1) There is no function to toggle persistence from a script. If an object is unexpectedly persistent, this might be because it is still linked to other objects (or other objects being linked to it). Workshop objects that require an actor are linked from that actor (this link is deleted on unload and restored on load). All crops are linked from their damage helpers but this link is permanent; it is not cleared until the crop is deleted. It also could be that the offending object is in a script property. All crops, for example, keep the reference of their damage helper in a script property and they also have an array on WorkshopObjectScript to keep the references of their furniture markers. (2) Deleted objects are not actually removed until their parent cell unloads. Up to that point, they're only "marked for deletion" (that's why scripts should disable them before they delete them, so they are at least invisible until they are actually deleted). Thus, in order to make sure that you don't look at bogus objects, you should allow the workshop to unload and reload before you start inspecting objects. Better though if you allow it to unload and reload twice because the householding functions that start running when a workshop loads do a lot of cleanup stuff that may result in even more objects being removed when it unloads subsequently.

Update: I'm pretty much convinced now that this iis not an F4SE issue. You might want to have a look at this ticket which we fixed almost two yeras ago: https://afktrack.iguanadons.net/index.php?a=issues&i=20640 In this case, an actor array that should actually have been initialized by the OnLoad() event was mysteriously 'none'. At that time, I had no F4SE running (and it did probably not even exist). I also did not spend any time to investigate why the array was none Just added a sanity check and a line to re-initialize the array if necessary, and that did fix it.

In the "Files for Fixes" section, you have to upload a new version first. Only then, there will be delete options for individual files.

A condition check was on the wrong line. Update is on the way.

Good to know. Thanks for the clarification.