Andrakann wrote:
Another strange thing is
Name entry - this entry must have name lenght in symbols for correct reading, and it have it, but in strange format, like mirrored byte:
![Image](http://i91.fastpic.ru/thumb/2017/0122/14/214310416f7f1885beedba7c18108914.jpeg)
...or in some hex format I'm not familiar with:
![Image](http://i90.fastpic.ru/thumb/2017/0122/47/66e9c3a93ad74131550899dfa755ef47.jpeg)
18 is 12h and 31 is 1Fh - I can see some logic here, but it's strange.
shakotay2 wrote:
Code: Select all
...
0x140b emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.753424 0.755402 -1.765556 0.753425 1.081711 0.620197
0x143e emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.966901 0.000073 -1.803357 0.966901 0.578240 -1.000934
0x1471 emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.815528 -0.002078 -2.096735 0.815527 0.179026 1.001929
0x14a4 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.961083 -0.000369 -2.319926 0.961083 1.047848 1.001929
0x14d2 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.802868 -0.000369 -2.130043 0.802868 0.184148 1.001929
0x1500 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.879130 0.141074 -0.786225 0.879130 1.016461 0.669687
...
An error here: "emaN`" is "Name 60h" where 60h is 6 symbols in name "Shadow".
This is (obviously) way late - but the short immediately preceding the string refers to the length of the String + that short, and the preceding 6 bytes.
So...it's something like this:
Code: Select all
char name[4]; //emaN
short unk1;
short unk2; //unk1 & unk2 may really be a a single int - much like the unknown int in both the preceding header, and entry structures.
short unk3; //len's length starts including from here.
short unk4;
short unk5;
ushort len; //(sizeof(short)*4)+length of string
char string[len-8];
or...
65 6D 61 4E E0 00 10 00
78 6F 42 42 80 01 16 00 62 75 6D 70 65 72 46 5F 61 5F 4C 4F 44 31
Where...
emaN
bumperF_a_LOD1 (14 bytes)
22 (8 bytes longer than string)
Part that's included in size
Now, one or more of those shorts likely indicate the type of name entry. Because there are at least two types.
The first has 4 [s]null bytes[/s] an unsigned int after the string, and is recognizable by unk3 having the value of 8224 (20 20) and unk4 having the ASCII value of dI (64 49)
The second has 6 floats after the string, and is recognizable by unk3 & unk4 having the ASCII value of xoBB (78 64 42 42)
Edit:
I'm continuing to use bumperF_a.modelbin from the Crown Victoria Police Interceptor (Forza 7).
I'm fairly confident that the entries look more like so:
Code: Select all
//start of "header"
char tag[4]; //emaN
ushort hshort1;
ushort hshort2;
//end of "header"
char type[4]; " dI" or "xoBB" (or even, MatI's "TSTA")
short unkShort;
short dataLength;
char text[dataLength-8];
//if type== " dI"
uint unkInt;
//if type=="xoBB"
float unkFloats[6];
//if type=="TSTA"
//nothing
Now, here's the fun part - after the full Name entries, there's a collection of "headerless" entries that omit the tag, and the first two shorts (i.e. first 8 bytes). With the exception of one, none of these have any actual text data - their "dataLength" fields are all set at 8 - or a zero length char array. The last of these name stubs, contains the seemingly nonsensical text of "feRTÀ " (66 65 52 54 C0 03 20 00)
To make things more annoying, after the collection of the "headerless" entries, the section is finalized with an int, followed by a collection of ushorts. In the case of this particular file, there are 28 "complete" Name entries, the aforementioned int, has a value of half of that, and there are 28 shorts. I'm guessing these are just offsets to something.
If the entire section needs to be read, including that short array, it's going to be obnoxious - especially considering that all sections make liberal use of padding. On the other hand, if it doesn't, then what's the point of it?