Helpful Links and References

[smr1957]

Looks like Bethesda may have another update in the offing.
As per kdodds on the Steam Starfield forum in The Coffee Pod thread:
"Looks like another update might be incoming this week.  Updated today, same way they did the last one, uploaded on the w/e and made live the following week.
 
https://steamdb.info...716740/history/ "
 
original quoted post can be found here

Edited October 18, 2023 by smr1957

[smr1957]

Latest news concerning xEdit  (from Elminster, on Github):

What's New in (future) xEdit 4.1.5 since 4.0.x? SF1Edit - Starfield

 

[smr1957]

ADDED:

WHAT CAN I DO IF STARFIELD IS CRASHING ON PC?

To Section 5 - General Troubleshooting

[smr1957]

ADDED:
GETTING STARTED - NEW PLAYER GUIDE - STARFIELD
https://help.bethesda.net/#en/answer/61265
to Section 1 - General Information

ADDED:
WHAT DO I DO IF I HAVE AN ISSUE WITH A MISSION IN STARFIELD?
https://help.bethesda.net/#en/answer/61353
to Section 5 - General Troubleshooting

[smr1957]

Latest info on Mod Organizer 2 (thanks to Avrie for the information):

"2.5.0 - Beta 14 @MO2 Feedback
Please don't link this externally or upload somewhere else.

IMPORTANT
2.5 builds include a number of dependency updates which ultimately means that these builds currently only support Windows 10 and above.

We currently can't support Windows / Xbox Store (gamepass) installs as these do not work with the VFS.

Beta 14:
Added diagnoses to Starfield
Detections for improper plugin management setup
Warnings for various plugin types
Togglable in the settings
Updated libloot to 0.22.1
Revamped download code (SaltyTrout)
Removed reliance on dynamic IDs
Additional changes to mitigate errors
Cyberpunk 2077 support (ZashIn)
Updated display for dummy (recordless) plugin files
Overlay plugin type revisions
BSA Packer will now use ESL files for Starfield dummy plugins
Translation updates

Please Note: For the 2.5.0 installer, plugins will be wiped to account for 2.4 plugins being incompatible with 2.5."

[smr1957]

XEdit for Starfield is due for preliminary release soon. For information on this, see:
For more info on the above, and on xEdit progress, see:
https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/whatsnew.md

There is important information there as regards the type of files which will be supported. Bethesda, with Starfield, is moving away from supporting .esp plugins, and will apparently only be supporting .esm and .esl (lite) plugins. This makes sense from the view of cross platform compatibility as regards modding, and should also make it easier as there will no longer be the worry of what type of plugin is being used, compatibility between plugins, or a practical limit to the number of plugins (obviously there is still a limit, but it will be much, much harder to reach).

This just really emphasizes what many have stated in regards to modding the game at the current time and how any mod which uses plugins should not be used.

[smr1957]

Good day, all!  I took a quick read through the xEdit release notes (https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/whatsnew.md) the other day and it was interesting, to say the least.  As such, I think it important for people to realize some things as regards modding the game at the current point in time.

If indeed, as stated in the release notes,  the game will not support .esp files, and will support only .esm and .esl files, I really don't see a problem with that - in fact, it is more than likely a smart design move, as there will no longer be any issues between console modding and PC modding, nor will there be the issues of different types of plugins (.esp vs .esl).  And, this would perhaps also align with the decision made to have all mods in the Document location - the main location will remain unchanged (for all practical purposes) except for official updates and patches, while the mod files will be in a separate location, and thus there will no longer be an issue with the official files somehow being replaced or removed due to modding.

Well, at this point it is a lot of conjecture, and we will not find out for sure until the release of the CK - as was correctly pointed out in the preliminary release notes.  Until then, it is still, at heart, a lot of speculation - even if some of it, by some of the more knowledgeable people (based upon experience in working with Beth games and tools), is more informed than others.

