Zini wrote:None of these deficits are causing us any problems at all.
I disagree. We may be handling it, but it's still not an ideal situation, IMO. Don't forget too that so far we've only been handling Morrowind.esm... we have no idea what it will be like once we gain support for the thousands of available mods.
We should also consider content creators and 3rd party tools. A robust format should be simple to create, with a clear definition. Errors in the data should be easy to spot, report, and handle. An ESM-like format doesn't do any of this: the format leaves a lot of questions (are sub-records order-sensitive? can they be missing to specify a default? do the FOURCCs actually have meaning beyond being an ID for the loader?), and errors in the data are difficult to deal with (what do we do if a sub-record has an unexpected size? what if there's an unexpected sub-record?).
Besides, even if we can handle the majority of mods, it's still a poor format. If we're going to do something new and incompatible, we may as well do it correctly. It's different anyway, so let's take the opportunity to clear up the problems with the format, to make it robust, easy to understand, and easy to handle, with as little guesswork as possible (for both us, and makers of 3rd party tools).
Switching from something that works well to something else that we would still need to get working doesn't look like a wise move to me.
Just because we can handle what we've been so far been able to test doesn't mean it "works well". Like I said before, the data format of the game should be closely tied to the way it's handled internally. We currently treat it as a data stream that gets transformed into easier-to-handle data structures, rather than handling the records and sub-records themselves. It wouldn't at all surprise me if the vanilla game has accessor methods to read/write/create whatever (sub-)record is needed directly, and loads the esm/esp/ess files into a flat chunk of memory.
Mixing up save files with content files would be bad. Wouldn't work anyway, because the data in a save file is notably different from the data in a content file. A clear no to that.
The save file is effectively just a patch on top of the esm/esp data. It contains extra information you wouldn't normally find in esm or esp files, true (since it's working with an active game rather than specifying what to start the game with), but it also contains a lot of the same information and is a patch very similar to an esp (e.g. a moved/modified reference in a save game is the same as a moved/modified reference in an esp).
I do see your point about ESP and ESM being the same. That would also be true for omwbase and omwext for the most part. The difference is more of a semantic nature. An omwbase file represents a game. An omwext file represents an extension to an existing game. For the end user that would be an important difference IMO.
Personally, I don't see the need to separate the two. It's all game data. Sometimes they require other game data, sometimes they don't. It just creates confusion to arbitrarily split 'base' from 'ext'. Someone will say something should be 'base', another will say it should be 'ext', even though it's all the same.
What I'd like to see is a combined BSA/ESP setup. You have an archive (BSA, zip, 7z, whatever), and in the root of the archive are files that act as ESM/P files. You'd enable this package to enable a mod, then the data files (sounds, textures, meshes, etc) will be used by the game as well as the ESM/P files. Disable it, and none of it will be used. The package could be extracted into a directory if you want more control over what's actually used, but for the majority of mods you'd just enable the package and play.
