![]()
|
|
Related Issues: 34174
This person had the issue but fixed it with the process described and all is working again. As it's not happening to us, we have no means to diagnose it.
I'm not using Vortex, I'm using the latest dev build of Mod Organizer 2. Nevertheless, I think I figured out what's happening. I'll try to explain as best as I can.
First, I did a fresh reinstall of Starfield. As in completely fresh — I deleted the whole Starfield folder from steamapps/common/, then the data from the MyGames folder, except for saves. Then I started a new game plus with only Bethesda Creations (Blackout Drumbeat, Gravis Suit, TA Vulture quest, Observatory). Went to New Homestead, talked to technician... no crash when cycling NG-20. Then I added USFP. Still no CTD. Then I added other mods. Crashed when cycling NG-20.
Then, I started the game again, but before loading up my save, I went into the Creations menu and rearranged my load order. Really all I did was nudge a load order agnostic mod up one space. Loaded up the save — did not crash when cycling NG-20.
My theory: each time a person adds a new master file - regardless of whether they got it from Nexus or Creations - they need to rearrange their load order in game, as a sort of way to confirm/self-correct forms to the engine itself. Vortex and Mod Organizer 2 can do preliminary sorting for .esms, but you actually have to go into the Creations menu itself to finalize it. Otherwise, they'll get issues such as mine, PC or Xbox.
I understand this theory might be subject to skepticism, but I went through this process several times. I am almost certain that you have to reorganize your load order in Starfield itself whenever a new .esm is added in order to prevent issues. Please ask me questions if elaboration is needed.
First, I did a fresh reinstall of Starfield. As in completely fresh — I deleted the whole Starfield folder from steamapps/common/, then the data from the MyGames folder, except for saves. Then I started a new game plus with only Bethesda Creations (Blackout Drumbeat, Gravis Suit, TA Vulture quest, Observatory). Went to New Homestead, talked to technician... no crash when cycling NG-20. Then I added USFP. Still no CTD. Then I added other mods. Crashed when cycling NG-20.
Then, I started the game again, but before loading up my save, I went into the Creations menu and rearranged my load order. Really all I did was nudge a load order agnostic mod up one space. Loaded up the save — did not crash when cycling NG-20.
My theory: each time a person adds a new master file - regardless of whether they got it from Nexus or Creations - they need to rearrange their load order in game, as a sort of way to confirm/self-correct forms to the engine itself. Vortex and Mod Organizer 2 can do preliminary sorting for .esms, but you actually have to go into the Creations menu itself to finalize it. Otherwise, they'll get issues such as mine, PC or Xbox.
I understand this theory might be subject to skepticism, but I went through this process several times. I am almost certain that you have to reorganize your load order in Starfield itself whenever a new .esm is added in order to prevent issues. Please ask me questions if elaboration is needed.
Comment #2 Jun 24, 2024 3:23 pm
Edited by Univus on Jun 24, 2024 3:41 pm
Curious... Both Arthmoor and I, who have not had this NG20 bug, both use Wrye Bash's Starfield-compatible dev builds and have never had to do this. I wonder what Bash is doing that Vortex and MO2 aren't, if any, that would prevent this from affecting us.
I primarily use Wrye Bash in all things BGS because it's been nearly 20 years and it's never failed me.
That said, for load order testing on USFP with official content I have tried both WB and the built-in manager to deal with things and thus far have no issues with the NG20 parts. I in fact put it through fairly extensive testing because we all had to be sure there weren't any weird version specific mesh issues lurking.
You also said that you added USFP and got no crash. Then added "other mods" and after that it began crashing. Which mods might those be?
I'm personally using the Blackout Drumbeat, Starborn Gravis Suit, Observatory, and the paid Vulture quest. Plus 2 other mods of my own making, only one of which has been released so far.
Users on XBox have no choice but to use the built in manager to deal with their mods so I don't see why they'd ever run into this kind of thing if using that fixes the problem.
That said, for load order testing on USFP with official content I have tried both WB and the built-in manager to deal with things and thus far have no issues with the NG20 parts. I in fact put it through fairly extensive testing because we all had to be sure there weren't any weird version specific mesh issues lurking.
You also said that you added USFP and got no crash. Then added "other mods" and after that it began crashing. Which mods might those be?
I'm personally using the Blackout Drumbeat, Starborn Gravis Suit, Observatory, and the paid Vulture quest. Plus 2 other mods of my own making, only one of which has been released so far.
Users on XBox have no choice but to use the built in manager to deal with their mods so I don't see why they'd ever run into this kind of thing if using that fixes the problem.
The "other mods" are the ones by Deebz and a few of my own (not the increased ship ranges and traits mods).
Again, I must emphasize — it's not the mods in and of themselves that are the issue. As I said in the original post, I was getting crashes using just USFP. And (mentioning this now) I had other mods without USFP, but introducing USFP after the fact would make trying to select the NG-20 cause CTDs.
It's the installation/uninstallation of mods without adjusting one's load order that causes crashes. It is critically important that one makes this text box appear whenever your load order changes. This data reload can be prompted by simply toggling any one mod in the Creations mod manager off and on. Installing/uninstalling a mod without getting the data to reload will cause issues, such as the crashing I was experiencing.
I'm sorry if my explanation seems a bit opaque (I'm aware that my theory sounds borderline superstitious), but I'm just trying to be as matter of fact as I can. Really, this should be affecting people who download off Nexus more than Creations, since using an external mod manager does not prompt the autoreloading. Despite this, it did happen to that one Xbox user I linked in the original post, so... I guess everyone should be wary.
Again, I must emphasize — it's not the mods in and of themselves that are the issue. As I said in the original post, I was getting crashes using just USFP. And (mentioning this now) I had other mods without USFP, but introducing USFP after the fact would make trying to select the NG-20 cause CTDs.
It's the installation/uninstallation of mods without adjusting one's load order that causes crashes. It is critically important that one makes this text box appear whenever your load order changes. This data reload can be prompted by simply toggling any one mod in the Creations mod manager off and on. Installing/uninstalling a mod without getting the data to reload will cause issues, such as the crashing I was experiencing.
I'm sorry if my explanation seems a bit opaque (I'm aware that my theory sounds borderline superstitious), but I'm just trying to be as matter of fact as I can. Really, this should be affecting people who download off Nexus more than Creations, since using an external mod manager does not prompt the autoreloading. Despite this, it did happen to that one Xbox user I linked in the original post, so... I guess everyone should be wary.
Comment #5 Jun 24, 2024 6:31 pm
Edited by Univus on Jun 24, 2024 6:37 pm
I haven't tripped that box since shortly after Bethesda released their freebies and although I obviously downloaded them in the built in menu, I did not activate or set their order that way. I used Wrye Bash. The game suffers no CTDs when messing with the NG20 modules.
So I do not think that it's valid blanket advice to insist people go into the menu. That may have worked for you, but that also doesn't make it a universal solution for everyone.
As far as sourcing information, I'd be extremely wary of accepting anything offered by reddit posts. Modding subs on reddit are notorious on every level for giving out bad information and then never correcting themselves when root causes of things are identified. The Starfield ones in particular have some really terrible advice and even the so called no drama one has a demonstrated vendetta against our project in particular.
So I do not think that it's valid blanket advice to insist people go into the menu. That may have worked for you, but that also doesn't make it a universal solution for everyone.
As far as sourcing information, I'd be extremely wary of accepting anything offered by reddit posts. Modding subs on reddit are notorious on every level for giving out bad information and then never correcting themselves when root causes of things are identified. The Starfield ones in particular have some really terrible advice and even the so called no drama one has a demonstrated vendetta against our project in particular.
Well, I'm not sure what to say then besides "it worked for me". There's nothing else I can add. Thank you for time.
Don't take this as us dismissing the case. We simply aren't able to reproduce it. Which is why the ticket hasn't been closed yet. Perhaps someone else may come along and be able to pinpoint the issue.
Thank you for keeping the ticket open and for considering the issue further. I appreciate your willingness to investigate, even if it's not something you've encountered personally.
If I come across any additional information or insights that might help in pinpointing the cause, I'll be sure to share them. Please let me know if there's anything else I can do to assist in the troubleshooting process.
If I come across any additional information or insights that might help in pinpointing the cause, I'll be sure to share them. Please let me know if there's anything else I can do to assist in the troubleshooting process.
I'm going to mention a couple things just to give a different perspective, outside the box.
1. NIFs are obviously graphical. From what I remember, the team uses AMD. I personally run nVidia and have had some different experiences than they did with FO4 in certain cells, in particular. It's not too far reaching that this could be on the drivers side if your card is not AMD.
2. The game uses plugins.txt to load mods, obviously. The game is blind besides that and the hard coded official ESMs. So, shutting down the PC, booting it up and starting the game, the only way it knows what to load is via that file. My thoughts on this theory since Bethesda forcing unload and load of the new order while in game is that Windows caching is forced to do a manual refresh of memory caching to clear the stack.
So, step 1. Exit the game but stay logged into Windows. 2. Install USFP. 3. Load the game and run it. 4. Exit the game. 5. Load other mods. 6. Load the game. CTD.
Perhaps try everything from 1-5. Then replace step 6 with: Shut down the PC. 7. Boot the PC. 8. Try the game and see if it crashes. This would by default clear cache of the game in Windows and essentially do the same thing of simply loading the plugins.txt without anything cached similar to "IF" BGS sends a manual flush to remove whatever is left on the stack during that in game load order reload.
Just some outside thoughts.
1. NIFs are obviously graphical. From what I remember, the team uses AMD. I personally run nVidia and have had some different experiences than they did with FO4 in certain cells, in particular. It's not too far reaching that this could be on the drivers side if your card is not AMD.
2. The game uses plugins.txt to load mods, obviously. The game is blind besides that and the hard coded official ESMs. So, shutting down the PC, booting it up and starting the game, the only way it knows what to load is via that file. My thoughts on this theory since Bethesda forcing unload and load of the new order while in game is that Windows caching is forced to do a manual refresh of memory caching to clear the stack.
So, step 1. Exit the game but stay logged into Windows. 2. Install USFP. 3. Load the game and run it. 4. Exit the game. 5. Load other mods. 6. Load the game. CTD.
Perhaps try everything from 1-5. Then replace step 6 with: Shut down the PC. 7. Boot the PC. 8. Try the game and see if it crashes. This would by default clear cache of the game in Windows and essentially do the same thing of simply loading the plugins.txt without anything cached similar to "IF" BGS sends a manual flush to remove whatever is left on the stack during that in game load order reload.
Just some outside thoughts.
VoodooChild,
1. I'm using the latest NVidia drivers. But I'm almost certain that the issue isn't graphical, because
2. I followed the process you outlined, but only similarly. Instead of installing USFP into an empty load order, I installed a personal plugin on top of my existing - and I should add minimalist (USFP already included) - load order that had nothing to do with ships. All it did was just change the outfit of one NPC — a single record change. Keep in mind that my Starfield was perfectly functional prior. NG-20 was placeable without a hitch. It was after installing that new mod (and not doing the load order reload) that trying to cycle/place an NG-20 would cause crashing.
Then, I restarted my PC as you advised. Started the game up, tried to put the NG-20 in. Crash. Reloaded the load order in the game itself... no CTD.
But noting your mention of plugins.txt — perhaps that's involved?
When using Mod Organizer 2, there are two instances of plugins.txt that exist — one in the AppData/Local/Starfield folder (which doesn't get used), and one in the AppData/Local/ModOrganizer (which does get used when running the game through MO2). Maybe by refreshing the load order, Starfield recognizes the appropriate plugins.txt? Perhaps that's why Arthmoor and MadCat221 never experienced this issue. If Wrye Bash handles its plugins.txt differently, that would explain why.
I dunno. I'm just speculating. All I'm certain of is that for me, refreshing the load order in game solves my NG-20 woes.
1. I'm using the latest NVidia drivers. But I'm almost certain that the issue isn't graphical, because
2. I followed the process you outlined, but only similarly. Instead of installing USFP into an empty load order, I installed a personal plugin on top of my existing - and I should add minimalist (USFP already included) - load order that had nothing to do with ships. All it did was just change the outfit of one NPC — a single record change. Keep in mind that my Starfield was perfectly functional prior. NG-20 was placeable without a hitch. It was after installing that new mod (and not doing the load order reload) that trying to cycle/place an NG-20 would cause crashing.
Then, I restarted my PC as you advised. Started the game up, tried to put the NG-20 in. Crash. Reloaded the load order in the game itself... no CTD.
But noting your mention of plugins.txt — perhaps that's involved?
When using Mod Organizer 2, there are two instances of plugins.txt that exist — one in the AppData/Local/Starfield folder (which doesn't get used), and one in the AppData/Local/ModOrganizer (which does get used when running the game through MO2). Maybe by refreshing the load order, Starfield recognizes the appropriate plugins.txt? Perhaps that's why Arthmoor and MadCat221 never experienced this issue. If Wrye Bash handles its plugins.txt differently, that would explain why.
I dunno. I'm just speculating. All I'm certain of is that for me, refreshing the load order in game solves my NG-20 woes.
I also don't think it's a nVidia/AMD thing either, because I have an RTX 4k-series card and am fine and dandy. Never had the NG-20s glitch out. The nature of glitch-outs don't seem to be graphical but asset loading-related, as it's wanting to load another lander's geometry at the same time (NG-15 in one case IIRC), and then the game poops the bed.
The bug is acknowledged, but too sporadic to get a diagnosis. Solution effectiveness seems to be as inconsistent as the bug's manifestation and are made with stabs in the dark.
The bug is acknowledged, but too sporadic to get a diagnosis. Solution effectiveness seems to be as inconsistent as the bug's manifestation and are made with stabs in the dark.
MO2 uses it's own, yes. Can you confirm that the 2 are identical? Meaning, enable via the game interface. Let it save and reload the load order. Hit the Windows key so you can access your desktop, then check both files. Check the modified date of each along with entries. If they are different, then the issue revolves around MO2. I don't use a mod manager, but if I was going to I would only use Wrye. I seem to remember hearing something along the lines that MO2 also adds the plugins SFBGS003.esm to the plugins.txt, but I can't confirm this as I don't use it. That would be an issue right there because they are hard coded to startup and not needed in plugins.txt, I would imagine. Keep in mind, I'm just going off of what I heard about MO2, but have not experience with it. That extra plugins.txt might actually be something used for multiple characters, for all I know, where is copies that one over for a certain profile.
@Madcat, that's good to know. I was going on a while back, I think Arth mentioned that the team had AMD mainly, so the Graygarden workshop border issue wasn't showing up for you guys. Could be wrong on the incident, but I remember something along those lines.
They're not the same. Not even close. I had in fact checked prior to posting my response, and I probably should have mentioned that.
MO2's (generated 6/28/2024):
# This file was automatically generated by Mod Organizer.
*unofficial starfield patch.esm
*sfta01.esm
*sfbgs00a_a.esm
*sfbgs021.esm
*sfbgs023.esm
*VisibleChronomark.esm
*ImprovedFollowerBehavior.esm
*MoreSurveyMissions.esm
*ProperGravityWave.esm
*XPForEMKnockouts.esm
*Ganymede.esm
*GravSprint.esm
*Hush.esm
*Faster Companion Affinity.esm
*PlayerSpeedRevised.esm
*Odyssey.esm
*KeoniAlpinOutfit.esm
Starfield's (generated 6/24/2024):
# This file is used by Starfield to keep track of your downloaded content.
# Please do not modify this file.
*sfta01.esm
*sfbgs021.esm
*sfbgs023.esm
*sfbgs00a_a.esm
I wouldn't be so quick to pin this on MO2, though. As you can see, neither vanilla nor MO2 adds SFBGS003.esm to its plugins. Maybe in a previous version of MO2, but I'm using the latest dev build. And I have but only one profile for MO2. Also, as I had linked in the original post, this is affecting Xbox users (i.e. not MO2 users). Or at the very least an Xbox user. And I am aware of the mistrust towards reddit, but I wouldn't be so quick to assume the guy is plain lying. His modding naivete would add credence to his post, if nothing else.
It's probably a plugins.txt thing. Who knows for sure at this point.
MO2's (generated 6/28/2024):
# This file was automatically generated by Mod Organizer.
*unofficial starfield patch.esm
*sfta01.esm
*sfbgs00a_a.esm
*sfbgs021.esm
*sfbgs023.esm
*VisibleChronomark.esm
*ImprovedFollowerBehavior.esm
*MoreSurveyMissions.esm
*ProperGravityWave.esm
*XPForEMKnockouts.esm
*Ganymede.esm
*GravSprint.esm
*Hush.esm
*Faster Companion Affinity.esm
*PlayerSpeedRevised.esm
*Odyssey.esm
*KeoniAlpinOutfit.esm
Starfield's (generated 6/24/2024):
# This file is used by Starfield to keep track of your downloaded content.
# Please do not modify this file.
*sfta01.esm
*sfbgs021.esm
*sfbgs023.esm
*sfbgs00a_a.esm
I wouldn't be so quick to pin this on MO2, though. As you can see, neither vanilla nor MO2 adds SFBGS003.esm to its plugins. Maybe in a previous version of MO2, but I'm using the latest dev build. And I have but only one profile for MO2. Also, as I had linked in the original post, this is affecting Xbox users (i.e. not MO2 users). Or at the very least an Xbox user. And I am aware of the mistrust towards reddit, but I wouldn't be so quick to assume the guy is plain lying. His modding naivete would add credence to his post, if nothing else.
It's probably a plugins.txt thing. Who knows for sure at this point.
OK, well, that's good news on the MO2 not including the extra ESMs. If XBox is having the same issue, then it is obviously not a mod manager issue. At this point, I've exhausted what I can think to be the issue as I was just looking for a common denominator outside the box and the only thing that might make a difference is load order of sfbgs00a_a.esm as that seems like the only thing that the engine would di different than MO2. I'll follow up if something else comes to mind.
Showing Comments 1 - 16 of 16