LarannKiar

My guess is roombouns and portals but I don't know.. As for the grenade arc, it's called "GranadeTrajectory" in both the game files and the EXE; see game settings fPerkGrenadeTrajectoryStartTangentEndLength and fPerkGrenadeTrajectoryStartTangentStartLength for example. The shader is an actual EffectShader GrenadeTrajectoryFXS [EFSH:001D4761]. Its behavior is mostly hardcoded but I think it's not rendered basically when the game considers the area for it too small.

If the game crashes upon trying to save the issue seems to be that something was loaded in the memory from the previous save (this is a problem: the native save game loader should've dropped the "unavailable data" (i.e. data from removed mod) from the save) which can't be flushed to a new save. Buffout 4 has a crash logger but to interpret the log, you'd probably need dissasemble the EXE to actually identify the issue (this is difficult). I think a bit easier if you open this mod in FO4Edit and edit it, basically to turn off its features so you won't even notice it's running ingame. (This isn't very easy either if you haven't made scripted mods before). As a last resort, you can try contacting the author of Fallrim Tools, they may be willing to help.

There's a vanilla bug that can "lock" the category submenu, preventing one from going back to the main menu. Scrolling down to the bottom of the list or waiting a few seconds after opening the category before attempting to go back may help.

I'm currently testing the plugins and the new version in general and vanilla SFSE doesn't appear to have a project file "hook_api.cpp" and by a quick Windows Explorer search, the error line "minhook failed to hook function" isn't present in any of its files. Are you sure it's not caused by an outdated SFSE plugin? Move the files from ..\Starfield\Data\SFSE\Plugins to another folder and try to launch the game through sfse_loader.exe. (For me SFSE v0.2.4 works without issues).

I just started rebuilding the script extender plugins, will analyze the EXE later. The only info I could find is this: "A small hotfix has just been released to address an issue occasionally causing certain quests to disable, preventing players from continuing those quest lines." It wasn't the first patch for occasionally "softlocking" quests though. One way or another, this issue always shows up, story manager's alias fill code bug, dialogue input bug, conventional quests scripting errors..

I haven't updated yet but both sfse_loader.exe and the .dll must be in the folder where Starfield.exe is, and make sure to launch the game with sfse_loader.exe. And.. so there really is a new update. I've received some posts about an update but "Starfield | Official Website | Bethesda.net" doesn't tell anything.. oh wonderful....

While I know original poster isn't active anymore, for futere reference: The engine wasn't developed for all this yes but had BGS given Starfield worldspaces as content rich and large as in their other titles, beyond a few modders with grandiose custom city and world projects, most people wouldn't even consider this "limitation". Max value of object reference coordinates isn't a limitating factor in practice. In theory, it is but in theory every limit is limit. Also, Starfield uses Meters so 1 "Game Unit" is much larger than 1 unit in Skyrim or Fallout 4. 1., 2.: It's time consuming (expensive) enough for a game developer rather not do it if they think they can release a profitable game without doing so. The code assigns/releases IDs all the time; I don't think the solution in 2024 is to replace uint32_t formIDs with uint64_t ones but to properly implement both the ID remapper or the loader. v1.9.67 is supposed to patch this issue, I haven't compared the two codes though. From my perspective, the Creation Engine is not "inherently bad" or "completely outdated" and Starfield was a huge step toward a "fully 2023 ready" engine which step was required to release a game last year. The engine isn't responsible for the loudest critics either: - procedural generation is a great addition but it's not meant to replace 90% of a handmade game world especially when it was expected from the developer based on their other titles - "from load screen to load screen" is bad design choice, could have been avoided but... draw calls are CPU intensive already. - forced dialogue menu: quickest to implement (less possibility of unexpected player input; helps out the "not always quite nice" character (face) lightning with custom light nodes; etc..) - enclosed menus: easiest (fastest) to make a system of them. 1. create a "template", 2. use the template as a base for the others, 3. reach the others from the template. Less designing required; more immersive menus (e.g., Chronomark UI integration) means more development time; etc.. - character lightning is mostly a result of "fine tuning": they should've invested more time in it (the "new" lightning favors world objects but handplaced light sources still look better on NPCs). - "Chronomark HUD widget" shows gibberish data like 30 Celsius while snowing: whoever thought PlanetData should hold many of the environment data like temperature information wasn't thinking (unfortunately there's no other way to put it). - NPC AI is not a lost cause, the crowd system (without the visual appearance of crowd NPCs which is more of a result of buggy FaceGen and watered down race data like morphs) was a v0.1 toward an AI more suitable for very large number of NPCs (>160 loaded)). 3.: It's not an open source game, no one is able to / allowed to rerelease the game almost enterely differently beyond BGS.

