LarannKiar

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

You're within the reference handle limit which is 2^21 (here's a link of what this limit is about). (And both the ingame total and persistent object reference (REFR) count seem to be valid; for total actor reference (ACHR) count, ~2000-2,500 would be more appropriate).

I'm not familiar with the boostpack mods but you can try disabling them all, then reenable them one by one while continuously checking whether the pack still works ingame. Edit: forgot "not".

Do you have a "heavy" load order? Unfortunately before offical mod support BGS doesn't really mind modifying form data structures which are usually found in mods as well. After the Creation Kit is released they tend to be a little bit more cautious.

Unfortunately Invoke is underdeveloped, it can only call simple AS3 functions, parameters aren't implemented. Actually, I originally made it for the ClearConsoleLog/ClearLog function that internally calls "root1.AnimHolder_mc.Menu_mc.ClearHistory" to clear the console log as the vanilla ClearConsole/Clear console command is no-op.

I just took a look at the EXE.. it seems like the game performs a strcmp check for sLanguage:General and the getter function only proceeds to find the player address (which is mandatory) if the interface language index (appear to be enumerated, 19 in total) is english (some kind of boolean check for "is localized" it seems). The function references ..\Starfield\Data\Misc\PA.dat (I guess "player address".dat). This is where the list of the supported player names are. About the .dat: human readable file, names are in alphabetical order, in 3 columns either for the three valid player address titles: Male, Female, Unspecified or for the different accents Vasco can spell, I'm not sure.. It's packed in Starfield - Misc.ba2. Supposedly, if you add new names to this file, you can expand the list if Vasco has a matching .wem voice file. (Notes: this is just a theory based a quick reverse engineering, I haven't tried to hack the game code to work with other languages or edited the .dat file to verify it).

Globals are utilized by a few forms such as Quests (see Quest Completion XP, Text Display Globals, UpdateCurrentInstanceGlobal) and Messages (Text Replacements) so sometimes they can't be avoided.

Compress the Textures folder (that should only contain your texture, like ..Textures\Weapons\SomeWeaponName\SomeTextureName.dds) and upload it as .zip. So the important is that the folder structure up to Textures should be preserved.

One would need to reverse engineer everything involved first which currently seem impossible. Basically, one needs to 1) force the game to save all relevant world data during traveling to external files (save games probably won't do), 2) disable the content creator, 3) load (build) everything from the external files at runtime. Unfortunately, even if one finds a way to accomplish this, the external "world data files" would contain many instances of the same vanilla POI locations (linked to the same interior cells too like "Deep Mines") so it won't be able to help with the repetitiveness alone.

Sorry, I overlooked something then..

I think it's in the nif collision but as a workaround, you can place "BldDecoSmFlrOnly01 [STAT:000D4456]" beneath the non workshop object colliding ground.

It's been a while since I made something like this but if I'm remembering right, the keyword "playerCannotEquip [KYWD:001CF299]" needs to be added to the item to make it non-equippable. Here's its dev notes: "For items which we want to appear as lootable, but not usable by the player. (ie: creature armors, other things for which "unplayable" is not quite right)" ("Playable" is an equippable Form data flag (e.g. Weapon) which, if unchecked, can also prevent the player from equipping the item). A Perk with Perk Entry "Activate" can't be used to block equipping a weapon found in the game world. (Maybe it can be used to block taking it with Target Condition: HasKeyword 'playerCannotEquip' == 0, I'm not sure right right, but it surely doesn't make it unequippable). You can't add keywords to non-persistent items directly if they're already in the inventory because vanilla Papyrus doesn't provide any function for this. If there's only instance of this item in the inventory, you can use AttachModToInventoryItem. (Just add the relevant Property Modifier to the ObjectMod to attach a keyword to the item; see mod_armor_Synth_Leg_Material_0 "Standard" [OMOD:00046D9C] and its dn_HasMaterial_0 [KYWD:00182E73] keyword for example). If you want to instantly Unequip the item to prevent it from staying equipped, then here's a quick code that should work or at least point you to the right direction: Scriptname Tier_PerkRestrictions extends ReferenceAlias Group Keywords Keyword Property Tier_Lvl Auto Const EndGroup FormList Property EquippedWeapon Auto Const Weapon Property Equipped Auto Const Event OnItemEquipped(Form akBaseObject, ObjectReference akReference) ; event sent when the reference filled into the RefAlias this script is attached to equips something Actor PlayerRef = Game.GetPlayer() ; store Player variable to be used later in this event to prevent calling Game.GetPlayer() again (to speed up script execution; i.e. no need to "ask" Game script to return the Player reference again) If Self.GetReference() == PlayerRef ; Player is the reference filled into this RefAlias If akBaseObject == Equipped && akBaseObject.HasKeywordInFormList(EquippedWeapon) == true ; akBaseObject of the event OnItemEquipped is the weapon you're looking for AND this akBaseObject has any of the keywords found in the FormList "EquippedWeapon" (Form script function: HasKeywordInFormList) PlayerRef.UnequipItem(akBaseObject) ; then unequip this item EndIf EndIf EndEvent Notes: - the function UnequipItem has a parameter "abPreventEquip", if you intend to set it to True, be careful with it - you can replace akBaseObject.HasKeywordInFormList(EquippedWeapon) with akBaseObject.HasKeyword(Tier_Lvl) if you don't want to use a FormList (i.e. you only have one keyword to check) - both HasKeywordInFormList and HasKeyword work on BaseForm level, not on the object instance level (so you can check what keywords the Weapon form you see in the Creation Kit has with them but if you attach an ObjectMod to an item ("object instance") and that ObjectMod has dn_HasMaterial_0 [KYWD:00182E73] for example, this keyword won't be seen by HasKeywordInFormList or HasKeyword because it's not "form keyword data" but "item instance data").

I remember we've talked in Garden of Eden SE's comments section so if using that is fine, and assuming this is an inventory level project and not something like the Cryopods in Vault 111, maybe PickUpObject() is able to place objects, including NPCs, in containers and actor inventories. ("Maybe" because Starfield's code has an equivalent function and I don't remember whether it could put non-equippable forms into inventories in Fallout or in Starfield but I know it could..). ; # Makes akActor to instantly pick up iCount number of ; # instances of akReferenceToPickUp. Can be essetially used to clone inventory items ; # because the code reattaches all instance data of akReferenceToPickUp to ; # the duplicates. Optionaly abPlayPickUpSound to play the pick up sound. Function PickUpObject(Actor akActor, ObjectReference akReferenceToPickUp, int aiCount, bool abPlayPickUpSound) native global This one's for furnitures but don't know if it works on dead NPCs: ; # Moves akActor instantly to akFurnitureRef (and makes them sit on it) ; # optionally, one can specify the target MarkerID of akFurnitureRef Function MoveActorToFurniture(Actor akActor, ObjectReference akFurnitureRef, int aiMarkerID = 0) native global Of course, if there's a working vanilla way that's preferred but I can't think of anything other than MoveTo either: Disable-->MoveTo-->Enable / perhaps Resurrect-->Disable-->MoveTo-->Enable (assuming the actor ref wasn't flagged as "Starts Dead"). Edit: Actor.SnapIntoInteraction() came into my mind, this function is used by one of the Vertibird Companion AI packages if I'm remembering right. You may want to try that first.

As far as I know the game doesn't have a setting to change the "holotape button" but I think you can edit ..\Fallout 4\Data\Interface\TerminalButtons.swf (should be packed in ..\Fallout 4\Data\Fallout4 - Interface.ba2). Bethesda Archive Extrator and Archive2 can open BA2 files, JPEXS Free Flash Decompiler and Adobe Animate CC (and Adobe Flash) can edit .swf files (modding tools' link). (You can implement a keyboard event).

