|
Forum > Development and Presentation
[QUESTION] Parsing ADTs..
(1/2) > >>
Neglected:
Hey there guys :)
Right now I'm working on a small project where I parse ADTs and WDTs and then display them in an OpenGL window. Nothing too special, just to test mah skeeeelz as it were.
Anyway, I've run into a roadblock parsing ADT files. The issue being that, while I can read every chunk header absolutely fine, and all the data from a WDT file just fine, any data in the ADT seems to be out of whack. See below for more on what I mean..
--- Code: ---MHDR: flags=0
MHDR: OffsetInfo=0
MHDR: OffsetTex=0
MHDR: OffsetModel=0
MHDR: OffsetModelId=0
MHDR: OffsetMapObj=0
MHDR: OffsetMapObjId=0
MHDR: OffsetDoodadDef=4251
MHDR: OffsetObjDef=4243
MHDR: pad1=4235
MHDR: pad2=4227
MHDR: unk1=4219
MHDR: unk2=4211
MHDR: unk3=4168
MHDR: unk4=64
MHDR: unk5=-1097516758
MCIN: entry0={flags=1740, aSyncId=450019, MCNK_Offset=0, size=0}
MCIN: entry1={flags=1740, aSyncId=448271, MCNK_Offset=0, size=0}
...
MCIN: entry251={flags=1740, aSyncId=11271, MCNK_Offset=0, size=0}
MCIN: entry252={flags=1740, aSyncId=9523, MCNK_Offset=0, size=0}
MCIN: entry253={flags=1740, aSyncId=7775, MCNK_Offset=0, size=0}
MCIN: entry254={flags=1740, aSyncId=6027, MCNK_Offset=0, size=0}
MCIN: entry255={flags=1740, aSyncId=4279, MCNK_Offset=0, size=0}
MTEX: texture_path_34=
MCNK: flags=0
MCNK: indexX=1296257861
MCNK: indexY=0
MCNK: nLayers=1296253260
MCNK: nDoodadRefs=0
MCNK: ofsHeightMap=0
--- End code ---
The above is an excerpt from the log that I write to every time I parse a file. I parse a file by creating a new instance of my Chunk class (which automatically reads the Chunk header in the current input stream and automatically reverses the data so it's in BIG_ENDIAN rather than LITTLE_ENDIAN. I'm following the Wiki TO THE LETTER on the info about ADT and it jut seems that the numbers are parsing incredibly wrong. Take MCNK.nLayres, which is 1296253260, for example. It just doesn't seem right.
Any ideas on where I am going wrong?
My thoughts are that the wiki lists the ADT format in Little Endian.
EDIT: And posted in the wrong forum. Sorry, I googled and found another support post in this forum and thought "OHAI I'LL POST HERE". :c
schlumpf:
You're having a pointer off. Your nLayers is the beginning of a zero-size MCAL. Seems like you're taking the wrong offset to start at.
Also: the wiki is on WotLK files!
Neglected:
--- Quote from: "schlumpf" ---You're having a pointer off. Your nLayers is the beginning of a zero-size MCAL. Seems like you're taking the wrong offset to start at.
Also: the wiki is on WotLK files!
--- End quote ---
Ah awesome, thanks. :)
And I'm using the custommap1 blank map from these forums :P
What I was doing is using a FileInputStream in Java and reading chunks by finding the chunk header and then turning that into a ByteBuffer - reading procedurally. Gonna try and find this MCAL now. Thanks for your help Schlumpf. :)
EDIT: When you were talking about MCAL I assume you were talking about it at the end of my parse; I was more concerned with the start of the parse. I reversed the read direction (back to little endian) to get this:
--- Code: ---MHDR: unused4=0
MHDR: unused3=0
MHDR: unused2=0
MHDR: unused1=0
MHDR: offsetMTFX=0
MHDR: offsetMH2O=0
MHDR: offsetMFBO=0
MHDR: offsetMODF=4251
MHDR: offsetMDDF=4243
MHDR: offsetMWID=4235
MHDR: offsetMWMO=4227
MHDR: offsetMMID=4219
MHDR: offsetMMDX=4211
MHDR: offsetMTEX=4168
MHDR: offsetMCIN=64
MHDR: flags=-1097516758
--- End code ---
Which makes more sense - but those flags.. wtf is up with that? Is that intended or is it a red herring?
Steff:
You should use original blizz files for such a test. The custommap files are created with taliis. So it can be that they are not 100% ok.
schlumpf:
Add 0x14 to all offsets.
You may always want to start reading a chunk by comparing the identifier. At 0x0 in the file you should get 'MVER'.
This is not the case with your reading. It is not the file being wrong, but as said, you reading starting at the wrong position.
Navigation
[0] Message Index
[#] Next page
|