Jump to content

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


Qwinn

Recommended Posts

Ah yep, your math's slightly :hm:

 

7C8h - 510h = 2B8

 

2B8 + 28 = 2E0

 

That makes a lot more sense too, since the bit array is there.

 

Yea, I just found it too. I wrote down the wrong memory span in my notes on a previous entry and was off by 0x10 bytes. Ugg, I have to rewrite my list now because that makes everything below it off by 0x10 as well. Fortunately it was just after 0x293 so everything above that is ok.

Link to comment

Well you were right about something. 0x29 seems to be involved in a bitcheck to see if the character is clown-colored or not, which explains why the values Exxx and 6xxx were used in the ANIMATE.IDS file.

 

I haven't gotten bit 0 or bit 1 of 0x2E0 to affect this though and modifying any other bits of 0x29 causes a crash. Though if I'm correct the engine is probably just handling bit 1 internally, which is why it's not saving to the GAM file at all possibly? Something else might be working here too of course.

Link to comment
Well you were right about something. 0x29 seems to be involved in a bitcheck to see if the character is clown-colored or not, which explains why the values Exxx and 6xxx were used in the ANIMATE.IDS file.

 

I haven't gotten bit 0 or bit 1 of 0x2E0 to affect this though and modifying any other bits of 0x29 causes a crash. Though if I'm correct the engine is probably just handling bit 1 internally, which is why it's not saving to the GAM file at all possibly? Something else might be working here too of course.

 

Yea, my screw up won't affect the fact that the high bit is getting set at 0x28. Now that I have my list fixed up let me see what else I can find.

Link to comment

I'm having trouble following you guys a bit (I can't read decompiled code yet, for example, even though I took assembler once :/ ) but....

 

"I haven't gotten bit 0 or bit 1 of 0x2E0 to affect this though"

 

Bit 1 of ox2e0 is "transparency" from the list I gave.

 

Qwinn

Link to comment
I'm having trouble following you guys a bit (I can't read decompiled code yet, for example, even though I took assembler once :/ ) but....

 

"I haven't gotten bit 0 or bit 1 of 0x2E0 to affect this though"

 

Bit 1 of ox2e0 is "transparency" from the list I gave.

 

Qwinn

 

He meant, he tried to find if any bits affect clown color.

The fact that invulnerability and half transparency is set by 0x2e0, but clown color is set by 0x29 (high byte of the animation ID) makes us a bit suspicious.

Link to comment

Yep, I was curious if 0x28 would be affected if any of those bits were on and it didn't seem to save the effect if they were.

 

Did some in-depth testing on this...looks like 0x29 is rather interesting: The first five bits are used to determine appearance...somehow. I'm not entirely sure how this works in full yet. The remaining three bits, however, are used for animation.

 

So E/6000-E/67FF is completely valid, giving you 2048 animation slots to work with (not 4096 like I initially presumed).

 

The bits for 0x29 work as follows:

bit 0 - True color yes/no

bit 1 - Unknown

bit 2 - Unknown

bit 3 - Unknown

bit 4 - Unknown

bit 5 - Transparency. Behaves the same as 0x2E0 bit 1.

 

So Displacer had a very good point and thus the mystery is solved!

Something about the transparency effect here though...it seems slightly different than the regular effect? From what I can tell it's targetting dark colors in the palette, while leaving brighter ones untouched (case in point, Deionarra vs setting it on a Black Abashai).

 

To note, bits 2 and 3 seem to always be on. From what I can tell these, along with bit 4, might be determinates for the EXE to tell if it's looking at a PST animation or a BG1 anim (since BG1's animation set data is still residing withing the game...)

Link to comment

Once I have the entire structure in memory figured out, I can just scan the entire exe for the pointer to the struct and be able to see everything that pertains to the creature. Going to take a bit though, like I said the struct is over 0x5000 bytes in memory.

 

You can see the struct I'm building here, but keep in mind it will be changing as I find more info out. The position in the cre file is on the right, and its place in the memory struct is on the left.

Link to comment

Since we're on a roll here, the game's unused classes still work...somewhat. Their strings are dummied but they can be assigned to characters all the same. The downside is that none of the skills associated with them work: Bards can't seem to use spells though they can access a spellbook page, Rangers lack tracking and so forth.

 

For anyone interested in working with this a little and because it does fit with the CRE items, here's where in the EXE the strrefs are stored (4CD).:

0x1865E4: Bard

0x1865EC: Priest

0x1865F8: Druid

0x186608: Paladin

0x186610: Ranger

0x186619: Fighter

0x186622: Thief

0x18662B: Mage

 

Guessing from the distance between it attributes might be handled between them as well...worth a shot for anyone more skilled with the debugger to take a closer look perhaps.

Link to comment

Looks like the unknowns at 0x2F2 are related to the color placement below it, at least the byte at 0x2F4. This byte is processed along with 0x2F5, 0x2F6 and 0x2F7 so I think this byte is another color placement entry, and the word above it at 0x2F2 might be another color (clownclr.ids) entry.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...