These could also affect the editability of an NPC's appearance: - Face Template data: FO4Edit >> Non-Player Character (Actor) >> Template Actors >> Traits. Best not to edit templated NPCs; it's recommended to remove templating by copying over facial data from the template to the target NPC in the Creation Kit. - Exported FaceGeom data: stored in .nif (NetImmerse) mesh files (..\Fallout 4\Data\Meshes\Actors\Character\FaceGenData\FaceGeom\{SourceModName}\{FileName.nif}. They're usually in BA2 archives. BA2 ("Bethesda Archive", .ba2) files can be opened with Bethesda Archive Extractor and Archive2 (included with the game: ..\Fallout 4\Tools\Archive2), Nif files with NifSkope. A FaceGeom file's name matches the FormID of the NPC's BaseForm, e.g. 00002F1E.nif for Piper whose BaseID is 00002F1E.

Fallrim Tools but this is probably a mod issue because there's no Mk 5+ Ballistic Weave in the vanilla game. Unfortunately, if you don't have any armor or outfit that already has this modification, finding the source mod could be difficult. If there's no way, you can create a hard save then disable your mods until you find the culprit.

Do you have any SFSE mods? Many script extender plugins apply their changes right after the data handler finishes loading game objects, which takes after ~10 seconds in the Main Menu. If one of them is the issue, you can verify that by opening the game with the vanilla EXE instead of sfse_loader.exe.

Ah, I see. I don't have any ideas how to help with this project unfortunately. Even if a form doesn't get changed during the game, any form can be referenced by Papyrus scripts after a save is loaded so they could end up in a save game anytime. For example if a save was created during a Papyrus loop the form was used in as variable, either the form or more likely its bound script object handle would be flushed into the save.. but I don't know, I haven't experimented with these.

Interesting.. these issues seem to be out of the scope of ActorCause then. The bug I was referring to also affects companions, when they throw a grenade in a settlement for example which, if exploads shortly after the combat is over, may make everyone start combat with the player (and the companion who even "hated that"). I personally haven't tried the Simple Offence Suppression mod but I wonder if it fixes any of these already. It overwrites the vanilla faction combat reaction function. (I don't patch vanilla code in Garden of Eden SE so regardless of whether this bug is in the combat AI or caused by broken ActorCause data it won't be fixed "natively" by it anyway, only through Papyrus if that's possible at all).