Nice work! As for the 1st person, did you attach the node to the first person body mesh? Or have you tried worn "armors" shown in 1st person? I remember I experimented on the Pip-Boy light node for a script extender project, basically to see how the game code applies the "Pip-Boy glow" to the node's color property based on the color slider in the PauseMenu. (I could read/edit certain NetImmerse data through Papyrus but only in very specific scenarios, haven't made progress since). I think the node in question was BSLight, BGS' own niobject. Maybe you could try that, or BSFadeNode. Edit: sorry, BSLight itself isn't in NifSkope, I meant BSTriShape >> BSLightningShaderProperty / BSEffectShaderProperty.

Certain locations (usually interior cells) are "faction owned" and configured to trigger the combat AI of members of the owner faction if a non-member enters the cell. Technically IF Cell >> Interior data >> non-Public >> THEN SendTrespassAlarm. In SF1Edit, The Lodge is owned by the ConstellationFaction but it is also flagged as "Public Area". According to the wiki (of Skyrim) this flag should turn off the "trespass behavior". (It just "should" because I haven't seen how cell - trespass behavior exactly works in Starfield so I don't know for sure but I see no reason why it would be any different from other BGS games, given the data flags are almost the same). To separate the "Lodge broken" and "bad NPC faction data" scenarios, type [ 5986.MoveTo Player ] to teleport Sarah (but make sure she's not in combat yet) out from the Logde to the exterior area of New Atlantis and see if she attacks any neutral NPC there. If not, the problem is with the Lodge.

The line that starts with "Factions" shows all the FormIDs of the factions. 000191DC is the ConstellationFaction and 00106C30 the PlayerAllyFaction as far as I remember. If the ConstellationFaction would be an enemy to a faction whose ID is 01234567 for example, [ SetAlly 000191DC 01234567 1 ] would make them allies.

I've had playthroughs with the Kid Stuff perk but I haven't heard about or encountered this issue. I suspect this is mod problem but I'm not sure.. Did you mean you started a new game or reinstalled the game itself but kept the previous save games/playthrough? If the latter, then there's a high chance the hostality is caused by a faction data overwrite which is actually ActorReference data and is stored in save games. Most NPCs you see ingame are member of factions, including both the "main factions" like the UC and miscellaneous, rather technical factions like dialogue factions. Mods may add/remove NPCs to/from factions, or change their enemy/friend/ally flags which basically determines the hostality/neutrality/etc. of faction members toward members of other factions. If this is the case, you should be able to change faction data to remove the hostality. I think faction enemy/friend/ally flags can be overwritten in Starfield too with the console commands known from other BGS games: targetID.AddToFaction <faction id> <0 or 1> – Adds target to faction, needs to be used with a prefix or target, e.g. player.AddToFaction 0001c21c 1 to add yourself to the player faction. 0=friend, 1=ally. targetID.RemoveFromFaction <faction id> – Removes target from faction, needs to be used with a prefix or target targetID.removefromallfactions – Removes the target from all factions. Be aware that this will also remove the player character from the "player faction" if used on themself. setally <faction id> <faction id> <0 or 1> <0 or 1> – Makes two factions friendly with each other. 0=friend, 1=ally setenemy <faction id> <faction id> <0 or 1> <0 or 1> – Makes two factions enemies with each other. 0=neutral, 1=enemy If someone's is already shooting, you would need to (first type [ TDetect ] in the console to globally turn off NPC AI detection), then [ ActorReference.StopCombat ] to stop the combat behavior of the target ActorReference like [ 5986.StopCombat ] or click on ("select") Sarah in the console then [ StopCombat ] without the RefID. The problem is, without a custom Papyrus script or mod, it's difficult to know which factions are an NPC is a member of. I made a "Detalied Reference Info - SFSE" mod earlier that adds a native command to the console GetReferenceInfo/GetRefInfo that lists all factions of the target ActorReference.

I just wrote a quick xEdit script to count how many worldspaces have the form component to be used by the content manager. It returned "Number of Worldspaces with BGSPlanetContentManager property = 357" Don't how many of them have "special" conditions but their number is surprisingly large. I think when one travels to a new location they seek to discover something new, unlike when revisiting (intentionally) an already known location. In other BGS games the player can get to choose when to revisit a discovered location and when to "explore the unknown", but not in Starfield (this is kind of ironic). However, when the static worldspace runs out of undiscovered area in other games the player can only visit known locations. I guess this was that the designers originally wanted to improve upon. The problem is that... game world = ~90% repetitive/random + ~10% unique. One ended up on the wrong side which inevitably caused the other one to end up on wrong side too.. But I guess how much the system was used to "solve" the conflict between ~1600 planets / limited development time is another topic... As for me, I don't know why they thought this needed to be improved at all.. they made pretty good locations in the past. Locations that many players obviously "didn't mind" seeing back, even to this day. So... hadn't the last 10 years of the popularity of their games proven that static worldspaces are fine? Though I have to admit, native support for both static and dynamic worldspaces have more possibilities for landscape/location modding.. in theory. Custom POI and even unique locations like Sonny Di Falco's Island will be popular in my opinion too, if the CK proves to be a proper API for them. Personally, I'd be more insterested in creating unique ones (which are actually quite similar to POI locations, just not added to the planet content manager to be randomly generated based on conditions).

This may happen if your FPS is higher than 60. Do you have any mod that uncaps frames per second? Maybe an F4SE plugin or another .dll?

At this point, BGS must have realized they can't impress many players by a recursive/random content generator to "populate" most of the game world. I guess on paper it seemed more.. appealing. (Though I still can't see how making the frequent open/close of fully enclosed menus part of the gameplay or the travel from load screen to load screen design could look well even on paper). A sequel of Starfield.. hmm I was actually thinking about a Starfield 2.0, in which they use their updated code to develop a more "traditionally designed BGS game" most were probably interested in. Needless to say, those games granted BGS that award winning creators' place in the industry.

