Jump to content

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


Qwinn

Recommended Posts

Some of the bits listed as "Unknown" at offset 0x2e1 in IESDP's description of CRE 1.2 (PS:T only) correspond to whether this creature dying will affect certain globals such as your alignment, your Murder count, and your Lady count (meaning the counter that tracks whether you're pissing off the Lady of Pain enough to maze you). Here's what we have for the 8 bits at offset 0x2e1:

 

0x2e1 (Flag #2):

0: something to do with KAPUTZ type global and "Team"

1: invulnerability

2: toggles modifying GOOD global on death

3: toggles modifying LAW global on death

4: toggles modifying LADY global on death

5: toggles modifying MURDER global on death

6: unknown (unused in death function)

7: never used

 

 

Now, additionally, the IESDP CRE description says this:

 

0x02b8 32 (char array) Monstrous Compendium Entry

 

The 32 character array in question actually starts at 2bc, ending at 2db. This is correctly displayed in Near Infinity. The bytes 2b8-2bb are marked in Near Infinity as "Unknown".

 

Thanks to scient, we now know what they are for :)

 

If the bit to increment GOOD is set to true, increment global GOOD by the value of the signed byte at offset 0x2B8

If the bit to increment LAW is set to true, increment global LAW by the value of the signed byte at offset 0x2B9

If the bit to increment LADY is set to true, increment global LADY by the value of the signed byte at offset 0x2BA

If the bit to increment MURDER is set to true, increment global MURDER by the value of the signed byte at offset 0x2BB

 

 

So, if you want a creature's death to give an alignment/murder/lady hit, you first set the corresponding flags at 0x2e1, and then you tell it by how much to increment each of these at the 0x2b8-0x2bb offsets.

 

Qwinn

Link to comment
Actually, we're doing some additional investigation on what these and some other nearby fields do, so you might want to hold off on updating till we've got it all sorted.

 

Any word on further information?

Link to comment

Yea, the size of "Monstrous Compendium Entry" is wrong. There is a dword at 0x2D0 that seems to be flags. It is used with 0x28 (and possibly others). 0x28 has its high bit set depending on the setting of certain bits at 0x2D0. It also looks like there is a byte at 0x2CD, but I don't know how its used yet.

Link to comment
Hm, might be the part that says whether an animation set is clown-colored or not, I'll investigate this some. As for 0x2CD-2D0, I take it this is something only areas set within the creatures?

 

Not sure, I think the function is a post load processor for all cre files. It just happened that it was called from the area load function. It is called from other functions in the code other than the area loading function.

 

Remember the high bit at 0x28 is set or not depending on what is in 0x2D0, it looks like its checking bit 1 at 0x2D0 to decide on whether or not to set the high bit of 0x28.

Link to comment

Well what's strange is, looking through all the CRE files, it doesn't seem to be set in any of them. Possibly an unused function they considered but went with something else? (Also it's damn weird for them to have a bit array at 0x2D0 and then another at 0x2E0 o_O)

Link to comment

Here's the final on what I discussed in the first post.

 

PS:T CRE 0x2e0:

Bit 0 : unused in PST

Bit 1 : toggle transparency (used by Blackrose, Candrian, Deionarra)

Bit 2 : unused in PST

Bit 3 : unused in PST

Bit 4 : on death if TRUE, increment KAPUTZ variable "Script Name"_DEAD. Script Name set at CRE 0x324. *

Bit 5 : on death if TRUE, increment KAPUTZ variable KILL_"Character Type". Character type set at CRE 0x2bc. *

Bit 6 : on death if FALSE and bit 5 is TRUE, leaves out the KILL_ part of variable name and just writes to "Character Type". Never actually does anything in PS:T CRE Files: if Bit 5 true, bit 6 always is also. Some CREs have bit 6 on and bit 5 off. This does nothing.

Bit 7 : on death if TRUE, modify something to do with NPC KAPUTZ FACTION (doesn't actually work, wouldn't be useful if it did)

 

*Note that in vanilla PS:T these two bit settings (bits 4 and 5) do NOT work for creatures created by INI files, only for actors from ARE files or creatures created by scripts, which means INI creatures never set death variables upon being killed. There's no apparent reason for this beyond simple programmer error. This actually causes a number of dialogue triggers in PS:T to not work (such as checks to see if you'd ever killed githzerai before) Scient has fixed this for PS:T Fixpack version 4.0 going forward.

 

 

0x2e1

Bit 0 : on death if TRUE, modify something to do with NPC KAPUTZ TEAM (doesn't actually work, wouldn't be useful if it did)

Bit 1 : toggle invulnerability (Aelwyn, Nemelle, Coaxmetal, Pillar of Skulls)

Bit 2 : on death if TRUE, modify GLOBAL "GOOD" based on signed byte at offset 0x2B8 in CRE

