Question regarding 2.B. Clean the Update ESM

[TheOne320]

I am following "2.B. Clean the Update ESM" in the STEP guide v.2.2.9.1 and in step 11. the overwrite should turn red and the update.esm should appear in the overwrite list. This is not the case. The only thing in the grey overwrite is the "TES5Edit Backups" folder. I am using MO v.1.3.8 and TES5Edit v.3.1.1. What could I be doing wrong?

[DoubleYou]

What do you mean by "MO does not register the change of the update.esm." The file is cleaned, is it not? That's the whole end goal.

 

I will try to revise the guide to account for this irregularity.

[TheOne320]

Yeah, but MO is supposed to catch the change of the esm and put it in "overwrite" so I can create a "mod" of that.

[DoubleYou]

If you really want to have the "mod," you can simply copy the ESM and put it in the mods directory inside a new folder.

[GrantSP]

You know what... The reason for all this: the behavior will vary across different systems because MO uses a timeout to determine whether a file is overwritten or not. I forgot about this, so that is the cause for the confusion: there are two possible outcomes dependent upon how fast the file is saved.

As much as I don't want to question this, I will.

While it may be the case, this represents a significant change in program behaviour and I don't recall seeing any mention of this in changelogs.

We need to have definitive answer for this since my hardware has remained unchanged and the behaviour is different with the later versions. If this behaviour is hardware dependent, then fine we add a note to the guide. If it isn't then we also need to know what conditions trigger this difference.

 

Just downgraded to 1.2.18 and cleaned Update.esm and this time the file in 'Data' is being updated and only the backups are in 'Overwrite'.

Reverted my install to 1.3.8 and then cleaned Dawnguard.esm and MO moved the cleaned ESM out of 'Data' into the 'Overwrite' along with the backups.

 

For whatever reason MO 1.3.8 is moving the file but not copying it back. 1.2.18 is just editing it in place and placing the backups into 'Overwrite'.

[DoubleYou]

It isn't a significant change. It's been like this for a long time with the hooking procedure of MO. MO uses a guess procedure connected to time, if I remember correctly from Tannin explaining it, that enables MO to replace a file. All that would require for behavior to act different in cases like this would be a subtle difference, say an addition to fix some other random thing, to add a little more time between file creation and the guess timeout to create this phenomenon.

 

And the changes in this kind of behavior have never appeared on the changelog as far as I can remember (and that has been a while - back when 0.12.9 was the stable version...). And it probably has never been something intentional. I suspect that the optimizations that Tannin made to the hook with the 1.2 series changed the behavior because of the speed difference, and a change in the 1.3 series just added a little more time to it that changed it for us with slow HDDs.

 

But... since SSDs have been mentioned... that opens up another possibility. Perhaps MO will not change the files, but merely overwrite them, when the MO program is located on a different drive than the file being modified.

 

Whatever the case, it seems that both are possible outcomes, and it is simple to merely support both possibilities.

[GrantSP]

You and I clearly have a difference of opinion as to what constitutes a significant change. The ethos of MO is to maintain a pristine Data folder so that nothing the modder/user does will affect the vanilla game, this flys in the face of that.

Take a user that is migrating to MO and is still examining the details of the program. Suppose they have cleaned their plugins and, for whatever reason, starts a vanilla game from the desktop. The result: instant crash with the thought in their mind now - "MO stuffed my game".

 

Every other edit made to plugins in the 'mods' folder result in the original being updated and the backup being created. To have the original plugins in the Data folder moved is counter-intuitive and needs to be addressed.

 

Anyway, this whole discussion may be moot if @Tannin's comments in Bug Genie are anything to go by. It would appear that an entirely new, rewritten hook library is to be released sometime in the near future. Let's see if that procedure makes a change to this.

[DoubleYou]

I understand the sentiment, and agree, but in practice, we do with what we got. All you would need to do in this case is Verify Steam Cache and the uncleaned files would restored.

 

And the "MO stuffed my game" mentality is always a legitimate possibility that all modders must accept. If you mod your game, you will crash at some point. It's just the way modding goes. One needs to learn to deal with that and remember that the mods are free.

 

And yes, it is moot once Tannin changes the hook.

 

The only way that this could be "fixed" is by having two separate hooks with an advanced toggle between both to remove MO "replace file via guess" functionality, which I would be highly in favor of. If that happened, we could probably allow DynDoLOD create its files into Overwrite naturally.