I don't know the differences between the GOG and Steam version but it should be (INI) Fallout4Custom.ini >> (INI Section) [General] >> (INI key) bBorderRegionsEnabled=0, like: [General] bBorderRegionsEnabled=0 (You can take a look at [General] >> fTooCloseToBorderDistance too (its default value is 1024)). Notes: - Create Fallout4Custom.ini if it doesn't exist - Priority of INI an setting found in both Fallout4Custom.ini and Fallout4.ini: Fallout4Custom.ini > Fallout4.ini. So, if Fallout4.ini contains "bBorderRegionsEnabled=1" too, border regions would still be turned off. - Don't create another instance of the INI section "[General]" if it already exists because only the first one is recognized

I somehow forgot about this post. Yes assembly is part of it too. It can be quite time consuming.. If PauseMenu >> PhotoMode works, you can try manipulating the menu to open PhotoMode for you. Currently SFSE has no Papyrus >> UI script so accessing/editing AS3 variables through Papyrus is not possible. Editing the menu itself might be the easiest option. To do so, you'll need to find the actual function that selects the entry 'PhotoMode' in PauseMenu, select ("highlight") it, then fake a button press or mouse click. I made a "Starfield Console Extender" (SFSE plugin) that has UI >> Invoke function. If you make and add a custom "OpenPhotoMode" to PauseMenu (in JPEXS for example), after opening it with the command "ShowMenu PauseMenu" you should be able to call OpenPhotoMode with Invoke. To call Invoke, you'd need to use Papyrus >> Debug.ExecuteConsole. You can also implement a "pause game time" function by calling the console command SetGlobalTimeMultiplier. Another approach could be locating the Action that starts PhotoMode (if there's any) then invoking it with PlayIdleAction. Triggering certain "partially hardcoded" behavior with PlayIdleAction sometimes work but in many times it doesn't..

Assuming there's no way to trick the game to allow the rarity icons show up on next those objects, I think you'll need to edit the interface file (InventoryMenu maybe) for that. Rarity data is most certainly "sent" by the EXE through some Scaleform object or function parameter. I haven't made a mod for the inventory menu yet so I don't know where it is but you'll probably want to check out the main actionscript which should be named "InventoryMenu". JPEXS Free Flash Decompiler and Adone Animate CC are used for editing interfaces.

Landscape/worldspace modding is usually the most questionable part. Quests, items, NPCs and most game forms haven't been changed as much so they'll be editable in the CK. Content that requires automated processes to build/generate and licensed third party engines are unlikely though. (Despite Havok, on which Starfield highly depends on, has been purchased by Microsoft in late 2015). Certain aspects of Starfield's menus will be editable in the CK too I'm sure, due to the cell renderer.. As far UI modding, interface (.swf) files are Adobe Flash files, Adobe Animate CC can be used for those. BGS relies on Scaleform GFx to communicate with it. (Both Flash and Scaleform are discontinued actually). If I have to guess, I'd say with proper modding support Starfield can become more popular as many of its elements act as a "shell" one can fill up with content. Technically speaking, the game has a lot of potentional for modding already.

Technically you'd need to attach a debugger to the game's process. This would be a C++ project with advanced level of reverse engineering. You're probably right though, ShowMenu only tries to initialize a menu instance with hardcoded menu data but different scenarios like {CurrentFurnitureHasKeyword (PilotSeatKeyword) Run on: Player == True} needs to be handled elsewhere in the code. Certain menus cannot even be opened with it because the EXE crashes if the menu instance is not provided with mandatory data (ContainerMenu comes to my mind). Have you tried exiting first person mode before ShowMenu PhotoModeMenu? This should move the PhotoMode's camera node outside of the ship where the third person camera currently is. Or you'd like to enter PhotoMode in the pilot seat?

At first glance it seems to me the ActiveMagicEffect that applies the invisibility remains on the effect target actor and when you try to remove the effect source the ActiveMagicEffect enters into a "dormant" or "inactive" state but doesn't get properly removed. If you have Better Console, you can quickly see the list of all "Active Effects" applied to the actor. Check that actor's pre-OnEffectStart, post-OnEffectFinished, etc. state. As for using HasPerk, well, generally speaking the perk can easily get "untied" from the active effect, condition functions like HasMagicEffect, HasMagicEffectKeyword, EP(...) like EPAlchemyEffectHasKeyword are more appropriate to be used in Magic Effect >> Target Conditions.

While not exactly a city overhaul, I'm currently finishing up my latest and probably largest SFSE mod for Starfield so far that will more or less replace the crowd system BGS made. It replaces the emotionsless crowd NPCs (element 0 in the array.. :), enables everyone proper facegen, morphs, handles outfit clipping, 1billion+ combinations of random unique names, etc. and will also let people define everything for themselves as well, like adding "unique characters", specifying their armors/outfits, voice types, animation sets (expression and movement), encounter chance.. all selectively for males and females and for each location. Speaking of locations.. are there any places beyond New Atlantis, Akila City, The Well, Cydonia and Neon which have crowd NPCs?

I added OnHitEvent to v17.0 but yes I think I'll take a break too. As for the camera height, GetPlayerEyeHeight() and GetCurrentEyeLevel() are currently implemented, I can probably add SetPlayerEyeHeight(float afHeight) too. Camera coords seem doable as well. And now that I think of it, the only group of variables I excluded from OnHitEvent was the projectile impact data: projectile vector, hit direction and the like. Let me know if these are of interests.

Not currently but I can upload a preview build. I'm planning to add it to the next (rather large) update along with many new global events like OnCombatStateChanged, OnContainerChanged, maybe OnLoadOnUnload. Update: added ~40 variables in total, I'm still testing the Papyrus OnHitEvent.

I looked into it anyway, maybe it'll be useful later. OnHit receives all kinds of attack/hit related data, seems like every "hit type" results in a somewhat different set of input variables.. sometimes the parameters are duplicates of each other, sometimes projectile or akSource is None (while sourceByHandle still points to a ref)... it's no wonder the Papyrus version of OnHit can't always output consistent data. sourceByHandle = technically the source object instance that causes the hit (e.g., Explosion or Projectile instance that lives for only milliseconds, as it's destroyed after OnHit). sourceByHandleBase = not being sent natively, I added it as sourceByHandle.GetBaseObject() so that the source object instance can be identified in FO4Edit... (doesn't always work though, sourceByHandle might be destroyed too early). Garden of Eden currently receives all OnHit events sent by the code (logs even stray bullets that hit a wall, car or ground, etc.) so the log can fill up easily but here's what I could find (based only a few tests). >> The event either points to "MirelurkKingSonicExplosion [EXPL:000EA8F9]" (sourceByHandleBase) or "WeapMirelurkKing "Sonic Attack" [WEAP:000FC3EC]" (akSource) >> akAmmo, akSource, akProjectile are rarely sent by the event, this probably renders perks entries that rely on the akSource weapon unreliable >> hasAttackData should be True on a melee attack (yet no akSource is specified so the code most likely recognizes it by the other parameters) Some example event logs:

Could be caused by something that was spawned/edited during the game at Sanctuary in a way the EXE can't handle. You can try Buffout 4's built-in crash logger but it may not point to a mod.. Do you have any custom settlement objects at Sanctuary? If so, it might worth checking their comment pages, see if someone else already reported it.