LarannKiar

If you're interested in the mod plugin file limits, take a look at this and this articles. Note that while these are about the absolute limits, in reality, the engine can't handle this large amount of data. As for the actual limit, if one installs "too many" mods: - the game may get stuck in an infinite loop after launch (can't even load a save), or - skips initializing forms from mods whose plugin files were loaded after exceeding this limit The actual limit is unknown. It seems to be connected to form types and total game form count. (Some said ~80 normal/large sized mods, others ~120 small/normal sized mods). Note that most of these were reported on v1.12.36 (or maybe lower). I think BGS will change the affected code in an update.

I made an SFSE plugin recently to patch GetFormFromFile and IsInDialogueWithPlayer. Let me know if anyone's interested, I'm not sure if it's worth releasing.. Or if there's another broken native script function, I can take a look at that as well.

BGS uses their own CRC32 implementation, BSCRC32 for the pointer handles. (In Starfield handles are also held in the form data structure somewhere near the FormID and the player's handle became 0x1 ). Problem usually arises when the engine has to process too many data on the main thread which can result in micro stutters or even freezes. By the way, there's an INI setting fStoryTellerQuestFindTime:General (2 by default) which I'm not certain what it does but it seems to be some kind of failsafe time for the Story Manager to find/initialize a quest. Might worth checking it with bEnableStoryManagerLogging:General = true, maybe it has some effect on performance but I don't know.. Yes, executing condition functions shouldn't be an issue. I remember I once attached a logger to one of the native condition functions, I think it was GetOffersServicesNow, and it logged thousands of calls within a few minutes in vanilla but there wasn't any stutter. Also when one creates a perk with perk entry Activate "Replace Default", upon hovering the cursor over an activatable object, the perk entry "spams" the code with constant reevaluation requests for the condition field. Attaching a perk fragment script to a Replace Default Activate perk entry causes a huge script lag but the engine is able to handle the load without issues. Constructing extra data for large number of references on the other hand can cause lags. Edit: I meant the perk entry Run Immediatelly, not Replace Default.

It can, especially if it's started/stopped in less than 1 second. Actually, the engine evaluates conditions in the background all the time, they aren't necessarily the cause of the lag but the "filling" process. For example if you set up a quest with a RefColl with one fill type condition GetIsIbjectType "Static" == 1.00 (or any similar condition that allows filling many refs), the game may freeze for a second or so when starting the quest. If you add GetIsIbjectType "Static" == 1.00 AND GetIsIbjectType "Static" == 0.00 you won't experience the same lag. The difference is that upon filling, the game modifies all those thousands of Static refs. I.e. depending on the alias data, constructing / adding; new keywords, attaching a linked ref; or for Actor refs: adding override packages, setting an override voice type or name, etc. How fast are the embedded functions like SetDisplayName and the like is hard to tell. The MagicEffect Cloak effect is timer based which, if I'm remembering right, is defined in the INI setting fCloakEffectUpdateInterval:General (0.5 by default). The engine has to evaluate all conditions attached to the active effect source forms which results in a constant engine load. The code takes the actor process lists to iterate the actors. Cloak effects are not necessarily bad and for per Actor script processing ActiveMagicEffects are pretty handy but I personally wouldn't recommend using them for more than 30 actors and would also recommend checking fps and looking for micro stutters.

It seems like RobCo Patcher was trying to load a Potion ("Aid") item with FormID 691B3 defined in MojaveImports.esp shortly before the crash. Check the mod files of this mod, update it if needed. Also, you can take a look at your load order in FO4Edit to see whether if this mod conflicts with another.

Are you sure it's caused by sStartingConsoleCommand? The command or batch file defined there is executed once the engine loads game data which happens after the game is opened. At that time, the main menu's bink movie is already playing.

In general, mods shouldn't break after a new patch is released because the game has received official mod support. SFSE and SFSE plugins on the other hand are officially not supported so they may need to be updated by their respective authors.

Seems like the free cam / Photo Mode ship light bug was fixed in v1.12.36.

Did you edit the vanilla Ballistics perk in the Creation Kit and after saving this is how it appeared in game? That's odd, the Creation Kit shouldn't produce broken text replacement form data.

Have you tried adding the .ba2 as an additional archive to CreationKit.ini? ..\Starfield\CreationKit.ini >> [Archive] >> SResourceArchiveList2=SomeMod - main.ba2

In Creation Kit: Planet >> see tabs Per Biome Data and Resources Biome >> Biome Data >> see Resource Generation Data I made a planet database mod for organic and inorganic resources if you're interested.

Unfortunately yes, without the source it's very difficult to figure out how the values are used in the formula. The native functions HasDetectionLOS, IsDetectedBy, PlayerVisualDetection (and the like) were meant to be exposed to the condition functions list. They do all the calculation needed internally. I think PlayerXXXXXDetection >= 0 means HasDetectionLOS = true but I'm not sure... Documenting Detection isn't really possible as it's too long with many "special cases" that's hard to document without writing a very long text. For altering the Detection behavior, I'd "Set Undetectable" for full undetectability while applying some detection modifiers then unset the Undetectable flag when needed from a script. This way, one can control when the Vertibird is supposed to be detected but unsetting the Undetectable flag on it won't cause high level detection from any detector immediatelly (due to the changed modifiers), e.g. when an enemy receives LOS on the Vertibird, they won't engage it immediatelly (CombatLevel = 1) just starts "searching" for it (CombatLevel = 2).

All of them does different things, here's what I know about these. - Chameleon effect: applies the "invisible shader" on the actor; AV Visibility: used by the hardcoded detection formula to determine the "visual detection level" of the actor - Mod Detection Movement: used by the hardcoded detection formula to determine by how many values an actor's movement (e.g. speed) affects their detectability - Mod Detection Light: used by the hardcoded detection formula to determine an actor's "light detection level" - SoundLevel: used by the hardcoded detection formula to determine an actor's "sound level" (e.g. jumping near an enemy sends a "low suspicion" (see hardcoded AV Suspicious = 1 or 2) detection event to hostile nearby actors; what nearby means is determined by the detected-detector distance and the sound level) - Set Undetectable: overwrites everything above and makes the actor undetectable - notes: - Detection is a derived value of Light, Audio, Visual and Sound detection; calculation is pretty complex and is relatively CPU intensive - For the player the engine cares about the "highest detector" (e.g. the Stealth Meter level calc: determined by the highest detector actor) - Detection is also determined by the summed up weight of all worn items of the detected NPC, the detector's Perception and the Active Effects applied onto the detected NPC ("determined by (...) active effects applied onto the decected NPC": like detected NPC >> worn outfit >> outfit instance data (includes ObjectMods) >> applied enchanements (which are in the actor's Active Effects array, similarly to applied MagicEffects)) - I wrote GetDetectionState, GetActorsDetectedBy(Actor akActor, bool bMustHaveLOS = false) and GetActorsDetecting(Actor akActor, bool bMustHaveLOS = false) for Garden of Eden SE, that's why I know these. Hopefully I remember correctly AI sends a detection event (I think assault alarm) upon detecting an "explosive theat". It's somewhat similar when on a few occasions the combat formula (based on combat timers) calls for one of randomly picked combatant native SayTopic() (on manager "BGSStoryTeller" if you're interested) with the Topic "AvoidTheat". The "send alarm on detecing a hostile mine" behavior is hardcoded. I don't know of any non .dll way to disable it (without editing the ownership of the mine, or MoveTo() it elsewhere and so on).

If you're not looking to make a mod, only change faction relations on your playthrough you can use the console. The wiki site contains the faction IDs. This page the console commands. Look for SetAlly.

This could happen if you have too many items in the Build Menu or the items have very high polygon count / high definition textures. The game loads those previews every time you open the menu or a category which can slow down the menu. 20 seconds is still very interesting. It shouldn't be that many. You can try this F4SE plugin.