IWD1/2 Travel Trigger Field

[FredSRichardson]

Does anyone know what the (2) bytes starting at 0x08C in an ARE's Travel Trigger structure do? I have a crash occurring when transitioning, and odd things happened when I changed these numbers. I tried changing them to the ones used by another Travel Trigger in the area and the Travel Trigger wouldn't activate (maybe they need to be unique?). What I mean is that I would click on the doorway and the party wouldn't move. Very odd...

[FredSRichardson]

Woops, false alarm. I think those offsets do something, but the crash I had was silliness on my part. Sorry about that.

[Avenger]

Can you tell me what fields are around this '0x8c' field?

 

Apparently it is in an unknown section, the IESDP is a bit flawed there, as it labels 0x84-0x92 as a 8 bytes field (alternative use point).

 

Though 0x84-0x8c is 8 bytes already.

 

According to my own notes, 0x8c starts a 44 bytes unknown part which isn't used anywhere. PST uses the last (16 some) bytes of the structure.

But IWD1-2 doesn't use anything beyond 0x8c. (To my knowledge)

[devSin]

This is true for the Baldur's Gate series. The whole range occurs after the override point and is reserved (actually, I think the override point is also reserved space in BG, and the engine in BG2 doesn't pay attention to it unless it has to).

[FredSRichardson]

EDIT: Oops, after re-reading Avengers e-mail, I realized that I'm just repeating what he said about IESDP on this point.

 

Well, you guys are way over my head

 

IESDP looked a little flawed on this offset. It has:

 

0x0084	  8 (rect)	  Alternative use point
0x0092 	40 (bytes) 	Unknown

 

But 8 bytes after 0x0084 is not 0x0092. It should be 0x008C which is what I'm looking at.

 

I did a "profile" on the two bytes starting at 0x008C across all ARE's in both IWD1 and IWD2. Somehow the values look very intentional. Here's what I saw:

 

0x08C takes values from 0x00 to 0xFF. The values are pretty uniformly distributed across ARE's. In IWD2, 0xAA is used more often than any other, and in IWD1 0xAA is not used at all.

0x08D takes values from 0x00 to 0x0b. The distribution is not really uniform.

 

I'd have to verify this, but I think that the two values are always 0x00 for non-travel triggers. In almost all cases, when one is not 0x00, the other is not 0x00 as well.

 

I'm not sure if any of that helps. I'm afraid it's far beyond my ability to examine decompiled assembly which is probably the only real way to figure out what's going on.

 

I'm also not sure about my earlier test of flipping these bytes around. I had another problem at the time. I can try again and see what happens.

[devSin]

It could just be junk from memory (the reserved fields weren't usually initialized by the toolset). Baldur's Gate is famous for junk strings in these fields (file paths, assert or other conditions or string data, etc.), but you also get a fair bit of random sequences (0x00ff000000ff0000forevertilltheendoftime is common).

 

The override point (only used by late-SoA and ToB areas that I know of) is a DWORD 2D coord (WORD x and WORD y), not an 8 byte rect.

[igi]

Updated, thanks.