IWD1/IWD2: 2 CRE flags

[FredSRichardson]

Here are two byte flags I haven't seen documented anywhere as yet:

 

CRE V9.0 : 1 byte at 0x270 (0x00 => visible, 0x01 => hidden)

CRE V2.2 : 1 byte at 0x29C (0x00 => visible, 0x01 => hidden)

 

An example is Hrothgar in AR1000.ARE of IWD1. The "converted" Hrothgar had the problem of being visible until I added this flag to the IWD2 structure.

 

The next byte over causes the variable "<scriptname>_DEAD" to be set when the Actor dies.

 

CRE V9.0 : 1 byte at 0x271 (0x00 => "*_DEAD" not set, 0x01 => "*_DEAD" set)

CRE V2.2 : 1 byte at 0x29D (0x00 => "*_DEAD" not set, 0x01 => "*_DEAD" set)

 

An example is the wolf you're asked to kill in Easthaven by the Scrimshander. The variable is only set when the byte flag is set which triggers the "quest complete" dialog part.

 

I'm not sure if bg1/bg2 has anything like this.

[Guest Guest]

The visibility flag is strange. There is a similar flag in the actor header in the area structure.

Are these flags the 'default' values for the actor header, or they have effect in the embedded .cre too?

 

I can very well believe this is the case, but then, the actor header also carries your second flag.

[Avenger]

Previous note was from me

[FredSRichardson]

High Avenger,

 

I saw that DLTCEP has a visible flag for the actor field (it's not in IESDP or NearInfinity yet ). There's also the bit flag for setting the death variable. So I think maybe you're right, that the CRE can set default values for these things.

 

Is it possible that these are really bit-fields? I was wondering if the value in the "visible" field is really a bit-mask (it looks like it's almost always set to 0xFFFF).

 

-Fred

[devSin]

IIRC, the visibility value in ARE actor structures doesn't have anything to do with visibility (in BG, at least). I tried to use it do disable an actor for BG1UB, and it had absolutely no effect. There are other unknown fields in the actor header that have terrifying effects (including rendering creatures unable to see and marking creatures static somehow), so it could influence values set somewhere else in the header (and not the known bitfield).

 

You're referring to the two bytes before the other custom fields that are always 1 in IWD CREs, right (the four-byte unknown in NI that's always 00 01 01 00)? I wouldn't be surprised if this was a bitfield (either 4 char, 2-byte surrounded by chars, or the whole 4 bytes); I just pray that these are the only two bits defined! Try plugging in 2 and 3 and see if it has the same effect (if it doesn't work with 2 but does with 3, then I'd say flags, but if it works with both, praise Jesus - a boolean value!).

[Avenger]

DevSin: there is an 'extra' invisibility flag in iwd/iwd2, which could be set by HideCreature.

 

What FredRicharson discovered is that .cre files got a default for these settings. (At least i think so).

Since he filled in an unknown gap between the script fields/internals (which exist in iwd/iwd2). I think he is right.

I'm unsure, though if they are real byte values. Boolean values (yes/no data) are either on a full dword, or on short (projectile qualifiers), or in a single bit in a dword. This is the first case, they occupy a single byte.

[Avenger]

I don't have any other structure definition at hand, except this snippet from ielister:

 

	os.AddString(RESREFSIZE,"Override");
os.AddString(RESREFSIZE,"Class");
os.AddString(RESREFSIZE,"Race");
os.AddString(RESREFSIZE,"General");
os.AddString(RESREFSIZE,"Default");
if(iwd2 || iwd)
{
os.AddWord("UNKNOWN");
os.AddWord("UNKNOWN");
	for(i=0;i<5;i++)
	{
		sprintf(tmpstr,"Internal #%x",i);
		os.AddWord(tmpstr);
	}

 

Fred talks about that the area with the 2 unknown words.

[FredSRichardson]

I'll make sure I look at ielister then to compare fields in the future.

 

Regarding bit flags, I was wondering if the whole dword was a bit field with bits 1 and 8 being used for these two purposes (as opposed to 2 boolean byte fields on after the other). I'm not sure if that makes any sense though.

[FredSRichardson]

DevSin: there is an 'extra' invisibility flag in iwd/iwd2, which could be set by HideCreature.

 

What FredRicharson discovered is that .cre files got a default for these settings. (At least i think so).

Since he filled in an unknown gap between the script fields/internals (which exist in iwd/iwd2). I think he is right.

I'm unsure, though if they are real byte values. Boolean values (yes/no data) are either on a full dword, or on short (projectile qualifiers), or in a single bit in a dword. This is the first case, they occupy a single byte.

 

Just a quick follow up regarding the byte fields at offset 0x29c and 0x29d in IWD2 CRE's (I haven't tried this in IWD1): I changed these values to 0x01, 0x02, 0x03, 0x04 for an embedded CRE in a save file and all these values had the same effect. Therefore I'd say these are in fact 1-byte boolean fields (though this does seem odd that these are the only ones).

[devSin]

Do you know what the other field is for (in the sequence, most CREs are 00 01 01 00; from my understanding, this is defining the first two bytes 00 and 01, leaving the last 01 00)?

[FredSRichardson]

Do you know what the other field is for (in the sequence, most CREs are 00 01 01 00; from my understanding, this is defining the first two bytes 00 and 01, leaving the last 01 00)?

Oh right, you mean at offset 0x29e for IWD2 (and 0x272 in IWD1)? In IWD2 that's set to 0x01 for one CRE (20CARCWL.CRE) and it's zero'd out for all the others. In IWD1 roughly 2/3'rd of the CRE's have it set to 0x01 and the other 1/3'rd are zero'd out. The next byte over (0x29f for IWD2 and 0x273 in IWD1) is zero'd out in all cases.

 

So I'd like to figure out what the 0x29e (0x272) byte flag is for. I'll try playing around with it a bit.

 

edit: Okay, 0x29e/0x272 flags incrementing KILL_<name>_CNT (posted in a new thread here).

[igi]

Nice to fill in some more unknowns, thanks.