- BYTE length
- CHAR[length]
Is there a guaranteed null byte at the end? That's what I'm seeing in the HIM files with the "quad" string:
- 0471 7561 6400 .quad.
Though I'm not sure if the null is part of the next data segment.
EDIT: MSDN states it's
- DWORD length;
- CHAR[length];
- SHORT null = 0;
but that's not what I'm seeing in these formats.
EDIT2: also, working on the HIM format, I'm seeing an extra SHORT before each FLOAT in the points list (first loop). As well, I'm also seeing an extra DWORD (or some 4 byte construct) in the header (before the point list).
This is from client v162. Going to hold off on HIM support right now because it's obviously not correct.
For completeness, here is the full HIM file I'm working with. It's from Junon 29_29, client v162.
http://pastebin.com/c8Lp1zKW
And just the first portion, since I know stuff on this forum gets outdated/broken pretty often:
- 0000000: 4100 0000 4200 0000 0400 0000 0000 7a43 A...B.........zC
- 0000010: 0000 c3ba c383 0000 c3ba c383 0000 c3ba ................
- 0000020: c383 0000 c3ba c383 0000 c3ba c383 0000 ................
- 0000030: c3ba c383 0000 c3ba c383 0000 c3ba c383 ................
- 0000040: 0000 c3ba c383 0000 c3ba c383 0000 c3ba ................
- 0000050: c383 0000 c3ba c383 0000 c3ba c383 0000 ................
- 0000060: c3ba c383 0000 c3ba c383 0000 c3ba c383 ................
- 0000070: 0000 c3ba c383 0000 c3ba c383 0000 c3ba ................
- 0000080: c383 0000 c3ba c383 0000 c3ba c383 0000 ................
- 0000090: c3ba c383 0000 c3ba c383 0000 c3ba c383 ................
- 00000a0: 0000 c3ba c383 0000 c3ba c383 0000 c3ba ................
- 00000b0: c383 0000 c3ba c383 0000 c3ba c383 0000 ................
- 00000c0: c3ba c383 0000 c3ba c383 0000 c3ba c383 ................
- 00000d0: 0000 c3ba c383 0000 c3ba c383 0000 c3ba ................
- 00000e0: c383 0000 c3ba c383 0000 c3ba c383 0000 ................
- 00000f0: c3ba c383 0000 c3ba c383 0000 c3ba c383 ................
[hr]
Now I'm on to IDX. Similar problem; the format isn't quite right.
Here is what I'm finding:
- c28b # magic (?)
- 0000 00c2 # base version
- a200 0000 # current version
- 0600 0000 # num. VFS files
- # DATA vfs
- 0900 # filename length
- "DATA.VFS"
- 00 # null
- 6a00 0000 # file offset
- 00 # null byte (?)
- # MAP vfs
- 0800 # filename length
- "MAP.VFS"
- 00 # null
- c394 c393 0400 # unknown
- # GROUND vfs
- 0b00 # filename length
- "GROUND.VFS"
- 00 # null
- 2ac3 8415 00 # unknown
- # 3DDATA vfs
- 0b00 # filename length
- "3DDATA.VFS"
- 00 # null
- 7c27 1900 # unknown
- # BASIC vfs
- 0a00 # filename length
- "BASIC.VFS"
- 00 # null
- 731b 1e00 # unknown
- # ROOT vfs
- 0900 # filename length
- "ROOT.VFS"
- 00 # null
- c2a3 0e1e 00 # unknown
And then the format seems to continue normally.
All of the unknowns seems to end in a null byte, but only the first VFS entry (DATA.VFS) actually adheres to the structure.
Here is the first portion of data from data.idx, client 162:
- 0000000: c28b 0000 00c2 a200 0000 0600 0000 0900 ................
- 0000010: 4441 5441 2e56 4653 006a 0000 0008 004d DATA.VFS.j.....M
- 0000020: 4150 2e56 4653 00c3 94c3 9304 000b 0047 AP.VFS.........G
- 0000030: 524f 554e 442e 5646 5300 2ac3 8415 000b ROUND.VFS.*.....
- 0000040: 0033 4444 4154 412e 5646 5300 7c27 1900 .3DDATA.VFS.|'..
- 0000050: 0a00 4241 5349 432e 5646 5300 731b 1e00 ..BASIC.VFS.s...
- 0000060: 0900 524f 4f54 2e56 4653 00c2 a30e 1e00 ..ROOT.VFS......
- 0000070: 4f13 0000 0300 0000 0000 0000 1d00 3344 O.............3D
- 0000080: 4441 5441 5c41 495c 4141 4a55 2d41 5155 DATA\AI\AAJU-AQU
- 0000090: 4147 5541 5244 2e41 4950 0000 0000 00c3 AGUARD.AIP......
Can anyone shed some light as to what those unknowns are?