LarannKiar

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).

Do you have F4SE? If so, try launching the game with the vanilla Fallout4.exe. If it doesn't crash, the issue is probably with an F4SE mod (could be a conflict, version mismatch and so on).

I don't think you can query "Items stored in the Workbench." in vanilla Papyrus or through a Condition function. (It gave me the idea to make some custom functions for them though ) Form[] Function GetWorkshopStoredForms(ObjectReference akWorkshopRef) native global Int[] Function GetWorkshopStoredFormsCount(ObjectReference akWorkshopRef) native global I can write a simple Quest script function later for a Condition e.g. GetGlobalValue check to detect whether you have a stored item but I'll need to test these functions more first..

Due to the upcoming Next-Gen update, I took a deeper look at Papyrus, the compiler and the VM.. I'm currently making some Papyrus functions to help with diagnosing any possible script related changes.. I'll likely add these to Garden of Eden SE v17.4:

You can't log in if you're not from BGS but I don't know.. it's been unavailable since February I think. You can use the mirror site.

No, "appmanifest_413150.acf" in the original post was a typo. 413150 is the AppID of Stardew Valley. The AppID of Fallout 4 is 377160, so you need to look for "appmanifest_377160.acf". The default path is: C:\Program Files\Steam\steamapps\appmanifest_377160.acf

C:\Program Files\Steam\steamapps\appmanifest_377160.acf is the default path. 377160 is the AppID of Fallout 4.

You can see the current vanilla Fallout 4 files (EXE version: 1.10.163; "Patch 1.34"; released on 4th of December 2019) in these Depots: Depot 377162 (.exe) Depot ID 377162 Build ID 4460038 Manifest ID 5847529232406005096 Creation date 3 December 2019 – 22:32:20 UTC (4 years ago) Last update 18 July 2020 – 09:13:59 UTC (4 years ago) Size on disk 62.47 MiB Compressed size 48.11 MiB Depot 377161 (content_a) Depot ID 377161 Build ID 4460038 Manifest ID 7497069378349273908 Creation date 11 March 2019 – 17:00:26 UTC (5 years ago) Last update 18 July 2020 – 09:13:58 UTC (4 years ago) Size on disk 5.67 GiB Compressed size 5.21 GiB Depot 377163 (content_b) Depot ID 377163 Build ID 4460038 Manifest ID 5819088023757897745 Creation date 4 December 2019 – 21:26:42 UTC (4 years ago) Last update 18 July 2020 – 09:13:59 UTC (4 years ago) Size on disk 18.20 GiB Compressed size 17.60 GiB I don't know about the GOG version but I think the number and the names of the game files can't be very different (aside from "steam_api64.dll" and the like). If you make a backup of these files, you can always revert back later. You can also make a backup of: ..\Documents\My Games\Fallout4 %LOCALAPPDATA%\Fallout4 ..\steamapps\appmanifest_377160.acf ..\steamapps\common\Fallout 4\f4se_1_10_163.dll ..\steamapps\common\Fallout 4\f4se_loader.exe In case the Steam update removes your save files, here's where Steam moves them to. You can refer to this guide on how to download game files using the Steam Console.

I haven't tried to make ships invincible, a few ideas: - ShipRefID.SetEssential(True) ( Papyrus >> SpaceshipReference.psc ) - SetEssential ShipBaseID 1 ( Console >> function [SetEssential BaseID EssentialState]) - ShipRefID.SetGhost(True) ( Papyrus >> SpaceshipReference.psc ; also has Console equivalent ) - ShipRefID.SetAV Health 10000 ( Console >> function [SetAV ActorValue Value] ; has Papyrus equivalant: SetValue >> ObjectReference.psc ) - ShipRefID.SetProtected(True) ( Papyrus >> SpaceshipReference.psc ; also has Console equivalent ) Notes: - you can use Papyrus Actor events OnEnterShipInterior and OnExitShipInterior to apply/remove changes - if you're in a ship, type GetSpaceship in the console to see the ship's RefID - I advise against editing ActorValue forms directly in SF1Edit as they may be used by more Object References

Honestly, I don't know. I have a few guesses but I can't verify whether they're true so I rather not spread possibly false info. I can only say that the affected code was edited multiple times by BGS to fix vanilla bugs and mod support wasn't a priority. Make the game load plugins on top of the two official master files is the very first step but it's the vanilla code that has to initialize every form found in the plugins records and the save game properly and be able to handle all the load, i.e. have allocated resources required for it. Since BGS edited the save loader too, it's difficult to determine exactly what mod added records and saved data the updated code couldn't handle.

