Skyrim Mod talk:Mod File Format/QUST

FLTR

Sounds like a helper for the Creation Kit, IE a tree view with folders. —Rick 10:52, 10 November 2011 (UTC)

QUST structure

Here's my initial attempt at figuring out how the QUST fields nest for Tes5Mod, using the Tes4Mod structure as a starting point. There are a bunch of rare fields that I haven't tracked down, but from what I've seen so far, chances are that any field that doesn't appear here falls under ALST-ALID.

• EDID (1 / QUST)
• VMAD (0-1 / QUST)
• FULL (0-1 / QUST)
• DNAM (1 / QUST)
• ENAM (0-1 / QUST)
• FLTR (0-1 / QUST)
• NEXT (1 / QUST) -- seems to always be last field before starting CTDA and/or INDX fields -- but sometimes it's after the CTDA records, and sometimes before

• CTDA (0-many / QUST)
  • CIS2 (0-1 / CTDA)

• INDX (0-many / QUST)
  • QSDT (1-many / INDX)
    • CTDA (0-many / QSDT)
      • CIS2 (0-1 / CTDA)
    • CNAM (0-1 / QSDT)
    • SCHR (1 / QSDT)
      • SCDA (0-1 / SCHR)
      • SCTX (1 / SCHR)

• QOBJ (0-many / QUST)
  • FNAM ( 1 / QOBJ)
  • NNAM ( 1 / QOBJ)
  • QSTA (1-many / QOBJ)
    • CTDA (0-many / QSTA)
      • CIS2 (0-1 / CTDA)

• ANAM (1 / QUST)

• ALST (0-many / QUST) or ALLS (0-many / QUST) -- ALLS is only used when there are multiple ALID entries
  • ALID (1 / ALST) or (1-many / ALLS)
    • FNAM (1 / ALID)
    • ALNA (0-1 / ALID)
    • ALNT (0-1 / ALID)
    • CTDA (0-many / ALID)
      • CIS2 (0-1 / CTDA)
    • ALCA (0-1 / ALID)
    • ALCL (0-1 / ALID)
    • ALCO (0-1 / ALID)
    • COCT (0-1 / ALID)
    • CNTO (0-many / ALID)
    • KSIZ (0-1 / ALID)
    • KWDA (0-many / ALID)
    • ALFC (0-1 / ALID)
    • ALFE (0-1 / ALID)
    • ALFD (0-1 / ALID)
    • ALFR (0-1 / ALID)
    • ALPC (0-many / ALID)
    • ALUA (0-1 / ALID)
    • VTCK (1 / ALID) -- nearly always 1 / ALID, but does not appear within ALLS fields
    • ALED (1 / ALID) -- end of section marker?

--Nephele^Talk 01:21, 19 October 2011 (UTC)

CNAM oddity

I started off confident it was pointing to CELLs (0x3743, 0x3744). But then I noticed most of them have legit DLString lookup ids, context-specific definitely.

So I double-checked and 0x3743, 0x3744 are also in ILStrings, Strings but the text is way off (like 'Whirlwind Sprint' and 'I understand if you're not ready to go'. Every one of them that resolved to DLStrings was fine, but if it resolved to ILStrings or Strings it wasn't right. Those ids then mapped to CELLs with no EDID (so can't tell if they're appropriate or not).

The only thing I'm wondering is if maybe there's just a whole list of possible strings for it to use and if it fails lookup it goes to the next? That quest has like 6 different IDs that all point to the same string, and the 2 outliers are radically different as well.

I just can't see how CELL would be stuffed in there with an lstring. A good QUST to look at I think is dunFrostmereCryptQST (0x000CF915) - it has quite a few of those and decoding that quest pretty much will give you the entirety of the INDX records as there's a billion of them.

Anyway just thinking out loud I guess! --Themendios 07:50, 24 December 2011 (UTC)

Actually, I've never been sure where the oddity is with CNAMs. I've never had any trouble reading all CNAM records as string lookups -- and given that I've posted the quest stage info for every quest on the site, I'm pretty confident that I've looked at the majority of the quests in the game. Or at least that someone would have yelled even if I'd missed the strange-looking strings myself. SR:The_Pale_Lady#Quest_Stages shows the list of CNAM strings that I'm getting for dunFrostmereCryptQST, and none of them look odd. On which INDX/QSDT combos are you seeing strange CNAM values? --Nephele^Talk 08:34, 24 December 2011 (UTC)

I'm glad you posted that link cuz then I could look at the decoded info right next to it. You are right, it is resolving correctly to strings, I think I was looking decimal value 3744. Also the structure makes a lot more sense than it did last night, think I was too tired to tackle that monster.

While I'm here though I assume this page is a standard in certain areas based on the fact that you built the quest stages so I am reluctant to change it, but I am pretty sure it has the INDX record values flipped, ie 0/1 bytes = uint16 journal index not 2/3 (at least in the quest I mentioned that I was looking at). I'll leave it to you to verify/change since this still hasn't fully clicked with me yet. — Unsigned comment by Themendios (talk • contribs) at 17:58 on 24 December 2011

Ah, good point on INDX. I hadn't even noticed that INDX was now 4 bytes instead of 2 ;). And FYI, the Mod File Format pages don't contain any auto-generated content. Somewhat ironic given that nearly every Skyrim page contains auto-generated content derived using information about the file format. In fact, the Mod File Format pages don't even contain all the info that I've decoded about the format because I've been too busy with Skyrim pages :/ So I'm sure there are alot of similar tweaks/fixes that need to be made. --Nephele^Talk 21:24, 24 December 2011 (UTC)

yea i was thinking about that too (that none of it is auto-generated), i'm not sure how the hell that would work without wiping out progress until everything was figured out (and there are still TES4 unknowns years later) - i've made a ton of new pages with as much info as i could scrape together recently, i think once the original pages are up then it should get a lot easier to maintain — Unsigned comment by Themendios (talk • contribs) at 03:31 on 25 December 2011

I'm getting CNAM oddity too. In TES5 Edit, CNAM value is "In Reachwater Rock, ........", and I have confirmed that value is in not .STRINGS but .DLSTRINGS file. How could this be explained???
Screenshot (TES5Edit.exe): http//puu.sh/6A6kg.png (add colon to see screenshot in url)
Screenshot (HxD.exe): http//puu.sh/6A6mC.png
— Unsigned comment by 116.40.252.227 (talk) at 15:18 on 27 January 2014

Well, all the strings documented here as "lstring" can be either found in STRINGS, DLSTRINGS or ILSTRINGS. In my experience the string id is unique over all three files, so one can just lump them all together when reading data. There was recently an effort do document per field which of the three files holds the string (denoted with dlsting and ilstring). But I guess this would need making sure that the file used is indeed determined by the field and not by something like string length. --Alfwyn (talk) 15:55, 27 January 2014 (GMT)

Yeah, it appears that they're unique across the files. I hadn't noticed that. That would probably make documenting which file they come from redundant, then. I've currently got them as three separate collections, so it's very obvious which file a given string can be found in, since the others will fail. So far, any given field has always come from the same file for all values in that field. I'll have to keep the uniqueness in mind for v2 of my TES reader, though; that'll make things much simpler. – Robin Hood  ^(talk) 18:25, 27 January 2014 (GMT)