Most importantly, all this goes to the point that except for the simplest of mods - textures replacers, UI interfaces (.swf files), etc., people should probably not be using mods which contain anything that might be needed to be placed in the the game's main root folder - and this includes SFSE and any mods that may require it - nor should they be using any mods that contains a plugin - not even if they are able to make one using the present release of xEdit.  Until the release of the new CK, there is no safe way to create any plugins - so, only once the new CK is released will it be possible to make "safe' mods - and only then will it be possible to determine if xEdit has been assembled properly.

[Arthmoor]

You should keep in mind that the desire to force .esm only is something Elminster is pushing. That's not something the game devs have done anything about. We don't actually know yet what the CK will and won't allow so it doesn't pay to have information about that floating around just yet.

We have no idea yet whether or not Bethesda is going to fix what the xEdit guys think is wrong, assuming anything actually is.

IMO it's still way too soon to be introducing mods to the game, even for texture replacers, since those replacers may not be properly optimized for what the game is expecting.

[smr1957]

1 hour ago, Arthmoor said:

You should keep in mind that the desire to force .esm only is something Elminster is pushing. That's not something the game devs have done anything about. We don't actually know yet what the CK will and won't allow so it doesn't pay to have information about that floating around just yet.

We have no idea yet whether or not Bethesda is going to fix what the xEdit guys think is wrong, assuming anything actually is.

IMO it's still way too soon to be introducing mods to the game, even for texture replacers, since those replacers may not be properly optimized for what the game is expecting.

Personally, I think it would have been better to just put off the release of xEdit until after the CK comes out and things can actually be seen and verified as regards to how the game works when it comes to mods.  Especially given some of the conclusions (whether right or wrong) that the xEdit team itself indicated in their notes.

I have never understood the whole "rush to release" attitude that so many have.  It is far better to delay the release of a tool or mod until it can be ascertained to be properly made, than it is to release one prematurely, and run the risk of people breaking their game.

As to the most basic of mods, such as replacers, though they may not have the issues that others do, it is only fair to recognize the validity of what Arthmoor said regarding them.  Simply put, the best approach is that unless a person is prepared to consider their game a "throw away" playthrough, they should not be modding it at all - and if they do, they should not be surprised if things do not function as expected somewhere down the line.

[Scythe Bearer]

3 hours ago, smr1957 said:

Personally, I think it would have been better to just put off the release of xEdit until after the CK comes out and things can actually be seen and verified as regards to how the game works when it comes to mods.  Especially given some of the conclusions (whether right or wrong) that the xEdit team itself indicated in their notes.

I have never understood the whole "rush to release" attitude that so many have.  It is far better to delay the release of a tool or mod until it can be ascertained to be properly made, than it is to release one prematurely, and run the risk of people breaking their game.

As to the most basic of mods, such as replacers, though they may not have the issues that others do, it is only fair to recognize the validity of what Arthmoor said regarding them.  Simply put, the best approach is that unless a person is prepared to consider their game a "throw away" playthrough, they should not be modding it at all - and if they do, they should not be surprised if things do not function as expected somewhere down the line.

 

As a developer in a different world, what you have labeled a "rush to release" is called "prepositioning" in another frame.  There is a LOT of work in developing tools like xEdit and SFSE and that work takes time.  If developers wait until AFTER Bethesda releases the CK to start work on their tools/services/facilities, then they start behind schedule.  Thus, developers do what they can with what they have and what they can "deduce" from what they have.  This is why you see the makers of every thing from xEdit to MO2 to SFSE (and a host of other tools/services/facilities) scrambling to get and share any and all information they can to get their tools ready and in position for when it is actually needed. 

As for releasing early, that approach is quite often used as a means to test theories, interpretations, and implementations, all in an effort to make sure that what they have thus far is workable and robust.  Now, maybe this release went to too large an audience, but the "limited testing" release was leaked and keeping things under wraps was an idea that was ignored by overanxious mod makers. 

[smr1957]

