[yermom]

I've said it before and I'll say it again.

BATCH ESMIFICATION.

We know how to manipulate the ESM header flag. It can't be that hard to make a little program that en masse converts all ESPs into quasi-ESMs and back (for GECK purposes). And from the sound of it, ESMs are spared these bugs. The only issue is that load order will have to be watched as there would effectively be no more "ESMs Load First" safety net.

It would certainly be a whole lot easier than Persistent-izing every ref.

[Kelly Tomlinson]

I can understand not testing against mods - they are just too many and what might not break one may break another. BUT . . . making a change such as they did, having to intentionally make such a change, and I have to believe knowing the issues it would cause, I just don't understand. Why did they do this? What is the explanation for it? I might could even understand this if there was some sort of explanation for it. But we got nothing . . . it's very hard to be understanding of Bethesda given the lack of explanation on their part, even if one wanted to give them the benefit of the doubt. Why . . . ?

[Kelly John]

Well i can say one thing not all that many people are going to bother getting broken steel if it is in fact BROKEN. User mods are what make Bethesda games without them you'd probably play them through maybe once or twice then shelf it again for the next few years.

Also i found this posted by Gstaff
http://www.gamesas.com/bgsforums/index.php?act=findpost&hl=&pid=14259022

Yes but I still think there may be more to this. Regardless of what's officially supported, look at what they've done so far. They made those web tutorials and those youtube tutorials and EVEN updated the GECK for their new Broken Steel-related features. However, there's this semi-new situation where the game does not effectively use the one and only type of file that the GECK produces when used stand-alone, which is the .esp file. This doesn't sound like something they would want lying around. This isn't about what they are obligated to do, this is about what they would want to do.

They have surely been hellaciously busy making Broken Steel lately. At least our mods do not have deadlines where everyone's paycheck is on the line. We shouldn't assume that the GECK's stand-alone abilities to create mods have been thrown to the dogs just yet, its just plain-ole too soon.

[OJY]

Despite really liking the way the chinese stealth suit looks, I haven't bought a single DLC for Fallout 3 over lack of Quality Assurance.

Seeing all the problems with 1.5 and now errors that folks have been reporting while playing BS... has definitely turned me off of them.

If they fix the bugs, or if Quarn can patch up the ESP's I could see myself buying them.

[Patrick Gordon]

I'm not saying it has been thrown to the dogs the reason i posted the quote is cause people were wondering where it came from. While i do believe they will fix the bug i don't think its going to be anytime soon.

Also MadCat as i understand esming everything would pretty much kill everything since from what i understand esms do not overwrite esms. This is potentially a MASSIVE problem.

[Gen Daley]

I've said it before and I'll say it again.

BATCH ESMIFICATION.

We know how to manipulate the ESM header flag. It can't be that hard to make a little program that en masse converts all ESPs into quasi-ESMs and back (for GECK purposes). And from the sound of it, ESMs are spared these bugs. The only issue is that load order will have to be watched as there would effectively be no more "ESMs Load First" safety net.

It would certainly be a whole lot easier than Persistent-izing every ref.

As a temp measure while we don't know what's coming down the pike, this can be a great thing, but understand that this can in some cases break savegame compatibility. My own mod is an example of this. Making a complete ESM/ESP pair out of Phalanx that recifies all the issues positively breaks people's saves. So for now, I made what I consider a temporary .esm (using a beta version of FO3edit) that rectified the navmesh issues while not touching anything that would break savegames. The remaining unfixed issue is the bright-white skin on followers, and for the time being that's going to ride as-is.

[Vivien]

I'm not saying it has been thrown to the dogs the reason i posted the quote is cause people were wondering where it came from. While i do believe they will fix the bug i don't think its going to be anytime soon.

Also MadCat as i understand esming everything would pretty much kill everything since from what i understand esms do not overwrite esms. This is potentially a MASSIVE problem.

A fix mentioned in the V1.5 changelog...

Fixed crash related to altered references between master files

You may be referring to the Land Bug that was encountered during the Oblivion modding days. That is certainly not the case now: The Operation Anchorage ESM alters the Wasteland worldspace (in the Fallout3.esm) to add the doorway and nearby ruined subway entrance that leads to the Outcast Outpost, and there is no issue with the terrain disappearing. I'm not sure how Form objects are affected, but Ref object additions and alterations in an ESM on a parent ESM's stuff apparently is far less of an issue now.

[Liii BLATES]

A fix mentioned in the V1.5 changelog...