Bit 3 : on death if TRUE, modify GLOBAL "LAW" based on signed byte at offset 0x2B9 in CRE

Bit 4 : on death if TRUE, modify GLOBAL "LADY" based on signed byte at offset 0x2BA in CRE

Bit 5 : on death if TRUE, modify GLOBAL "MURDER" based on signed byte at offset 0x2BB in CRE

Bit 6 : in dialogue if TRUE, do not turn CRE to face protagonist. (Examples: Giant Skeleton Guards, Sleeping Bariaur, Trias, Festhall Lecturers, etc.)

Bit 7 : if TRUE, this creature calls for help, and ALL nearby creatures go hostile. Can be set by "auto-buddy" in INI files, though it never is.

 

 

0x2e2:

All bits Unknown.

 

 

0x2e3:

Bit 6: Not set in CRE's, toggled on in save games if NPC is dead/killed -> prevents deaths globals being set twice for a NPC.

Other bits Unknown.

 

 

0x2b8 thru 0x2bb

If the bit to increment GOOD (0x2e1, bit 2) is set to true, increment global GOOD by the value of the signed byte at offset 0x2B8 when this CRE is killed

If the bit to increment LAW (0x2e1, bit 3) is set to true, increment global LAW by the value of the signed byte at offset 0x2B9 when this CRE is killed

If the bit to increment LADY (0x2e1, bit 4) is set to true, increment global LADY by the value of the signed byte at offset 0x2BA when this CRE is killed

If the bit to increment MURDER (0x2e1, bit 5) is set to true, increment global MURDER by the value of the signed byte at offset 0x2BB when this CRE is killed

 

 

Additional note: the scripted DestroySelf() action does not trigger incrementing any of these globals. The scripted Kill() action does.

 

 

Qwinn

Link to comment

My guess is the Kaputz variables are all related to KAPUTZ (KILL_)type-name where it increments them by 1 on death (meaning Faction and Team in this case, which apparently are both broken anyway).

 

As for 2D0...I tried modifying this (in fact I modified the whole 32 byte array to FF): no results.

Link to comment

Yes. In theory those two bits (0x2e0 bit 7 and 0x2e1 bit 0) should set KILL_FACTION and KILL_TEAM, but both are useless. In most cases, barring errors, the Character_Type for your average Dustman is "Dustman", and your average Sensate character type is "Sensate", so "Kill_Dustman" is already going to be incremented by bit 4 and the set would be redundant. And "Team" is completely fluid, changed continually by scripting as is necessary, so setting KILL variables for it is -really- useless.

 

Lots of the character types are set to silly values - for example, most Curst citizens have character type "Godsman". I already coded up fixing most of these to something less silly, but as the variables are very rarely used, it's rather valueless, beyond increasing the accuracy of variables that can really only be seen with a save game editor.

 

Scient and I did discuss combining my fixing those character_types with him adding a display in the Journal screen that would display the value of those variables in game. A "Kill" screen, basically, tracking how much of each type of critter you killed during the game. Other games have this, so why not? It would just be a tweak, obviously. Low priority over fixing the remaining bugs, of course.

 

Qwinn

Link to comment

That actually sounds like a cool idea. As for 2D0...I think there's a chance Displacer might be mistaken on the placement?

 

VAR's use a 32-byte string for their names, and currently where it is that's the exact number. There doesn't seem to be any changes done to this field either after a certain point in any of the CRE files (and if it were it'd throw off the KAPUTZ increments for sure). So maybe his offset is off? I'm not entirely sure.

 

Either way I worked the new information into the version of NI I've tossed you, Displacer and Igi. I'll get it uploaded in a sec at the same link as before.

Link to comment
That actually sounds like a cool idea. As for 2D0...I think there's a chance Displacer might be mistaken on the placement?

 

Let me double check the location, I'm working with the creature struct in memory which is over 0x5000 in length so its technically possible I may be off, but I don't think so. As to what the code is doing I assure you I'm correct, here's the relavant code (note this is the struct in memory which means the offsets are not the same as in the file):

 

text:00750C2E loc_750C2E:
.text:00750C2E                 mov     edx, [ebp+var_178] ; CRE memory struct
.text:00750C34                 mov     ax, [edx+510h]  ; Animation ID (0x28 in file)
.text:00750C3B                 mov     [ebp+var_24], ax
.text:00750C3F                 mov     ecx, [ebp+var_178] ; CRE memory struct
.text:00750C45                 mov     edx, [ecx+7C8h] ; = 0x2D0 in file
.text:00750C4B                 and     edx, 2
.text:00750C4E                 test    edx, edx
.text:00750C50                 jz      short loc_750C5D
.text:00750C52                 mov     ax, [ebp+var_24]
.text:00750C56                 or      ah, 8
.text:00750C59                 mov     [ebp+var_24], ax

Link to comment

Archived

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

×
×
  • Create New...