Scythe, perhaps for some other field of endeavor, where there is money and profits on the line, what you posted may possibly hold true (though I have my doubts about that based upon my accumulated knowledge and experience), but that is absolutely untrue when it comes to creating free tools for a game or creating free mods for said game.  In all my experience in the not just the forums, but also as a former game designer/developer (albeit it many years ago), the "rush to release" has been one of the major factors in failure of a tool being useful, a mod being successful, and in the breakage of individuals games - not to mention failure of games themselves upon premature release by game companies.  What you are stating simply does not apply in this situation - unless there is some ulterior factor at work.

Edited October 21, 2023 by smr1957

[Scythe Bearer]

And therein lies the rub. 

If the developers of mod managers wait for Bethesda to release the CK before starting their work, then for the development/test time users have no way to manage the mods mod makers will make, and must revert to  tedious and error prone manual installation processes. 

If the authors of Xedit wait until Bethesda releases the CK before beginning their efforts to implement required changes into their tools, then mod makers are without the ability to perform the crosscheck processes xEdit does to ensure mods are clean and free from dirty edits, ITM records, deleted records, etc.  Consequently, dangerous mods get released which break games and erode trust in mod makers. 

And those are just two examples of the impact that waiting for Bethesda to release the CK can precipitate. 

In any field of endeavor, when product A is dependent on product B, it is incumbent on the developers of product A to begin to position their product for availability as soon after the release of product B as possible.  In my experience, companies which failed to heed this simple guidance fail and either disappear of get gobbled up by their competitors who did heed the guidance. 

Finally, free tools and a voluntary workforce are not a limiting criteria for success, and should never be used to denigrate the work of dedicated and hard working people.  It is always and forever the people with the coding pencil in their hand, short on sleep and long on cold coffee and pizza, who produce success.  Critics on their work, on the other hand, do not contribute  to anyone's success.  Most writers, movie makers, game makers, photographers, artists, sculptors, cartoonists, etc share Robert A. Heinlein's view of critics.  "A critic is a man who creates nothing and thereby feels qualified to judge the work of creative men. There is logic in this; he is unbiased, he hates all creative people equally". 

[Arthmoor]

Starfield is a unique iteration though. Mod managers in and of themselves are not capable of doing much right now without employing code hacks to get around engine limitations the devs inserted on purpose. Bethesda has made it crystal clear that the installation and use of mods is NOT SUPPORTED right now. When they use this language it's often more realistic for those of us on the outside to say it's been deliberately disabled. Reverse engineering types have confirmed this is indeed the case because they've blocked the reading and parsing of the plugins.txt file in the code. Which to me strongly suggests Bethesda is not ready for mods to hit the scene yet.

Combine this with the fact that people have said that "overlay plugins" can't work right now and that there are specific hacks in the code to allow the preorder and premium bonus files to load anyway, and it's quite frankly folly to go forward with plans based on a system that's currently "broken" because the devs "broke" it on purpose. Plus the ESL system is apparently also non-functional. This ought to tell you that the game is not in a state that's ready to accept mods. Yet here we are, with irresponsible modders pressing ahead anyway and with premature tool releases encouraging this behavior before it's time. Right now everyone is proceeding from the false assumption that Starfield modding works identically to modding for every older game. This is demonstrably not the case.

IMO, the wise and patient approach is to wait for the CK to come out, then develop the assistive tools we all use to follow its model for how mods are supposed to be made for this game. Yes, it sucks that this means we won't see shit out of BGS until "next year"

[Scythe Bearer]

Simply put, "right now" is not the same as "prepositioning", and neither is specific to Starfield.  "Right now" is a petulant child demanding a cookie.  "Prepositioning" is getting ones ducks beak to butt before releasing product.  Equating these two dissimilar concepts is neither helpful nor productive. 

We do what we can with what we have.  NOBODY is endorsing releasing anything for "real work".  I, however, applaud the efforts to study, evaluate, understand, learn, prepare and apply new knowledge to a new situation. 

I am certainly not waiting for the CK to arrive before I test the concepts for any mods I have planned.  I work with what I have to test the impact and effect of what I plan to do.  Yes, I am using console commands instead of a scripted implementation, but I work with what I have to see the efficacy of what I have planned.   This is "prepositioning".  