Probably but it doesn't seem easy.

I haven't tried to make an "instant survey" mod but the difficulty could be that while Papyrus script (scripting language of BGS games, widely used by mods) has SetTraitKnown and IsTraitKnown functions, it doesn't have "SetSurveyPercent" (only GetSurveyPercent that returns the survey percentage). BGS only exposes functions to Papyrus that they need to make the game. If there really is no other way to flag a planet surveyed then this requested mod would require an SFSE plugin. One has to decode the planet survey percent variable then change it at runtime.

I don't know to be honest, I haven't examined the save loader and manager very much (I avoid writing data directly to saves). The code works something like this: in theory, any Form can be flagged as "changed". This is done by the EXE through a few virtual functions of the Form class. The game writes the changes into a buffer, keeps them in the memory then upon saving, flushes the changes to the save file. Form Lists for example is known to changeable, this ability is even exposed to Papyrus (e.g. AddForm()). Script added forms are stored in another "list" of each FormList that contains such forms. On the other hand, certain Form data isn't loaded into the memory as actual Form data. For example, loose mods (the MiscItems) linked to every craftable ObjectMod are loaded into a separate hash map and are not treated like an "ObjectMod data" despite in mod and master files it seems like as if they were and in both FO4Edit and the Creation Kit loose mods are modifiable in the ObjectMod record. So plugin records and record structures don't really matter. What determines whether a particular Form like a Scene has any variable that can be changed during a game session is that whether the EXE has functions to interpret the changes. Which is unknown as the game is closed source. So one can only try to map the "actually changeable" Form types through test observations. As for Projectiles, Projectile base form is unlikely to be changed but as I said, I can't know for sure.. Projectile references so the actual objects that the player and NPCs shoot for example are short lived IsCreated Object References spawned by the code with a specific, additional Projectile data structure. So they're a special type of Object References (just like Explosion instances by the way). (Bit off topic, I decoded the ActorCause struct of Object References (made Set/GetActorCause) recently that might be of interests, tested on a few thrown grenades but I don't know if they actually be used to fix the related known engine bugs, e.g. random hostality by "friendly" grenade exploading after CombatState = 0). Image space modifiers are stored in saves but they're kind of a "global data" so what image space modifiers were in effect at the time the save was created is not an "Image Space Modifier data" like their Depth of Field values. The code creates "instances" of them similarly to Input Enable Layers then, if there's an instance in the save the game will auto apply them after loading it. Movement Types, I don't think so but active animations performed by NPCs are stored in saves in general... but it's hard to tell exactly how as animation handling looks a bit overcomplicated (though ironcally I see more anim glitches in Starfield than in Fallout..). As for "changeFlags", unlike form flags like the "Non-Playable" or the "Temporary reference" flags (that one can only figure out by examining the integer bits), the EXE contains a handy function that can even prettyprint the changeFlag results. Signiture would look like [ GetFormChangeFlagAsString(int FormChangeFlag, byte FormType, byte ReturnFriendlyName = 1) ]. I added the ability to see the changeFlags in Starfield's GetReferenceInfo but not to Garden of Eden SE.. (maybe later). The result differ depending on what FormType is used. (They are enumerated). ChangeFlag 30 for a Cell form would mean it has "CellDetachTime" (used for Cell reset). Here's a list of the changeFlag values (not decoded or verified by me, I only have the function). By the way, I can post the disassembled function or the formType list if you're interested. Those Forms are likely changeable.

The only functions I can add to this discussion are the [ Set TimeScale to fValue ] and [ SetGlobalTimeMultiplier fValue ]. Set TimeScale to advance game time and SetGlobalTimeMultiplier to speed up time (latter speeds up character movement, animations and voices too..).

If they're a 3rd gen Synth then having the HumanRace in Armor >> Races and Armor Addon >> Races or Additional Races should be enough. For other Synths the Gen 1 or Gen2 Synth Race has to be in the supported races list. Probably the easiest if you find a vanilla Armor that's equippable on Synths then "Copy as new record into..." to a new Armor record to use that as base for a custom lab coat.

Move your SFSE plugins from ..\Starfield\Data\SFSE\Plugins folder to another folder and see if the save can be loaded afterward. Many plugins perform the patches they were coded to once the data handler finishes initializing forms and loading game data like objects rendered in the game world. This process usually completes when the player is about to load a save or maybe after the already selected one to load. If you open the console right after the logo intro ends and type something like TDetect, you may notice the game freezes until the console command is executed. That is because the main thread waits for game data to be loaded. If the game crashes a few seconds later typing the command then it's unlikely the save is corrupted. In v1.10.31 even object references' base object form was realigned (let alone inventory or keyword data) so I guess many plugins were affected. The save loader and data handler (which handles mods as well) were changed too so if it's a plugin issue disable the ones that were released prior to the new update. You can tell their release date by their "Date modified".