The working assumption at the moment is that Skyrim will use a mod file format similar to that used by Oblivion. However, various changes introduced for Fallout 3 are likely to be incorporated into Skyrim, too. The best documentation of the Fallout3.esm format that I can find is here.
Key differences that I've noted with Fallout3 are:
- The headers for both records and groups (but not subrecords) are 4 bytes longer than in Oblivion (24 bytes total instead of 20). The extra 4 bytes is assumed to be flags, but the meaning of the flags does not appear to be known.
- This is the only change that was made to the fundamental structure of the file -- GRUPs, records, and subrecords are used in the exact same way; XXXX subrecords are used for oversized subrecord lengths; compressed subrecords exist and are identified with the same flag.
- References to magical effects use the effect's refID instead of the EDID, making magical effects more consistent with all other references. The data is still stored as 4 bytes, but the 4 bytes are an integer instead of a string such as 'FIDG'.
- There are no SKIL records in Fallout3 -- AVIF (Actor Value Info) records are used instead.
- Skill perk information is in PERK records.
Of course, there are also differences in various details of the individual subrecords -- although fewer than might be expected.
- In case anyone's interested, here's a breakdown of the different types of record used by Fallout3.
- I agree that the new field in each record's header is almost certainly flags. The number of records with bits 0, 1, 2 and 3 set is huge - about 75% of them. Bits 4-15 are only set in a tiny fraction - roughly 0.5%. There's another large group with the first few bits of the upper 16 bits set too. rpeh •T•C•E• 07:11, 8 October 2011 (UTC)
|Record Type||Fo3 Count||Data Object||F:NV Count|
|ALOC||Media Location Controller||89|
|ASPC||59||Space-related sound effects (reverb, etc.)?||113|
|AVIF||60||Actor value information||64|
|BPTD||32||Body part data||49|
|CDCK||Decks of Cards||13|
|DEHY||Dehydration level (Hardcore mode)||5|
|DOBJ||1||Default Object Manager||1|
|FLST||243||Form ID List (non-leveled level list?)||464|
|HUNG||Hunger level (Hardcore mode)||5|
|IPDS||41||Impact Data Set||60|
|LSCT||Load Screen Type||1|
|SLPD||Sleep Deprivation (Hardcode more)||5|
* Probably more than this but my code crashed
This is me just nitpicking, but would it not be better to have the page (and sub-pages) named 'Plugin File Format' rather than 'Mod File Format'? Seems more appropriate. —Rick 05:28, 10 November 2011 (UTC)
- It might be good to have a redirect from Plugin File Format to here, but I'm not sure about actually renaming the page. Although I suppose I don't feel too strongly either way. --NepheleTalk 05:43, 10 November 2011 (UTC)
- I figured I would bring it up before the pages started being created and getting fleshed out. —Rick 05:54, 10 November 2011 (UTC)
General Skyrim ChangesEdit
Just wanted to make some quick notes about some key things that are different processing Skyrim data.
- Strings, which have already been covered elsewhere.
- Used for a lot of flags/type information (e.g. weapon types all tracked via 'WeapType%' keywords; armor types tracked via 'ArmorHeavy'/'ArmorLight')
- Keywords themselves are in rectype KYWD
- Vast majority of rectypes contain KSIZ and KWDA subrecords. KSIZ is the number of keywords. KWDA is then 4*KSIZ bytes in size, containing KSIZ formids pointing to KYWD records.
- All creature-related information has been wiped out. No CREA, ACRE, LVLC rectypes exist. Instead there are now 99 races -- including Wolf, Fox, Giant, Wisp, Draugr etc.
- No CLOT records any more. All included in ARMO, with ArmorClothing and ArmorJewelry keywords (generally) identifying the non-armor items.
Sorry about not discussing it, but I was attempting to clean the page up to use official terminology (they're called forms by the game engine). —Rick 06:09, 13 November 2011 (UTC)
- Yeah, I realized with the FormID that we've got somewhat of an inconsistency there. But at first I had no idea what the page was talking about with forms, so I'm guessing other readers might have the same issue. --NepheleTalk 07:56, 13 November 2011 (UTC)
- No problem with having it as record for clarity then. —Rick 08:34, 13 November 2011 (UTC)
I'm extending CBash 0.6 for Skyrim support, could serve as reference-implementation.
12 mystery record typesEdit
Thes were in the main record type table. No grup, no records, maybe these came from FO3/FONV?
- NOTE - Note
- PCON -
- PARW -
- PBAR -
- PBEA -
- PFLA -
- PMIS - Placed missile
- SKIL - Skill
- TLOD -
- TOFT -
- MICN - Menu Icon — Unsigned comment by Themendios (talk • contribs)
oh they came from here: http://www.uesp.net/wiki/Tes5Mod:Forms/18.104.22.168
well since this is the mod file format and they're not in mod files i assume there's no objections? if not then i'll just delete this note in a couple days —Themendios 16:48, 27 December 2011 (UTC)
As near as I can determine, the stamp property isn't in MS-DOS format as I understand it (e.g. ). Suspiciously, the first of the four bytes in the sequence has a range of 1 to 30 in Skyrim.esm, the second and third bytes seem to have a very narrow range of values, and the last byte is always 0. Does anybody else have any thoughts on this? For reference, I've posted the full list of stamp data from the top-level groups below.
At a cursory glance of Oblivion.esm, the dates in TES 4 also don't look to be MS-DOS format, so either I have a different understanding of what MS-DOS formatted dates are, or we'll need to correct the information there as well once we figure it out. – Robin Hood↝talk 21:21, 29 March 2012 (UTC)
- Poking around some more, I found the Revision format, and that seems like a more likely bet for the stamp format. Using that, I get dates ranging from January 17, 2008 to September 29, 2010 in Skyrim.esm (with the exception of the very last GRUP record, which is February 1, 2003), and October 12, 2011 to February 9, 2012 in Update.esm. – Robin Hood↝talk 21:54, 29 March 2012 (UTC)
- Okay, this almost certainly is the same format as the revision, and it looks like we've got it wrong on Oblivion. As I've stated in the article, the high byte of the 16-bit value is the number of months since December 2002, not the complicated thing we have currently in Tes4Mod. I seem to be having some oddness with testing this in Oblivion right now, though, as everything is reverting to month 03. All the old stuff I have saved, though, the calculated date matches (or at least is similar to) the last release date of the mod. Same with all the Skyrim mods I tested. I'm assuming the other 16 bits is the check-out log, like in Oblivion, but I have no way of confirming that. – Robin Hood↝talk 00:40, 30 March 2012 (UTC)