LarannKiar

You can move the BA2s which have the updated format to another folder. FO4Edit only can't open the BA2s, I think.

You can keep the earlier version, it'll take some time for modders to update their mods. If you'd like to try out the new update, install Fallout 4 in another folder and either play vanilla or enable only those mods which are not F4SE dependent.

I've been comparing the two EXEs for a while now.. the technical differences are quite large, which makes binary diffing... tedious. I also checked a few form data structures (References, Actors, Armors; 3 form classes of ~150) and they didn't really change which hopefully means most plugins will be updated. Haven't looked into Papyrus engine yet but the assembler and compiler provided with the updated Creation Kit are the same as the pre-update ones.

BGS changed the BA2 (archive) format. I just recreated the archive of my Recruit Jenny mod with the updated Archive2, the offical dev tool to create archives beyond the Creation Kit. Since Recruit Jenny contains voice assets as well, I chose Compression: None, everything was left on default. The pre-update EXE (v1.10.163) couldn't load the archive (quest script wasn't detected, Jenny had no voice) but it didn't crash. I opened the .esp of Recruit Jenny with the updated Creation Kit, then saved it. The pre-update EXE (v1.10.163) could load it fine (mod file Header Version didn't change either). (The post-update EXE (v1.10.980) can load earlier BA2 files, they can be used for pre/post update compatibility).

Conceptually and structurally they are quite similar. I only have actual modding experience from Fallout regarding MagicEffects (especially Cloak Effects) but I decoded the Starfield's ActiveEffect structure for my "Get Detailed Reference Info" mod and it seems BGS made improvements to MagicEffects regarding performance. But something to keep in mind is that they're more resource hungry than RefColls, like they've always been. I understand, and yes.. that can be quite inconvenient unfortunately. On the bright side, these functions, that became available in vanilla Starfield Papyrus, may prove useful: RefCollectionAlias.psc: Actor[] Function GetActorArray() Native ObjectReference[] Function GetArray() Native

That's interesting.. well, I've never tried to exclude Invulnerable actors as far as I can remember but.. if I understand correctly, there are two quests, QuestA and QuestB. The RefColl fill of QuestA finds many actors, including the Invulnerable one, then it adds a Keyword call it "KeywordA" to the found actor refs and also keeps them in Self. Then the RefColl fill of QuestB, which has condition HasKeyword "KeywordA" == 0 Run on: Subject, still finds the Invulnerable actor. - What's the timeframe between the two RefColl fills? Is QuestB shortly follows QuestA? - How are the quests started? From a script, Start() or SendStoryEvent() or SendStoryEventAndWait()? If a script, one of multiple parallelly running scripts? ActiveMagicEffects maybe? Or editor defined Story Quest node? - How's the Keyword exactly applied onto the actors? "Alias Keywords"? AddKeyword() or maybe Alias >> "Apply To Ref"? Will need to set up a test environment for this later..

Do you have F4SE or F4SE mods? If so, launch the game with the vanilla EXE and see if it still crashes. If it does, disable your mods to check if it's a mod issue (crashes could be caused by a driver too).

None that I know of. Why do you need one script for each reference by the way? Processing speed or timers? As far as I remember, AttachPapyrusScript doesn't set const properties to the variables defined in the editor which makes it unusable for many vanilla scripts as one cannot "fill" the const property later. How the VM clears the Papyrus object if it was attached with AttachPapyrusScript I don't know.. I personally wouldn't use it without extensive testing (even though it doesn't seem dangerous). The best tool to see certain data stored in saves is Fallrim Tools. If you'd like to examine the effects of AttachPapyrusScript, you can call it on a reference, create a save, open it with Fallrim Tools then locate the reference, (keep Fallrim Tools open), reopen the game, then call MarkForDelete for example to remove the reference. Verify it's removed with "Prid RefID" (console posts an error if no ref caould be found with the given ID). Create another save, then compare the saves in Fallrim Tools. Alternatively, you can request the VM to attach a script normally (e.g. by filling it to a script variable) then compare the script objects in the saves.

FaceRipper reads appearance data from the save file while LooksMenu from the game process memory. LooksMenu requires F4SE, both saves to/reads JSON but only FaceRipper can save to a plugin (format can be .esp or .esp as far as I know). Are you sure you can't select the Player from the dropdown menu in FaceRipper? It should work. By the way, it's not impossible that FaceRipper needs to be updated too after the Next-Gen update.

I'm not sure if you can access DataObj without naming it. UI functions can navigate through names and this object is created in PipBoyMenu() ---> this.DataObj = new Pipboy_DataObj(); But I don't see if it receives a name, in which case it'd keep its default generated instance name a like "instance46" or something. (Would change every time the object is created and destructed). By the way, this would return "Data_tf": Debug.MessageBox(UI.Get("PipboyMenu", "root1.Menu_mc.Header_mc.PageHeader_mc.DATA_tf.name")) See the menu hierarchy in JPEXS >> Sprites and the action scripts. ( For Caps, you can use Papyrus: Game.GetPlayer().GetItemCount(Game.GetCaps()) ).

