Jump to content
Sign in to follow this  
Qwinn

PST CRE file, offsets 2e1, and 2b8-2bb

Recommended Posts

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

Share this post


Link to post

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.

Edited by Kung Fu Man

Share this post


Link to post

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.

Share this post


Link to post

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.

Edited by Displacer

Share this post


Link to post

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 :hm:)

 

EDIT: Looks like all color placement values are ran through these operations in a loop, not just the first one.

Edited by Displacer

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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"

Share this post


Link to post

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.

Edited by devSin

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...