Displacer Posted August 1, 2009 Share Posted August 1, 2009 Bit of an update, depending on a compare between the byte at 0x2F4 and the byte at 0x2F6, the byte at 0x2F4 overwrites the byte at 0x2F6. Here's the relevant code: .text:00766CEF mov cl, [eax+7DCh] ;0x2F6 in cre file .text:00766CF5 mov edx, [ebp+var_1C] .text:00766CF8 xor eax, eax .text:00766CFA mov al, [edx+7DAh] ;0x2F4 in cre file .text:00766D00 cmp ecx, eax .text:00766D02 jge short loc_766D16 .text:00766D04 mov ecx, [ebp+var_1C] .text:00766D07 mov edx, [ebp+var_1C] .text:00766D0A mov al, [edx+7DAh] ;0x2F4 in cre file .text:00766D10 mov [ecx+7DCh], al ;0x2F6 in cre file Link to comment
Kung Fu Man Posted August 1, 2009 Share Posted August 1, 2009 Well whatever it does I can help confirm it isn't a clownclr slot: if you look at the related IDS file for color placement you'll see that it only has 7 options, so an eighth wouldn't do a whole lot. As for 2F2-2F4...these are odd. In the CRE they're usually set up as: In clown colored character: 20 00 20 In true color character (i.e. Black Abashai) 0c 00 80 Deionarra, ROYALGD: 0c 00 0c Hope that narrows it down some. Link to comment
Displacer Posted August 1, 2009 Share Posted August 1, 2009 Well its some sort of override, but I don't know what for. The byte at 0x2F4 only overwrites the one at 0x2F6 if the value at 0x2F6 is lower than the value at 0x2F4. Link to comment
Displacer Posted August 1, 2009 Share Posted August 1, 2009 Arg, hold on I think my list has another spot that's off by a couple of bytes. Disregard everything I wrote today... Ok, not too much damage. What I had marked as 0x2F4 and 0x2F6 are actually 0x2F2 and 0x2F4. Link to comment
Displacer Posted August 1, 2009 Share Posted August 1, 2009 Are we sure color placement 1 doesn't have more to it? There's a sub that's doing a whole lot of logical operations on that entry, AND's, OR's shifts, etc. (and yes I'm sure this time, I fixed my offsets ) EDIT: Looks like all color placement values are ran through these operations in a loop, not just the first one. Link to comment
Kung Fu Man Posted August 1, 2009 Share Posted August 1, 2009 Pretty sure, there's really no place for it to go. Most likely from my guess what you're seeing there is the game processing the weapon color, overriding the Metal slot with it. Link to comment
Displacer Posted August 2, 2009 Share Posted August 2, 2009 Got some info on the color placement values. A struct is built out of these values in memory, I don't know how the struct is used in the game, but here's some info, note this is the struct as its in memory: 0x00 Byte from 0x2F2 0x04 Byte from 0x2F4 0x08 Byte from 0x2F3 0x0C - 0x12? Data from the color placement values, each byte position possibly is where the color goes (hair, skin, etc.) The first thing that happens when processing the value in a color placement slot is the high bit is checked. If it is not set then it is not processed further. If it is set bits 4, 5, and 6 are stripped off and they are used for a number between 0 and 7 (or possible 1 - 7, not sure yet) which is used as an offset in the above struct at 0x0C to store data from this number (e.g. if the number stripped off is 4, then data would be stored at 0x0C + 4) Several bits are then checked in the color placement value and these are acted on. Finally the loop goes on to the next color placement slot. Just a guess but bit 8 I assume is a flag for a valid color placement value. The number built from bits 4 - 6 are where the color is used (i.e. hair, skin) and is a offset from 0x0C in the struct, and the rest are flags for something, not sure what though. Link to comment
Displacer Posted August 2, 2009 Share Posted August 2, 2009 Ok, just to recap and to get it straight in my own head as NI knows what these values means, the value in a color placement is composed of the following: Upper nibble is a flag and the actual placement. The high bit is set if its a valid placement value, and the remaining value is the actual placement (skin, hair etc.) The lower nibble is a set of flags, bit 0 is a hologram flag, and bit 1 is a pulsate flag (according to NI). Bit 2 is not used and bit 3 is always set manually by the engine regardless of what the value actually is. So now the question is what are the other 3 bytes used for (0x2F2 - 0x2F4)? They are going into this color struct so they have something to do with the colors. Link to comment
igi Posted August 29, 2009 Share Posted August 29, 2009 I've added most of this info to my IESDP local copy, but I'm a little confused by this: 0x29: bit 0 - True color yes/no bit 1 - Unknown bit 2 - Unknown bit 3 - Unknown bit 4 - Unknown bit 5 - Per pixel blending 0x28 is currently defined as a dword representing animation. If the values listed above are corrected, it this a subset of 0x28 (i.e. the 0x28 dword still represents animation, but with some of the flags inside the dword altering the animation type) or is 0x28 split into multiple fields? Note to self: Integreate "Posted Aug 2 2009, 09:23 PM" Link to comment
devSin Posted August 29, 2009 Share Posted August 29, 2009 I believe only the initial WORD is used. I think they're hinting at how the BIS animation IDs are constructed (e.g., 0xE010 isn't just some made up number for the fun of it). I'd not document it for now until we understand more of it. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.