LarannKiar

Fill the reference into a Quest Alias (with Fill type Specific reference), save your mod, reopen this quest and remove the quest alias (if you don't need this alias). The Creation Kit won't unset the Persistent flag on the reference. (As for SF1Edit, REFR record >> Record Header >> Persistent).

You could try this code: Scriptname CoolShotRifleScript extends ObjectReference Const ; if it extends ObjectReference, you either need to attach this script to the reference (since PlayerRef 0x14 is hardcoded it's not really an option) or the reference's base form (in which case all object references of this base would inherit this script) Event OnInit() ; sent when this script is initialized ; RegisterForAnimationEvent is a native function so it looks like "bool Function RegisterForAnimationEvent(ObjectReference akSender, string asEventName) native" in ScriptObject.psc; it doesn't have "EndFunction" as it's native: it's only declared in ScriptObject.psc while being defined in the native code ; "Self" is technically this script instance, so an instance of CoolShotRifleScript bound to the object the script is attached to: in this case it is an ObjectReference; the vanilla code automatically casts it to ObjectReference, that's why you don't need to type "Self as ObjectReference" (the first parameter of RegisterForAnimationEvent is ObjectReference) RegisterForAnimationEvent(Self, "weaponFire") EndEvent Function AttachModFunction() ; you could call it "user defined function" Debug.Notification("AttachModFunction called.") EndFunction Event OnAnimationEvent(ObjectReference akSource, string asEventName) ; parameters don't contain the value like Game.GetPlayer() but the type and name, e.g. ObjectReference akSource If akSource == Game.GetPlayer() && asEventName == "weaponFire" ; the anim event is called "weaponFire" as far as I remember AttachModFunction() EndIf EndEvent The notes above the native functions and events in the vanilla .psc (Papyrus script source) files aren't always in depth descriptions so you should take a look at the Creation Kit wiki.

You can all ActorRefID.GetOffersServicesNow in the Console to determine whether the vendor should buy or sell items, e.g. 5986.GetOffersServicesNow.

It is expected yes. I knew Bool wasn't properly implemented in Starfield either but I thought I fixed it earlier.. I added a quick fix to Starfield Engine Fixes, thanks for the heads up. I don't know if someone has already did for Fallout 4 but I added it to my to do list.

Reference 3D and textures aren't kept in the memory when the persistent ref is not in the loaded area regardless of persistence (by Fallout 4, I don't know whether the Creation Kit does but I doubt it). Having too many loose files can increase the loading time of the Creation Kit. I think if you remove the Persistent flag in FO4Edit and it should automatically move the ref to the non persistent Worldspace record.

There seem to be several conditions of the "excess dead" cleanup but I can't see anything related to their Encounter Zone. The cleanup code looks for Quest Alias data which ApplyToRef() adds to the reference. I don't know if it gets removed OnDeath() so maybe this is the why they can't be removed. I'll look into this later.

It seems to me the native code intentionally does this so I think it is to help/speed up development. When the developers need to make a large amounts of references, quests, etc., the ability to MoveTo() basically any of them is probably very handy. Out of curiosity, I made an F4SE plugin now and bypassed the Master flag check.. the game could load, ESM order in the load order got messed up and distant refs from an ESP weren't loaded.

1) WorkshopMaxDraws [AVIF:0000034B] and WorkshopMaxTriangles [AVIF:00000349]. You can increase them but excessive draw calls can cause stuttering. 2) Not a workshop specific limit but various actor related processes like face gen, AI would probably hit their hardcoded limits if there are too many actors in the loaded area.

Change the footstep sound of the Power Armor frame Armor Addon, e.g. AAPowerArmorFrameAtomCat [ARMA:001909D2] >> SNDD - Footstep Sound >> FSTArmorPowerFootstepSet [FSTS:00021ADC] to another Footstep Set record. As far as I remember, the Power Armor frame that gets equipped on the player when they enter a Power Armor is hardcoded (more specifically referenced by the Default Object PowerArmorDefaultFrameArmor_DO [DFOB:0015503E]) so I'm not sure you can change the footstep sound per armor frame.

"Cleaning" save games externally or statically (i.e. when the game is not running) is particularly difficult as the necessary information (basically the answer to the question whether it is safe to delete) may not be available (i.e. the developer can't ask the game). What the engine would need in my opinion is more safeguards to prevent runtime created objects (not only object references) filling up save games. Actually, there are, both in the save loader and in native managers but unfortunately they're still not enough. They would need to be implemented into various classes which requires a lot of time from the developers. Once DLCs and official Creations (in the upcoming months or years) cause the game to slow down (stutter) very quickly (i.e not after Level 50 but Level 10), BGS may need to release an update for this issue.

It would require an SFSE plugin and someone to completely reverse engineer spaceships. Technically, their Generic Base Form class with the base form components and the native apply ship parts functions. If we don't count UI design, I think it shouldn't take more than a few hours for a single BGS developer to write two functions that export and import ship parts from JSON for example but without having access to the game engine's project files, it is considerably more difficult and time consuming. I personally don't have interest in this project but maybe sometime.

You can try this script. I haven't tested it but you'll probably need to write something like this.

It is hardcoded in the EXE. Game Setting uVehicleUnlockPrice (default is 25000).

The Actor Background Process Patches (part of the optional feature Engine Load Optimizations of Starfield Engine Fixes) had some sort of conflict with mods that affected companion AI. I added the Compatibility Mode in v5.5 and haven't received reports about this issue since. See bEngineLoadOptimizerActorBackgroundProcessPatchesCompatibilityMode. (It's still the longest setting but this was the only way to keep the setting names consistent). It could be caused by something else as v5.5 was released in October for v1.14.70.

You may have "esp" in the file path instead of "esm". E.g. \Data\sound\voice\ModName.esp\robotmodelavasco instead of \Data\sound\voice\ModName.esm\robotmodelavasco.