Here is my idea:
We create two new file types (with new icons, extensions and everything):
1. The base file. Proposed extension: .omwbase. Any stack of content files will contain exactly one of these files. A base file must not depend on anything else.
2. The extension file. Proposed extension: .omwext. Any stack of content files will contain zero or more of these files. An extension file must depend on an extension file or a base file.
OpenMW and the editor would still be able to read legacy file formats, but the editor can only write the new file format. When loading the old file formats these would mapped to the new ones by the following scheme:
- If the file is an ESP, it is seen as an omwext file (all plugins).
- If the file is an ESM, that does depend on another file, it is seen as an omwext file (Tribunal.esm and Bloodmoon.esm)
- If the file is an ESM, that does not depend on another file, it is seen as an omwbase file (Morrowind.esm).
The actual content of the omwbase/ext files would be identical to the ESX files but for one difference:
Instead of the old header record (TES3), we have a new type of header record.
For reference here is the old record:
Code: Select all
TES3 = 1 count Main Header Record, 308 Bytes HEDR (300 bytes) 4 bytes, float Version (1.2) 4 bytes, long Unknown (1) 32 Bytes, Company Name string 256 Bytes, ESM file description? 4 bytes, long NumRecords (48227) MAST = string, variable length Only found in ESP plugins and specifies a master file that the plugin requires. Can occur multiple times. Usually found just after the TES3 record. DATA = 8 Bytes long64 MasterSize Size of the previous master file in bytes (used for version tracking of plugin). The MAST and DATA records are always found together, the DATA following the MAST record that it refers to.
Here is the proposed replacement header:
Code: Select all
OMWH COMP int, 4 bytes: Engine compatibility version; value: 1 (replaces first entry in TES3.HEDR) AUTH (optional) string, variable length: Author name (replaces 3. entry in TES3.HEDR) DESC (optional) string, variable length: Content description (replaces 4. entry in TES3.HEDR) DEPE (optional, multiple instances, not allowed in omwbase files) FILE string, variable length: name of the content file this file is based on (replaces TES3.MAST) SIZE (optional) int, 4 bytes: size of the file specified in FILE (replaces TES3.DATA)
Regarding COMP: The switch from float to int should be obvious. float is a horrible choice for specifying a version number. Note that we do not use OpenMW version numbers here. Instead we are using a flat integer file format version number. This has the advantage that we can vary these independently. Obviously we will have to increment this number each time we release a new version of OpenMW, that provides new features with new data structures. But there may also be releases, that do not make any changes to the world model. In this case we can keep the COMP value.
I guess I don't need to mention that newer releases of OpenMW/CS should always be able to read file formats with lover COMP values.
This is a bit different from the original TES3 record. I reorganised it, because I am wary of the DATA/SIZE sub-record. It does not look to me like a reasonable method to track dependency version changes. I would like to keep the option to add other methods in the future. The new format should allow for easy additions of this kind.