We don't know many about the update.. but as far as speculations go: "widescreen and ultra-widescreen support" ----> probably EXE level; note: most menus of Starfield (most recent BGS game, late 2023) don't support 21:9, the renderer is hardcoded to switch to 16:9 on menu open; this shouldn't affect most mods, maybe a few F4SE pugins. "fixes to Creation Kit and (...)" ----> there's a chance mods saved with the upcoming CK cannot be loaded by the current (v1.10.163) EXE due to higher Version Control Info (version data stored in every mod file). Assuming this turns out to be true ---> if developers don't expand the FormID range (they did in 2019) or modify mod file format in a way that requires more than editing Version Control Info in FO4Edit to make the current v1.10.163 EXE load them, then people shouldn't have issues (and modders might be more willing to release optional files for previous game versions, as renumbering FormIDs after the 2019 CK update hasn't became very common). Of course, the most convenient would be if the CK fixes don't affect mod files at all. "will receive stability, mods and bug fixes" ----> if it means engine fixes, then this might mean more work for F4SE plugin authors who made custom engine fixes in the past few years as there's a chance BGS touched the buggy code ---> this could increase the time required to update these plugins "This free update includes native applications for PlayStation 5 and Xbox Series X|S, Performance mode and Quality mode settings, as well as stability improvements and fixes. Experience up to 60 FPS and increased resolutions!" ----> "60 FPS" is bold in the recent official post; it's under the consoles section but it worth mentioning that 120 FPS for PC isn't mentioned in the post. (Fallout 76 released in 2018 had native 120 FPS support as far as I know). Starfield's menus are limited to 30 FPS (even the ones that feature contanst looping animations) so I'd say even if BGS add 120 FPS support it is unlikely interface mods (the interface files themselves) will need to be recompiled, updated. Notes: for more DLCs, the devs edited the interface files which broke interface mods (e.g. they added new map markers to the PipBoy menu for Far Harbor; broken interface mods have a high chance to crash the game). Native 120 FPS support may affect mods that feature custom animations. "For Japanese and Chinese language players on PC, Bethesda.net login issues have been resolved, fixing access to mods." ----> the interface language getter function and the built in MainMenu mod manager is hardcoded in the EXE, however, simple fixes shouldn't break the loader at all. If it does (something like this happened in the past), then it would affect all mods and BGS would probably release a hotfix shortly after the update. "including the following free Creation Club items! (...)" ; In this new quest, “Echoes of the Past”; "Along with workshop items" ----> previously, for Creation Club (CC) content BGS added some new records to Fallout4.esm (e.g. an Attach Parent slot to the Armor Workbench so "Pip-Boy skins" added by CC content can show up). This doesn't mean vanilla records of the .esm (that many mods depend on) will be edited. "(...) and a variety of quest updates." ----> this might mean vanilla records of the .esm (that many mods depend on) will be edited; this may affect mods that heavily relies on / edits vanilla records such as UFO4P. By the way, it's strange in 2022 BGS posted about "Fallout 4 Going Next-Gen" and "Prepare for the future: A next-gen update is coming to Fallout 4!" but in their recent post they seem to actively avoid using these words for the update. They wrote "Fallout 4 is Getting Free Updates" instead and Next-Gen is used like "Experience Fallout 4 on your next-generation PC with widescreen and ultra-widescreen support" "FALLOUT 4 UPGRADES ARE COMING TO NEXT-GEN CONSOLES".

All vanilla Misc Items that come with Habs are regenerated by the game code after a while. Completing one or two even quests usually provides enough time. Modify your ship if it doesn't happen for some reason, that should reset the timer. Player placed items won't respawn.

I was interested in it too so I checked the code.. In short, it doesn't seem so. Some technical details: - Editor added ("drag and dropped") Forms (including Object References) as well as script added BaseForms are directly held in the FormList's primary internal array (Form array). ( theList.AddForm(PiperRef.GetBaseObject()) would be added to this one for example ). - the Creation Kit flags drag and dropped references persistent so that the game can properly build the Form array during the initialization process - Script added references' RefIDs are held in a secondary array (RefID array). ( theList.AddForm(PiperRef) would be added to this one ). - The function that loops the arrays for the elements just searches the second one for a matching FormID, the first one for a matching Form ( IsInList is technically based on ( if FormList.Find(akForm) >= 0, then return 1.00 )) . - IsInList iterates the RefID array actually but it passes SubjectRef.GetBaseObject to the native Find function ( ) unlike Papyrus' HasForm and Find which passes the reference (thus, they work with references.. at least as long as they're referencable in Papyrus, i.e. loaded or unloaded but persistent) - so, if theFormList would contain "CompanionPiper" [0x2F1E], then it would return 1.00 for Run on: Subject == PiperRef [0x2F1F] - FormList.AddForm( some reference) doesn't cause persistence: - one cannot call theList.HasForm( some unloaded non-persistent reference) even if the FormList's RefID array contains the RefID - "even if the FormList's RefID array contains the RefID" ---> it does, RefIDs don't get cleared: - not even OnUnload, or after Delete() or MarkForDelete.. so the formID gets baked in (the save file...) - AddForm( some IsCreated reference ) could lead to unexpected behavior as the 0xFF RefID might get cleared and remapped (i.e. yesterday it belonged to a "Trader" actor reference from a Random Encounter quest, today it points to a "Vampiric Bloodbug" from another RE quest...). Notes: - IsInList can be called in the console - IsEnableParent, HasEnableParent, GetEnableParent and NumScriptAddedForms ( returns formIDArray.Length ) are in Garden of Eden SE if multiple dependency isn't an issue... - let me know if a function like ( Int[] Function GetScriptAddedFormsIDs(FormList akList) native global ) is of interest

FO4Edit >> REFR (of DOOR) >> XTEL - Teleport Destination: Door. It is extra data indeed. Class DoorTeleportData holds the variables for load doors, linkeDoorRef.MoveTo alone isn't suppose to retarget teleport destination. Editing navmesh portal data is technically possible but in reality, outside of the CK (which has the proper implementation for it), it's extremely difficult to correctly edit them in a custom code. (If script extenders are of interests, I can take a look at the destination coordinates later).

One can't update then reupload an F4SE mod without permission but the authors of the most recognized F4SE plugins like LooksMenu, Better Console and Photo Mode haven't been retired. They release SFSE mods nowadays. I don't think they'd abandon their earlier projects.

Function GetPerkRank() is not exposed to Papyrus but you can utilize it through ConditionForms. Create 4 ConditionForms in SF1Edit, each one should have only one condition item at Condition #0. Condition data ---> Type: Equal to; Comparison Value: X; Function: GetPerkRank; Perk: YourPerk; Run on: Subject. X = the PerkRank you want the ConditionForm to look for. So, by creating 4 ConditionForms with Comparison values 1, 2, 3, 4, only one ConditionForm would return True. And the one that returns True tells the PerkRank of theTargetReference. In Papyrus: ConditionForm HasPerkRank1 = (Game.GetFormFromFile(0x123, "YourMod.esp") as ConditionForm) ConditionForm HasPerkRank2 = (Game.GetFormFromFile(0x456, "YourMod.esp") as ConditionForm) If HasPerkRank1.IsTrue(theTargetReference, theTargetReference) Debug.MessageBox("theTargetReference has Rank 1 of the perk defined in the ConditionForm data") ElseIf HasPerkRank2.IsTrue(theTargetReference, theTargetReference) Debug.MessageBox("theTargetReference has Rank 2 of the perk defined in the ConditionForm data") EndIf 0x123 and 0x456 ---> replace these with the FormIDs of the ConditionForms "YourMod.esp" ---> replace with the name of the where this ConditionForm lives theTargetReference ---> replace with the Actor Reference you want the ConditionForm function GetPerkRank to be called on

If the shader is an EffectShader form, you can use Play() and Stop(). theEffectShader.Play(theTargetReference, -1.0) theEffectShader.Stop(theTargetReference)

Vanilla Console.swf has "ClearHistory", I call it from the SFSE plugin.

All right, I got back to Starfield and finished decoding the name functions.. Yes. I added "Brittany Brittany Brittany" to "pa.dat" at line 125, right between the lines "Brigner Brigner Brigner" and "Brock Brock Brock". (Brittany isn't in the vanilla name list). Then I extracted the Vasco's vanilla voice file "howard.wem" from "Starfield - Voices02.ba2". Renamed it to "brittany.wem". Full file path: ..\Starfield\Data\sound\voice\starfield.esm\robotmodelavasco\brittany.wem Vasco could address a player named Brittany. (Of course, "Captain Howard" was recorded in the file but after enabling subtitles "Captain. Brittany" could be read so extending the name list by editing "pa.dat" is possible). I made a simple SFSE plugin that patches the vanilla code for other languages. It works like this: - get the interface language: read it from its INI setting sLanguage:General - get the index of this language by calling the native function BGS made - locate the player address getter function then patch that portion of its code that short-circuits it if the interface language is not English - "patch that portion of its code": use the actual language index defined in sLanguage:General instead of the hardcoded value of English (index = 1) so that function always proceeds to get the player's name Limitations: - the plugin patches the code only once, right after game data is loaded into the memory; if one changes the language ingame, the code will compare it to the old value so it won't work - this issue is only theoretical because changing the interface language for example with [SetINI "sLanguage:General fr] is technically allowed but it won't do anything: interface language cannot be changed ingame; sLanguage:General must be set before the game is opened Notes: - the plugin is address independent (I kept the plugin environment for earlier EXE versions, the affected functions haven't been changed and I don't think BGS would change it anytime soon) - I tested the plugin with French and German languages, not all.. - I may upload it later though I'm not sure many would be interested Update: released the plugin, "Native Player Name Support for Vasco in Localized Game Versions".