Ambients, animations

[igi]

I agree with devsin. This has been on my list of things to check for quite some time. I'm not sure how the value stored relates to the time the item is removed (it doesn't seem to be a time in second, or a game-time, or a delay), but fiddling it definately produces different times.

[devSin]

CHUI v1 controls, button - 0x16 is the cycle number, and 0x17 are the flags (IESDP currently has them swapped). The known bits:

no bits - center text (horizontal & vertical) (0)
bit 0 - justify text left (1)
bit 1 - justify text right (2)
bit 2 - justify text top (4)
bit 3 - justify text bottom (8)
bit 4 - anchor text (16)
bit 5 - reduce text size (32)

bits 6 and 7 didn't appear to do anything. bit 4 (anchor) anchors the button text at 0,0 (top-left), and all other bits then operate relative to the anchor position (so, left justify + anchor would have the text left aligned starting at 0,0). Just anchor will center the text at 0,0 (most or all of it will not be visible). bit 5 (shrink) just makes the button text smaller than normal.

 

I won't be looking at CHUs again, ever.

[Avenger]

Woo, this reduce text size thing is interesting.

I'll have to test it some.

Maybe this is the cause why GemRB looks slightly different in some cases

I just wonder how reducing happens, as these fonts are not true type fonts but fixed bitmaps.

Maybe the engine uses alternate bitmap? Or omits some rows/columns? Or does some bitmap shrinking?

Or it just turns all letters lowercase???

[devSin]

It looks like rudimentary scaling. I think it's used for the kit/racial enemy buttons; probably others during character creation.

 

The results aren't very appealing.

 

As for create item (days), items with values at 0x8 disappear, even if given to another character, and across multiple sessions (save, relaunch, reload). The items aren't actually removed, but are replaced with the "drained" item (referenced in the ITM header).

[Avenger]

Uh, i've never noticed this feature

I'll test and implement it then.

[devSin]

GAME v2.0 - After the game time (real seconds, which should be a DWORD), there are two DWORD values for some unknown purpose. The first is an offset (this will always be the file length) to some unknown structure type (strangely, this is stored big endian in Mac ToB?). The second is a count of the unknown structures (or something; non-zero values will fail assert(cnt == (DWORD)nGame)). In short, it should be:

 

0x74 , 4 (DWORD) , Game time (real seconds)

0x78 , 4 (DWORD) , Unknown

0x7c , 4 (DWORD) , Unknown

0x80 , 52 , Unknown/unused

<{POST_SNAPBACK}>

It looks like these may be the offset and length to another stored locations structure, this one used by the ExitPocketPlane() action (obviously, ToB only). I guess it's automatically set by the pocket plane opcode, but I won't do anything useful like actually test.

 

The locations seem to be 8 (resref) +2 (xpos) +2 (ypos) bytes long, with one for each member of the party when the pocket plane opcode was executed.

[Avenger]

Heh, i already knew this, and i swear i wrote about them

 

The following actions use these:

236 StorePartyLocations()

237 RestorePartyLocations()

 

Here is the old topic:

 

http://forums.gibberlings3.net/index.php?showtopic=3765

 

[edit]

 

Oh, you mean, ANOTHER stored locations. DUH. ok.

[devSin]

Yeah, this is an entirely separate structure. They just used 8 reserved bytes at the end of the GAM header for the offset+count.

 

The value at 0x7c is actually a count (not length); the Mac version stores these big endian (!!), so it took me a second to calculate 0x6000000 (100663296, what NI shows it as).

 

(GAME V2.0 & GAME V2.1)...

0x74 , 4 (DWORD) , Game time (real seconds)

0x78 , 4 (DWORD) , offset to PP stored locations (set by PP opcode)

0x7c , 4 (DWORD) , count of PP stored locations (set by PP opcode)

0x80 , 52 , Unknown/unused

 

Unlike normal stored locations, I doubt these are cleared when the ExitPocketPlane() action is used, but I guess they could be.

 

The locations structure appears identical:

 

0x0 (resref) stored area

0x8 (word) stored xpos

0xa (word) stored ypos

[devSin]

Thanks for moving this back to discussion.

 

BioWare usurped 16 bytes from the reserved section at the end of the ARE header in ToB.

 

AREA V1.0

0xd4, 8 (ResRef) , Rest movie (day)

0xdc, 8 (ResRef) , Rest movie (night)

0xe4, 38 (byte) , Unused/reserved

 

No mysteries. If the party can rest in an area, the normal rest movie (as determined by the area type flags) is overridden with the specified movie. If the party rests during daytime, the day movie plays, else the night movie plays. This happens if any or all of the following type flags are set (the ones that allow resting, obviously): outdoor, city, forest, dungeon, and can rest (actually, I made up city and forest; I don't know these actually allow resting without outdoor or dungeon).

 

I was hoping it was controlled by the rest flag, but it isn't (I would say to imagine using SetAreaRestFlag() to change rest movies based on events, but I don't think anybody can make a movie that would be worth it). I think I've seen this before (or I've previously discovered it and forgot about it). It isn't in the IESDP, so here it is.

 

@Avenger, GemRB

Unlike normal stored locations, I doubt these are cleared when the ExitPocketPlane() action is used, but I guess they could be.

The locations are cleared when the ExitPocketPlane() command is executed.

[Avenger]

The movie fields are new to me