You may be referring to the Land Bug that was encountered during the Oblivion modding days. That is certainly not the case now: The Operation Anchorage ESM alters the Wasteland worldspace (in the Fallout3.esm) to add the doorway and nearby ruined subway entrance that leads to the Outcast Outpost, and there is no issue with the terrain disappearing. I'm not sure how Form objects are affected, but Ref object additions and alterations in an ESM on a parent ESM's stuff apparently is far less of an issue now.

The thing is everything i've seen or read has talked about how esms dont modify esms. Is it something new in the 1.5 patch? I recall Quarn very briefly had the UFP a esm but quickly changed it back after problems heres the snippet from the patch notes.

Is no longer an ESM (well that was short lived! I really should of tested it more...), any modified placed object will be unaffected if it doesn't have an ESM override, once there is a way to automatically generate ESM overrides then it will be an ESM again.

[scorpion972]

I recall Quarn very briefly had the UFP a esm but quickly changed it back after problems heres the snippet from the patch notes.

Say I make an ESM and disable a rock thats in Fallout3.esm, for that rock to be disabled it needs an ONAM override otherwise no change will take effect when you load that ESM. New cell objects don't need ONAM overrides. Anyhow next release of FO3Edit has automatic generation of ONAM overrides which makes things a hell of alot easier.

[J.P loves]

Say I make an ESM and disable a rock thats in Fallout3.esm, for that rock to be disabled it needs an ONAM override otherwise no change will take effect when you load that ESM. New cell objects don't need ONAM overrides. Anyhow next release of FO3Edit has automatic generation of ONAM overrides which makes things a hell of alot easier.

Ahh i see. So generally the fact that its an ESM isn't such a big deal its just that it isn't set to have the override?

[Klaire]

Has there been any anolysis into the purported ability to nullify these problems by saving a file with the v1.5 GECK, like a side-by-side comparison of a before/after ESP to see if something is different between the two? If there is something, it may be batch-able too... maybe. :shrug:

Say I make an ESM and disable a rock thats in Fallout3.esm, for that rock to be disabled it needs an ONAM override otherwise no change will take effect when you load that ESM. New cell objects don't need ONAM overrides. Anyhow next release of FO3Edit has automatic generation of ONAM overrides which makes things a hell of alot easier.

Does this mean ONAM overrides in ESMs?

[Sheeva]

1.5 geck doesn't make things compatible. Sorry to pop yer bubble.

Batch esmification IS NOT AN OPTION.
The game treats esms and esps VERY DIFFERENTLY, specially when it comes to savegames. Disabling an esp is eventless, disabling an esm brings trouble. Not to mention the myriad of problems in load order this would bring.
It would also eliminate any kind of savegame compatibility.

[Alkira rose Nankivell]

1.5 geck doesn't make things compatible. Sorry to pop yer bubble.

Batch esmification IS NOT AN OPTION.
The game treats esms and esps VERY DIFFERENTLY, specially when it comes to savegames. Disabling an esp is eventless, disabling an esm brings trouble. Not to mention the myriad of problems in load order this would bring.
It would also eliminate any kind of savegame compatibility.

I've removed ESM's from my saves before and haven't seen anything bad happen... any source for the "bad" things? as for load order it would be easier to manage since it would just be "ESM's oldest to newest" instead of "ESM's oldest to newest then ESP's oldest to newest", plus no more constantly telling people esp's can't load before esm's all the time.

Does this mean ONAM overrides in ESMs?

ONAM overrides are needed in ESM's to modify cell objects placed by other ESM's.

How do I reset the cache?

When I mean "reset" I mean reset your computer.

[Travis]

Hey Quarn, sorry for the obviously stupid noob question, but just to be clear, what do you feel is a viable alternative (If you have any idea) with the 1.5 situation as it stands now.

I'm talking about worse possible scenario where there is no official fix down the pipe. I guess it can't be as easy as making every mod an esm with the next FO3EDIT and everything is back to normal can it?

[Izzy Coleman]

Hey Quarn, sorry for the obviously stupid noob question, but just to be clear, what do you feel is a viable alternative (If you have any idea) with the 1.5 situation as it stands now.

I'm talking about worse possible scenario where there is no official fix down the pipe. I guess it can't be as easy as making every mod an esm with the next FO3EDIT and everything is back to normal can it?

Well if no flaws are found with ESM's then it will be a pretty easy transition to ESM's with the help of FO3Edit.

[chloe hampson]

I've removed ESM's from my saves before and haven't seen anything bad happen... any source for the "bad" things? as for load order it would be easier to manage since it would just be "ESM's oldest to newest" instead of "ESM's oldest to newest then ESP's oldest to newest", plus no more constantly telling people esp's can't load before esm's all the time.

It's not necessarily "ESMs", it's "masters" in general, even when an ESP is a master to another. But it's not a problem AFAIK.

