Sadly I don't think I have any of my really old savefiles anymore (I lost a lot of stuff when two of my harddrives failed in close succession) but here is one of my recent saves (unfortunately not that much playtime). I can provide more of those since I always save to about ten different slots (I'm really afraid of save corruption )

Last edited by dEnigma on 24 Jan 2015, 12:03, edited 2 times in total.

Some pirates achieved immortality by great deeds of cruelty or derring-do. Some achieved immortality by amassing great wealth. But the captain had long ago decided that he would, on the whole, prefer to achieve immortality by not dying

there's some bundle. couple of those 6 can be broken due to mods that i used. for same reason the playtime isn't bigger than ~10 game days. this pack is kinda ancient

adding to denigma's
does the essimporter --compare function work as making the line: --compare save1.ess save2.ess with essimporter.exe shortcut

Since 99% of the format is still unknown, I figured I'd post the method I am using in case others want to help.
Basically what I'm doing is load a save game in Morrowind, change one specific thing I'm looking for, save to a new file, then compare the two files. That is why I added a "--compare" switch to essimporter that compares two ess files.

running abovementioned runs the analysis if it's those zeros and maybe some numbers going fast in the console. is there a report saving function yet as it crashes on startup atm. wasn't the missing include as same in today's 4db6c22d.

Thanks for the files, most of them weren't parsing correctly, which is fixed now. When this goes into a release, I should probably add some sort of graceful handling for unexpected or out-of-order subrecords, rather than aborting with an error. But for the time being, this gets issues to my attention quickly which is good.

The more I decode the format, the more it convinces me we should have done this sooner... much sooner. Ideally before we started implementing our own save format.
In some instances, this reveals things we forgot to do.
In other instances, it reveals things we did better than the original does them... but in order to stay compatible, we'll have to implement the flawed solution anyway. And while doing so, maintain backwards compatibility with the existing OpenMW save files.
In (rare) instances, it reveals things we did plain wrong and will have to redo them.

What's giving me a headache right now are the differences with the journal. Put simply, the vanilla files store the journal as one continuous HTML blob, with no meta information on the date of the entry, or the info ID that caused the entry. Obviously this will make filtering difficult, say we want add a date range filter to the GUI later.
Quest states are stored with the quest name instead of the quest ID as identifier, which will conflict with our post-1.0 goals of making save files localization independent.
Another curious thing, the "seen responses" for a dialogue topic in the journal aren't actually stored verbatim, only the info ID. As result, if the dialogue response was "Hello %PCRank", the journal entry might change later to reflect changes in the player's rank, even if you haven't talked to that NPC since.
So now we're back to the original question - compromise on the quality of the save format, or compromise on having the importer require loading the ESM files, so that it can properly convert the data? This is a difficult one.

scrawl wrote:So now we're back to the original question - compromise on the quality of the save format, or compromise on having the importer require loading the ESM files, so that it can properly convert the data? This is a difficult one.

Ultimately, this is your and Zini's call.
My preference would be to NOT compromise the quality of save format, and require loading the ESM files.

One thought that occurs to me in terms of backward compatibility of save files.
How much work would it be to provide a stand alone converter to migrate old version save files to the new version?
That means the trunk codebase doesn't get cluttered with code to handle old savefile versions that are obsolete.

Ultimately the save converter was meant to be something of an extra feature, having it require the user to provide their esms does not seem that bad considering most people who have their old saves will also be likely to have their esms.

I may be biased on the issue, since I do not have any saves to convert, but in my opinion it would be more detrimental to skimp on the save format.

onionland wrote:people who have their old saves will also be likely to have their esms.

I agree with this. Your saved ess won't be that good to you in vanilla anyway if you don't have the esms. Compromising the save format seems like a road riddled with snakes, especially considering how likely it is that someone starts from an imported ess vs starting a new game.

An option I see though, is to have 2 versions of the import;
1. Lite: just save the basics, like name, skills, completed quests, etc. As much as possible without having the esms available. If something can't be figured out, either fall back to the defaults, make a guess or remove it.
2. Full: Everything is imported, but requires esms.

I am leaning more towards the esm loading solution too. But I wouldn't want to make an over-hasty decision here. Maybe I'll implement (or at least sketch out) both and see how they compare.

An option I see though, is to have 2 versions of the import;
1. Lite: just save the basics, like name, skills, completed quests, etc. As much as possible without having the esms available. If something can't be figured out, either fall back to the defaults, make a guess or remove it.
2. Full: Everything is imported, but requires esms.