Sclerocephalus

This bug may not even be specific to Bethesda's engine, as I have seen the exact same thing occasionally happen in other games as well, including Kingdom Come Deliverance and The Witcher 3. I assume therefore that the algorithms used for certain aspects of AI processing are developed by a third party and have been implemented "as is" by the individual game developers.

https://www.nexusmods.com/fallout4/mods/42448 This was fixed in UFO4P 2.0.6 (bug #23294). Note that our fix - unlike the mod referred to above - does not remove the clipping glue bottle, but moves it into the correct position.

I assumed that you were not using Buffout. If you're plagued by frequent crashes, consider using it as its crash monitor may give a lead to the real culprit. There's some guess work involved though, so it will not always provide useful information. In the first place, you'll have to make sure that your crashes are repeatable on your end (i.e., that they occur repeatably when specific operations are carried out). Also note that it's not a standalone crash monitor but includes a dll with engine fixes, and that may cause glitches on its own. In my own game, the only mods I'm using in additio

Many crashes in Fallout 4 seem to be related to using up-to-date NVIDIA drivers under WIndows 10. Details are discussed in the thread of the "Buffout" mod. Start reading the posts from the end (i.e. oldest first) and you will soon find more information: https://www.nexusmods.com/fallout4/mods/47359?tab=posts The problem is apparently not really a driver issue because the drivers obviously work well with other games, and even with Fallout 4 if different operatng systems are used. It is soecific to the Fallout 4 / Windows 10 combination and thus something that likely needs to be

You can't move settlers around with console commands. There's a ton of extra stuff that needs to be done to make this work, and there are dedicated functions on WorkshopParentScript to handle that. If you don't do it properly, the affected NPCs may glitch out in various ways. That's nothing new.

You probably have to track this for each driver and store the tracking variable. OnActivate() events on the carriages should reliably work to tell you whether the driver is sitting (and in which carriage). OnSit() is not reliable and may even pass a wrong furniture ref (apparently an engine bug, according to the notes on the CK Wiki). OnGetUp(), on the other hand, is reliable,

If I got this right, you're looking for a way to store the driver state. You want it to be easily accessible by condition functions and you also want to protect it from being manipulated by unsuspecting mod authors. SOLUTION: Make a custom faction, count all drivers in, and store the information in the faction rank. Tthis also enables you to use more than two states (in case you need them). There are condition functions for both the adherence to a faction and the faction rank.

This had to be expected. Fast travel markers are pre-placed objects (i.e. placed references that are defined in a master file or a plugin) and therefore cannot be deleted. Only objects created at run time can [NB: to my knowledge, the only exception are pre-placed live actors if they are no longer persistent].. If you "delete" an object (either in workshop mode, by a script or by console commands), it only gets disabled and tagged as "marked for deletion". The game will then delete it when it is safe to do so. For pre-placed objects, this is never the case; for all others, this is

The CK Wiki tells this about sending animation events to actors directly: " If you use it to send an event to actors, you will most likely mess up the actor permanently as the internal actor data may no longer match their animation state. " see: https://www.creationkit.com/index.php?title=SendAnimationEvent_-_Debug

That Labyrinthian mesh issue was caused by a bug in the compressed mesh type collision calculations of NifTools which has been corrected in the meantime. If the meshes in question had their collisions built with the latest version of NifTools, there should be no weather issues (and if they have no compressed mesh type collision, it shouldn't matter anyway). From my own experiences with faulty meshes, the CK is much less forgiving than the game. Thus, the lack of crash reports does not necessarily support the integrity of the meshes. It just tells us that few (if any) users of that mod are

Some things to keep in mind: When an actor is placed, the game will try to move it onto the nearest navmesh without saying. If a cell is not loaded, there will be no navmesh either, so placement is expected to be pretty inaccurate. Placing an actor in an unloaded cell via PlaceAtMe won't work if the ref to place the actor at is not peristent. While you can force any ref to be persistent by ticking the respective flag in the CK, having too many peristent refs is not a good idea (they permanently consume memory). Likewise, actors cannot interact with refs in unloaded cells un

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. Als

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.