openmw.org

Lazaroth wrote:I searched the depths of my harddrive for some old ess backups and found one! It's big, so I've probably played for a while.

Thanks! Found a parser issue with the help of this file. Also the imported save fails to load, which I'm looking at now.

Here's the largest one I found on my HDD (from way back when)

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 )
P.S. Would it help you if I created a new save with loads of mods installed?

edit: Oh yeah, I probably used Morrowind Code Patch in the save, if that makes a difference

edit2: Uploaded archive with all the savefiles I found on my drives (it's not much, a lot of those are from the same character [Staudey]): https://drive.google.com/file/d/0B3JB0_ ... sp=sharing

https://www.dropbox.com/s/pj0qrtxslyrnc ... s.rar?dl=0

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.

(edit: running openmw-essimporter <options> infile.ess outfile.omwsave\nAllowed options

importer works with infile and outfile specified. others not.
https://bugs.openmw.org/projects/openmw ... r/main.cpp
c++ anyone?)

windows xp 32-bit.

Althought kinda inefficient there would be kinda ways to build those characters. With napshots or not this could do it. http://www.fliggerty.com/phpBB3/cne/cne_main.php .p

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.

That's just my two cents though.

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.

This is an interesting idea.