Sclerocephalus

Plus, there are objects where referencing works backwards. Construction and tempering recipes, for example: they reference the items they are supposed to work on but they are not referenced by any record themselves (at least not by any record in the game files; they are apparently still referenced by engine level code though).

You mean the bug where you kill all the enemies but the quest does not progress ? That's usually a script issue. There are various methods used on quests in the game to count the killed and still living enemies, but all of them require scripts. We fixed some of these issues (e.g. due to an error on REScript, all quests that were using its enemy group counter functionality could get stuck), but cannot provide these fixes for playstation users, due to Sony's asset restrictions.

What story manager event are you using ? Scipt event ?

Well, you're right. On the other hand, if you believe in your own theory, it shouldn't matter what modTargetCount().is doing and TriggerMe() would run if any of the specified actors enters the trigger. But only once because TriggerMe() changes states. Thinking of it, that actually leads to another problem: it's near to impossible that the three instances were triggered by the same actor. There should have been some delay if it was the same actor leaving and re-entering, so the state change after the first call of TriggerMe() would have left the script unable to react to the following

This specific trigger is configured to start a dialogue scene (via quest DialogueDawnstarIntroBrinaHorikSkaldScene; the only purpose of this quest is to start a specific scene), that involves four actors: three to take part in the dialogue (Brina, Horik and Skald) and the player to witness this. It thus makes little sense for the script to proceed before all of them are within a sufficiently short distance to each other. DefaultOnEnter reacts to trigger enter and leave events, and will process them if any of the specified actors interacts with the trigger. Since the player is one of the s

Works also in Fallout 4. UFO4P 2.1.2 had to create a mesh to fix bug #19582. From the changelog: This was made with Outfit Studio.

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