The mod I have planned and am "proofing" right now is not all that complicated and does not require all that much effort.  eXedit, MO2, SFSE  et al, are complicated, and require a larger lead time and a larger investment in time, effort and energy.  They also require more proofing to see if the concepts work and are effective.  I do not begrudge those teams their early releases to get help and feedback to validate their products.  Nor do I want to see them abused for their efforts.  The fault in the usage of their early versions of their products for "real work" lies with the mod makers who need their cookies, and the mod users willing to slurp up the crumbs. 

So, if any feel the need to bash or debase someone for using these early validation versions of tools for "real work" point the fingers where they belong.  Just do not confuse "early release" with "prepositioning", nor assume for a second that what is released today during the validation process will be the same tool that is released when the CK arrives.  

And with that, I will descend from the soapbox and yield the floor.  I have exhausted my energies and must now sleep and allow the little gray cells time to recuperate.  

[Arthmoor]

I'll remember this post when the CK comes out, the game gets the proper updates, and everyone goes "ah hell, everything changed and all this work was just invalidated". Cause right now this is what I see happening because people are making too many assumptions about how things used to work than they are spending time validating how they work in the new system.

I honestly feel like I'm going to be vindicated when this happens, like many times before when I've told people something and it was correct from the start.

Yes, it will suck to see people have invested so much time only to have things changed on them, but that's what happens when you're firing on moving targets and not waiting for the basic systems to be ready.

[DayDreamer]

3 hours ago, Arthmoor said:

when the CK comes out, the game gets the proper updates

ROFL! I'd actually waited to buy Skyrim until the CK was released, imagining that meant the game was properly updated. If I'd only known....

Anyway, I'm again waiting to purchase Starfield until its CK is released.

[smr1957]

Just an information note. I've come across many people in other forums who are stating that they do not have a save to go back to (whether it is due to saves being overwritten or some other reason). This points out the importance of not relying upon auto or quick saves, which are limited in number - 3 auto saves and one quick save - and which constantly overwrite the previous auto or quick saves. For this reason, people should make it a practice to use manual saves - and save frequently. Save before going through load screens, save before purchasing or selling anything, save before any possible combat situation or dialogue interaction - save, save, save. In this way, regardless of the situation, you will always have a save that you can roll back to should the need arise.

Good luck!

Edited October 21, 2023 by smr1957

[Pseron Wyrd]

51 minutes ago, smr1957 said:

save, save, save.

Agreed.  I've been known to make over 500 manual saves per character.  You cannot make too many manual saves, is my attitude.

[Arthmoor]

I've got a ton of manual saves myself. Probably not 500, but enough. Good habit to have no matter the game too.

[smr1957]

ADDED:

ADVANCED TROUBLESHOOTING - CRASHING/FREEZING ON PC - STARFIELD

to Section 5 - General Troubleshooting

[smr1957]

ADDED to Section 4 - Modding the Game, directly under The Golden Rule of Modding:

Addendum to the above:

"Until the release of the Starfield Creation Kit, though tempting, modding is not recommended and not supported, as there is too much unknown as to how the game works under the hood, and there may be unforeseen consequences. Remember, it is better to play a game unmodded, then to curse at a modded game that does not work."

 

Thanks goes to Vlad 254 for the suggestion.

[smr1957]

I would just like to take this opportunity to post a bit of an explanation as to my position on things regarding modding in Starfield and other aspects of modding, such as patches for the game, tools, as well as mods in general.  I will not be linking any released patches other than those which are directly from Bethesda, nor tools, regardless of who may be creating them, until the CK has been released.  This has nothing to do with personal bias, and everything to do with the fact that my Helpful Links topics on Steam, at AFK Mods, and the pinned version on Nexus, are meant to be places which only contain information and things that I have been able to absolutely and without reservation ascertain as being totally safe and completely and factually accurate, at least insofar as is humanly possible.  This applies to any patches, tools, or mods that may be released - regardless of by whom (unless they are from Bethesda), and until the release of the CK when the actual information and facts of how the game works and is constructed has been made available to all.

