Sclerocephalus

The original beta had German mod description texts on the muffled mods because I forgot to replace them after I did alter the keywords. It's up to you to decide whether that's important.

3D game objects generally consist of two meshes, one for the visuals (i.e. what you see) and an invisible one for the physics (the so-called collision mesh). The mesh for the visuals has pretty high detail.. The collision mesh however has low detail because the performance that needs to be invested in collision detection increases with the number of faces. A good collision mesh preserves the shape of the visuals mesh as accurately as possible despite having a much lower face count. To accomplish this, tiny wrinkles that may exist in the visuals mesh get flattened out in the collision mesh. Also, accuracy may get reduced on purpose in places that are out of reach to colliding objects. The water tower, for example, does actually not need any elaborate collision at the top because that's out of reach to the player, and there are no high-flying actors around. If collision is noticeably inaccurate (the "thin transparent layer" phenomenon you were referring to) in places that can be directly interacted with, this is plain simply a mesh error and by no means a limitation of contemporary computer games. In fact, you can realize "perfect contact" quite easily; that only depends on the skills of the 3D artist. Now if you look at the tower mesh in the CK and toggle the collision geometry (by pressing F4 while the render window is active, note that you will have to wait a few seconds for the collsion meshes to be displayed), you'll see that the collision at the tower's base is pretty accurate, and also that the first aid box is the object with the bad collision (note the completely unnecessary details on the edges). That box was also not floating but clipping into the tower base instead, in addition to being placed in a position that blatantly derides real-world physics. That's a crystal clear placed reference issue (see screenshot).

The skeletons are static objects, not actors. That is, they will behave just like any other pre-placed rubble piece in the game. They were never intended to clean up.

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.