OnLoad can be used for objects you have foll control over, like custom workshop objects you made. And yes, you'd need to attach a script to these objects. Take a look at the vanilla workshop scripts, they rely on OnLoad as well. If you know what objects a script with OnLoad is attached to and what to expect, they won't cause heavy script load. (OnLoad was meant for scenarios like items requiring special handling for mod compatibility and such). Since WorkshopObjectScript is already attached to buildable objects as well, for a "catch all" event WorkshopObjectBuilt is preferred.

Yes, getting the var path that can be sometimes... tricky, and time consuming. As for "_singleItemInspectMode", that's a private var in ExamineMenu.swf which can't be accessed by Get (or Set either). You'd need to edit this variable in action script: replace "private" with "public". Personally, the best "universal" approach to find variable paths I have found so far is: - editing the AS3 script of the menu's .swf file in Adobe Animate or JPEXS: - add trace() function calls like trace(this.parent.name) to get the "path to the variable" you're looking for (put the trace() functions in ExamineMenu.as for example then call it from Papyrus with UI.Invoke()), - then use the game's GFx logging (which can be enabled with and accessed through F4SE, see F4SE >> src >> f4se_whatsnew.txt >> bEnableGFXLog) to see the path in the F4SE log (..\Documents\My Games\Fallout4\F4SE\f4se.log). Now, I can't find my Invoke() callable GetAS3VarPath function anywhere... but you'll need to write something like this. If you have Starfield, I've made plenty of UI mods that use the native equivalent of Get (BGS uses Scaleform and ExternalInterface for AS3 - C++ communication; I named the function GetAS3Variable), I can send a few working examples like: GETAS3VARIABLE "WorkshopMenu root1.Menu_mc.BuildItemCard_mc.NameSection_mc.Name_mc.Text_tf.text" ; name of the item to be placed in Workshop Build Mode

Custom event OnWorkshopObjectBuilt is sent for any object placed in the Workshop Menu (if WorkshopObjectScript is attached to them; see the event sender function "BuildObjectPUBLIC" in WorkshopParentScript). ; Register Event OnQuestInit() Quest WorkshopParent = Game.GetFormFromFile(0x0002058E, "Fallout4.esm") as Quest RegisterForCustomEvent(WorkshopParent as WorkshopParentScript, "WorkshopObjectBuilt") EndEvent ; Receive Event WorkshopParentScript.WorkshopObjectBuilt(WorkshopParentScript akSender, var[] arguments) ; kargs[0] = newWorkshopObject ; kargs[1] = workshopRef ; Variables ObjectReference newWorkshopObject = arguments[0] as ObjectReference ObjectReference workshopRef = arguments[1] as ObjectReference ; ... EndEvent For items spawned by mods (e.g. with PlaceAtMe()) then get linked to the workshop workbench reference ("workshopRef"), this event is not sent. For them, you can use OnLoad() with if statements, to determine they got 3D loaded because they were just built and not because the player entered the area, UI.IsMenuOpen("WorkshopMenu"), used along with a PlayerRef.GetDistance(newWorkshopObject) < {MaxReasonableObjectBuildDistance}. If you'd like to avoid F4SE depenency, you can store the IsMenuOpen state of WorkshopMenu with OnMenuOpenCloseEvent in a script variable for example. Notes: - the workshop system is considerably complex, it may be a bit overwhelming if you're new to Papyrus - test your script in vanilla environment (vanilla workshop scripts, no mods enabled, etc.) in case the "WorkshopObjectBuilt doesn't being sent for all workshop objects" issue is caused by a mod

In their current states: GetScriptObjectTypes return all form typed ScriptObjects the engine knows in a String[]. These are scripts objects designed to be attached to game objects, e.g. "F4SE" is not in the list but "Form", "RefCollectionAlias" and "ActiveMagicEffect" are. LogScriptObjects logs all Papyrus script objects (the instances) existing in the memory and tries to locate the BoundGameObjects they're attached to. Native VM functions sometimes (seem intentionally?) don't locate the game object though ("unattached Script instances"?) that's why the many "IsValid" checks. LogScriptsData iterates the map of compiled scripts, then loops through the scripts' functions and events one by one to output some data. Instruction opcodes are not in the output. All functions query the VM to for script data that was loaded in the memory by the vanilla code. They, especially LogScriptsData, were actually made to help me identify possible changes to vanilla Papyrus scripts. If BGS decides to edit some then recompile all, it might prove difficult to determine which ones were actually edited, and how. Comparing the scripts pre-post update may reveal these.. Beyond that, having access to script instances and objects can help with identifying or maybe even debugging bad script data ("Set" and "Remove" functions we be a bit too ambitious though..). GOESE functions are located by the code through the Address Library, including the event dispatchers. The Address Library will (supposedly) greatly speed up things. I don't know if BGS changed class structures.

You can overwrite PowerArmorBodyPartData but take into account that it may affect all NPCs who are in a Power Armor. As far as I know, you can't make a separate, unique Power Armor Race for one NPC though. (I might be wrong, I've never tried it. Maybe F4SE DefaultObject >> Set() can be of help).