As a repository of information which people rely upon, I cannot in good conscience link or post anything therein that I either know, or strongly feel, based upon my experience, to be potentially harmful to people's games.

And this is all in line with my oft stated and referenced Golden Rule of Modding, to which I added an addendum, which succinctly explains my philosophy regarding modding activities:

"THE GOLDEN RULE OF MODDING

"No matter how good a mod may look or sound, no matter how much you may really want a mod, if the mod does not work as it should, causes issues in your game, or even seems to have the potential to cause issues, dump the mod. A game that does not work is no game at all."

Addendum to the above:

"Until the release of the Starfield Creation Kit, though tempting, modding is not recommended and not supported, as there is too much unknown as to how the game works under the hood, and there may be unforeseen consequences. Remember, it is better to play a game unmodded, then to curse at a modded game that does not work."

(from Section 4 - Modding the Game)

So while others may create, post, link, or otherwise use assets that have been released, unless I am positive that they are safe to use, I have a personal responsibility to the community to not endorse or seemingly recommend them - which, by my providing a link in any of my topics, might tend to infer or be possibly perceived by some to be an endorsement and thereby an indication of those items being safe to use.

Edited October 29, 2023 by smr1957

[smr1957]

Regarding Saves and the Different Types of Saves 

This is a reference thread for Helpful Links and References.  It is linked in Section 1 - General Information

The key to keeping your blood pressure down, and your playthrough on track, is to always have a backup you can trust.  Save files are not all equally useful, and the time to learn that fact is not several hundred hours into a playthrough.

Quick Save… The perfect tool for use in combat, especially when that pesky Spacer, Ecliptic, or Crimson Fleet character (or some creep-crawly alien) can suddenly appear and one shot/one hit you. But it is also the buggiest and most unreliable of all the saves. There is only one quick save file, and it is overwritten each time you use it. Useful in a tight spot, but rely on it at your own peril.

Automatic Saves… By default, the system cycles through three of them, overwriting the oldest file every time you rest, wait, travel, or pause the game (configurable “in game” under settings). You do not have control of the save, or when it will be over written. They have also been much maligned over the years as being a cause of crashes. While this is not exactly true, the fact that the game is trying to save at the same time that it’s trying to load can be very stressful on your system. Think of the occasional CTD or lag while exiting a building or landing on a planet as “A canary in a coal mine” - it’s time to re-check things amd reboot (couldn’t hurt ;-). In an extended playthrough (and even in a not so extended one), it might happen from time to time, even if you’ve been having no problems at all beforehand. If it starts happening more often, you have other issues to resolve. The backup is not the cause.  The best policy is to turn autosaves off completely.

Manual Saves… The gold standard. You control the save, and it's permanent until you delete it. By far the most stable, and the only save you should rely on.  Make a manual save before going through load doors, initiating dialogue, selling items to vendors, or doing anything that may have an impact upon the game or your character.  Save, save, save - and save some more.  It is better to make a save and not need it, than not make one and have nothing to roll back to when things go sideways.

Good luck!

(Paraphrased and taken from a thread originally posted by Avrie on Steam for Skyrim, but which applies to any game.)

Edited November 2, 2023 by smr1957

[Scythe Bearer]

Just a small correction.  All save files are created equal. 

Further, it is possible to create saves in Script files (ForceSave or Autosave functions), and via console command (Save and Quicksave commands).  The Console command SAVE and the Script ForceSave function can be invoked with an optional file name.  

Every one of these SAVE options go through the same processing to create the actual save file.  The difference in save files is when they are created, and not how they are created.

[smr1957]

The correction was unnecessary, as I never posted that the saves are inherently different in the manner in which they are made, nor does it state that there are anywhere in the post. The point of the post is that people should not rely on just auto or quick saves - not how the saves are constructed.  Because, as of now, I see far, far, too many people posting about problems who have relied upon only auto or quick saves and as a result, they were unable to roll back so as to fix issues that occurred in their game.

Edited November 1, 2023 by smr1957