I find that missing masters is only an issue when a master is truly missing (as in, no file present). If a module is master to another, and the master is deactivated but the slave module is not, the game just activates the module by default. Basically, the game won't let you deactivate a module that another active module calls master. For me, O:A would remain active for me even if I tried deactivating it, it turned out that I had some modules I didn't realize were mastered to it. I also figured out real quick that the UF3P installer activates the DLC patch ESPs as well, as at the time I didn't have The Pitt and was crashing at game startup because the Pitt patch ESP required the Pitt ESM. :wacko:

[Britta Gronkowski]

Well if no flaws are found with ESM's then it will be a pretty easy transition to ESM's with the help of FO3Edit.

I didnt see any flaws when me and Elminster did it, and Phalanx has a little of each thing that 1.5 natively breaks.

We did this deal where we took Phalanx and split it in two. The things that were being added new to the game were done both within the .esm and esp, and the things that were changing existing resources (like my changes to vanilla followers) lived in the .esp, and the .esp had both fallout3.esm and my .esm as masters. It behaved perfectly in every respect I was aware to test including interior new-cell navmesh. It was not savegame compatible.

[Lifee Mccaslin]

I've removed ESM's from my saves before and haven't seen anything bad happen... any source for the "bad" things?

IIRC, when an esm was turned off in oblivion, some several things from it didn't got removed from the savegame. Leaving a bunch of ghost data. I do not know if fallout is the same but i suspect it is.

no more constantly telling people esp's can't load before esm's all the time.

Neither FOMM nor the game actually let you load esps before esms, so this has never been an issue apart from "sort your goddamned load order so we can understand it better and help you piece of noob!" (in varying grades of offensiveness).
Everything esm would mean more chances for users to commit stupid mistakes. ESMs are currently used only by true master files, files that MUST load early and/or that serve as bridges between other mods. Breaking this barrier would bring all sort of trouble on the user side.

The game does treat esms and esps differently memory-wise. While the engine has been tested with 100+ esps without too much troubles, the limits on esms may lie elsewhere. We're threading unknown ground here and the chances of hard-to-track barfing and crashes is high.

[Quick draw II]

Also MadCat as i understand esming everything would pretty much kill everything since from what i understand esms do not overwrite esms. This is potentially a MASSIVE problem.

This is not true for FO3. It is true for TES4 that esm's can't override esm's without massive problems (which would seem to be one of the primary reasons the SI has been done by merging it into Oblivion.esm and the other DLCs are .esp's)

In Fallout 3 engine changes (and especially the introduction of the ONAM subrecord in the file header of ESM files which lists the contained overriden FormIDs) change this behavior. There doesn't seem to be any problems with esm's overwriting other esm's (as long as that ONAM record is correctly present) which can be seen quite well given that the 3 DLCs are all esm's, all overwrite records from Fallout3.esm and that seems to work in general.

I have to assume that all the problems with .esp's now are there because no one at Bethesda ever tested recent engine versions with any .esp's as all the DLCs are .esm's. That was different in TES4 where the DLCs were .esp's, so they had to make sure that .esp's work correctly.

[Lory Da Costa]

This is not true for FO3. It is true for TES4 that esm's can't override esm's without massive problems (which would seem to be one of the primary reasons the SI has been done by merging it into Oblivion.esm and the other DLCs are .esp's)

In Fallout 3 engine changes (and especially the introduction of the ONAM subrecord in the file header of ESM files which lists the contained overriden FormIDs) change this behavior. There doesn't seem to be any problems with esm's overwriting other esm's (as long as that ONAM record is correctly present) which can be seen quite well given that the 3 DLCs are all esm's, all overwrite records from Fallout3.esm and that seems to work in general.

You know your stuff but when you say in general, what exceptions are there?

I mean if Tarrant can find a bug and he knows what he is doing more than most people, what exception might of caused it?

I've said it before and I'll say it again.

BATCH ESMIFICATION.

We know how to manipulate the ESM header flag. It can't be that hard to make a little program that en masse converts all ESPs into quasi-ESMs and back (for GECK purposes). And from the sound of it, ESMs are spared these bugs. The only issue is that load order will have to be watched as there would effectively be no more "ESMs Load First" safety net.

It would certainly be a whole lot easier than Persistent-izing every ref.

As tarrant has highlighted and I have often said myself, this will cause problems, it would solve a percentage of them but ESMs do have some quirks themselves.

I am interested to see what would happening running 50 big masterfiles, my gut tells me crash after crash, because in previous titles that might well of been the case. If we go this route it really is a matter of crossing our fingers.

