Sclerocephalus

This is bad, because it means that your script will need to evaluate the length of the array in every cycle of the loop. The only reason to do this would be in a case where the code in the loop changes the length of the array (though AFAIR, this is not possible in Skyrim scripting). To save the time for the superfluous array length evaluations, do it as follows: len = QuestBooks.Length while i < len (do stuff) endWhile

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 events - unless they were delayed and fired at the same time as trigger events may do (not impossuble, but too much of a coincidence).

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 specified actors, there is no NPC required..

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 addition to UFO4P are Better Settlers, dDefinder's physics tweaks and a settlement building limit uncapper. With this combination, I don't get any crashes, at least not repeatable ones. The game does still crash occasionally after extended times of playing (say, > 6h without interruprions) or if I have to reload too often within a short time interval (i.e. the typical situation where you need too many trials to fight a hard boss on a high difficulty level), but these crashes are never repeatable: if I reload after quitting to desktop, they won't reoccur.

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 fixed by Bethesda.

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,