I didn't see this in the forums, where'd it come from and when? Cannot find it either with searching.

I think the poster is referring to the initial comments made when the bug was highlighted, if I am not mistaken.

If so then they were not an official decision, just helpful pokes to try and get around the bug.

Well, they're gonna miss out. Fake Patch Supports BS now. No need for 1.5 unless you wanna be picky.

This is great news

-edit

Apologies for the double quote.

[Joe Bonney]

That quote from Gstaff is just absurd! How can they think like that?

OF COURSE we don't expect them to test user mods... But that is not the problem here, or the point. That quote seemed like nothing more than dodging the issue!
The problem here is that they released a patch which BROKE things that previously worked fine! This is not the fault of modders at all! They've obviously broken some of the standards by which mods rely on. But don't get me wrong, I don't begrudge them for this bug, I'm sure they'll fix it eventually.

The save bug has rendered our games unplayable until they fix it. And removing the mods, which many of us find essential to the play experience, is not an option either, for that makes us not want to play at all anymore. Plus, having our games officially patched up-to-date not only insures that most mods are universally compatible for everyone, but also insures we can easily use (and buy) their DLCs.
Still, I've had to downgrading to 1.4, simply because I want to have a working game.
Bethesda makes these games for, and very openly encourages, mods. Yet now they've broken this feature, and a huge part/value of their game with it. How can they so easily ignore the people/community who pay their wages?! lol
(not demanding immediate fix) (And I also understand that they probably ARE working very hard on this issue. Bare with me, I'm still getting to my end point.)

I know I shouldn't be ranting, because it probably wont make a difference or be heard by them... But look, none of us expect an instant fix when such problems arise... We know these things take time and hard work... What we DO expect though, is to not be blown off, when a serious issue is discovered. We expect these issues to be taken seriously, since this game IS their BUSINESS! And we are their worried costumers. :sadvaultboy:

Rather than blowing us off with such a comment, why is it so hard for them to just say/announce "Yes we screwed up a little, we're working on it, and hope to have things fixed for you soon."
Is that too much to ask? Comfort your fans a little for god sakes!

I wouldn't even be complaining right now, if Gstaff hadn't said that... But I would still appreciate (and eagerly await) a comforting announcement/reassurance that they are working on this problem. *sigh*

[Sarah Knight]

You know your stuff but when you say in general, what exceptions are there?

None that I'm aware of.

I mean if Tarrant can find a bug and he knows what he is doing more than most people, what exception might of caused it?

I'm not aware of Tarrant finding any esm related bug? What he said about "save game compatibility" is simply a result of the file having a different name. If you rename any esp it's also for the game engine as if you removed the "old" one and added the "new" one. That's no different when you change your esp into an esm which changes the file name.

As tarrant has highlighted and I have often said myself, this will cause problems, it would solve a percentage of them but ESMs do have some quirks themselves.

I am interested to see what would happening running 50 big masterfiles, my gut tells me crash after crash, because in previous titles that might well of been the case. If we go this route it really is a matter of crossing our fingers.

I'm not aware of any problems or "quirks" with esm's in Fallout 3. (Given that all the official DLCs are esm's, the support for esm's is probably much much better tested on Beth's side then support for esp's, which I have to assume that they don't do any testing with whatsover).

I do also not see any reason why having 40 esm's loaded should result in any fundamentally different behavior then having 4 esm's loaded. There is a difference in behavior between esp's and esm's, yes. But beyond that difference, the number of loaded modules shouldn't make any difference.

As for "previous titles", you have to take into account that in TES4 all DLCs where esp's. So that's naturally what got tested with during development. I attribute esm oddities in TES4 to the fact that the developers never actively tested their engine with more esm's than the main Oblivion.esm loaded. For Fallout 3 the situation is exactly reversed. I very much doubt that the developers are actively testing with any esp's loaded. But because of the DLCs they HAVE to make multiple esm's work flawlessly together.

Also, the way that the ONAM subrecord is used in Fallout 3 esm's probably means that it's much easier to efficiently implement overrides then it is with esp's.

[Mr. Allen]

There are a few reports saying that parts of the Olney Powerworks vanish without 1.5

I think it might be a mod conflict, but I don't know.

Has anyone using Fakepatch with Broken Steel had this issue?

Only two people have brought this up, but I want to see if it's due to the lack of 1.5, or if it's because of a mod conflict.

[stevie critchley]

None that I'm aware of.

This gives me a lot more confidence in the whole concept as I do respect your opinion. I will cross my fingers indeed

[louise hamilton]

Bah. I can't play Broken Steel because of the save game bug. Anytime I save - BAM! - crash.

This needs to be fixed Beth.