Ambients, animations

[devSin]

All BG2/ToB-only.

 

I couldn't confirm the ambient flags.

Flags

bit 0: Ambient sounds of current section

bit 1: Point sound, i.e. volume decreases away from central point

bit 2: (0) Local (uses radius) / (1) main (ignores radius)

bit 3: Area Sound, same volume throughout area.

Bit 0 text doesn't make sense. It just toggles the particular ambient list on/off. Even if on, the schedule determines when it actually plays.

Bit 1 is undetermined. I couldn't discern any difference with it enabled/disabled.

Bit 2 does what it says.

Bit 3 causes the engine to randomly choose sounds from the list. If enabled, the order is random; if disabled, the sounds are played sequentially.

Bit 4 is used, but I couldn't tell what it does.

 

Animation flags still confuse me.

bit 1: Show shadow (0) or not (1)

bit 7: Invisible in dark (1) or not (0)

Bit 1 controls whether RGB 0,0,0 is drawn or not (if the bit is set, black is transparent, otherwise it gets drawn).

Bit 7 doesn't appear to do anything?

 

The final used GAM 2.0 flag

Bitmask controlling sizing of the text panel. Only bits 1 and 2 are used:

bit 0: Party AI disabled

bit 1: Text window size*

bit 2: Text window size*

bit 3: Unknown

bit 4: Hide GUI

bit 5: Hide options panel

bit 6: Hide portraits panel

bit 7: Unknown

Bit 7 controls whether automap notes are shown (0) or hidden (1). Journal sort isn't saved (fuckers), nor does anything else appear to be.

 

You've left a big chunk of data out of GAM 2.0 NPC structs. After the 4x2 array of quick weapon slots, there's a 4x2 (word) array. This is a simple mask of what to show on the main screen button bar. If an item is in a slot and is usable, the value is 0, otherwise it's -1. The quick weapon mask will always be the maximum number of usable slots for the class (since these are always filled with SLOT_FIST if there's no weapon there). The same is true for the quick item slots (except it's 3x2). These will be -1 if an item isn't in the slot, or the item is "unusable" (if you use a single-use/day item, it gets set to -1, but it will get set to 0 just by "picking up" the item and setting it back into the slot, even though you can't use it until after resting). These are appearance only (you can't actually add slots by changing the values here or anything).

 

In EFF v2, the first point is the caster point, and the second point is the target point. For target self, these will be the same. The effect labeled DestroySelf() (actually the MoveBetweenAreas() effect) stores the destination point in the caster point field. The first word at 0xc8 appears to always be the caster level (maybe this is how chance to dispel works?).

 

The ARE pro trap table is bugged. The structure is always 28 bytes:

8 projectile resref
4 offset to EFFs
4 length EFFs
4 unknown
2 Xloc
2 Yloc
4 unknown

These don't get saved correctly here, so I don't know anything else about it.

[devSin]

ARE v1.0 (ToB) - For trigger flags

bit 0: Invisible trap
bit 1: Reset trap (for proximity triggers)
bit 2: Party Required flag (for travel triggers)
bit 3: Detectable
bit 4: Unknown 
bit 5: Unknown 
bit 6: NPC can trigger
bit 7: Unknown 
bit 8: Deactivated (for proximity triggers)
bit 9: NPC cant pass (for travel triggers)
bit 10: Alternative Point
bit 11: Used by door? 
bit 12: Unknown 
bit 13: Unknown 
bit 14: Unknown 
bit 15: Unknown

bit 10 seems to be used to force the clicker to walk to the point defined (currently labeled "Alternative point"). This appears to be the only way to get the target to walk to a non-travel trigger (conveniently, the only apparent way WalkedToTrigger() will be true).

 

The points don't appear to override anything (as was suggested), or be "alternative" (the coordinates should be valid, and must be used if you want TriggerWalkTo* to happen automatically). It works for info triggers (I never tested any other trigger types).

 

Does anybody know what exactly the "launch point" is used for (if anything)? I'm still completely clueless as to what it could possibly be used for.

 

*No, the TriggerWalkTo() script action doesn't appear to work.

[Avenger]

launch point is the origin of the spell effects when the active region (trap) casts any.

For example, arrows start from there.

 

Alternate point is called so, because it modifies travel trigger locations too and i think it also modifies active regions (you will walk there for disarm trap, for example).

[Avenger]

I thought chance to dispel uses the power field, but you could be right about the new field at 0xc8.

 

You can get the area projectile structure saved by the set trap opcode (see thieves set trap ability).

Probably some other projectiles are saved (i think there must be a flag somewhere!)

If this is true, maybe even timed projectiles are possible.

[devSin]

Power is the sole value used to determine spell level (for effects such as reflect spell by level or protection from spell level). It doesn't affect dispel (if you give each of an ability's effects different powers, they will still all be dispelled at the same time).

 

For the area projectiles, the engine simply does not correctly save the effect list length (it just writes garbage junk to every field except the resref and point). The projectiles persist across saves, but will do nothing when they're triggered. The effects are added; I've tried manually setting the correct length in a saved ARE, but the engine still ignored the effects list. Any trap projectile can be saved (skull trap, symbols/wards, and the snare projectiles).

 

I don't know if this is an issue specific to the Mac version of ToB, or if it's yet another ARE saving issue with the 26499 beta (which the Mac version is based on). Creatures spawned in through spawn points don't get saved, nor do map notes set from the "Set automap notes" opcodes. :-(

[devSin]

I may check the alternate point again, but the behavior was pretty forced, so I still think it's just used as a point to force the clicker to walk to.

 

Oh, and please save the journal sort direction in GemRB. :-)

[devSin]

Bit 0 text doesn't make sense. It just toggles the particular ambient list on/off. Even if on, the schedule determines when it actually plays.

Bit 1 is undetermined. I couldn't discern any difference with it enabled/disabled.

Bit 2 does what it says.

Bit 3 causes the engine to randomly choose sounds from the list. If enabled, the order is random; if disabled, the sounds are played sequentially.

Bit 4 is used, but I couldn't tell what it does.

Bit 1 appears to disable some sort of environmental effects applied to the sound(s)? If you travel to the Mithrest and note the standard ambient (typical tavern sounds); disabling bit 1, reloading, and traveling there again, the ambient suddenly has weird echo/reverb effects.

[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

[devSin]

I forgot a few things:

 

GAME v2.0 NPCs - 0x0002 2 (WORD) Party order

Contrary to the description, this field does not store the dead value. Valid numbers are 0-5 (specifying the party order, Player1Fill through Player6Fill), or 65536 (not in party).

 

The dead value is stored at 0x0 (character selection), where the valid values are 0 (not selected), 1 (selected), and 32768 (dead). If the character is dead, Player objects still work depending on the CHR struct order (for Player1, Player2, etc.), and the slot order (for Player2Fill, Player3Fill, etc.).

 

 

GAME v2.0 Party stats - 0x0008 4 (DWORD) Time absent from party (real seconds)

This field is actually time spent with party, but is only stored if the character is kicked out of the party.

 

Inexplicably, both this and the "time joined" value are stored in ticks (1/15th of 1 second). A character who was in the party for exactly 8 game hours would have a value of 36000 at 0x8 ((36000 / 15) / 300 = 8).

 

 

Additionally, the value at 0x6c (Favorite weapon count) seems to be a time equipped in combat counter for each of the favorite weapons (based on the values, I suspect also stored in ticks).

 

 

GAME v2.0 Journal entries - 0xd 1 byte Journal section

This value is a bit field. 0x3 will add the journal entry to both the quests (bit 0) and completed quests (bit 1) sections. The bits:

 

no bits - user note (0)

bit 0 - quest (1)

bit 1 - done quest (2)

bit 2 - journal info (4)

[devSin]

GAME v2.0 character stats - the first byte at offset 0x10 (listed 0xf in IESDP) seems to be used by the engine to tell if a character is in the party or not, used only to determine how to write and calculate time spent with party.

 

If the value here is 0, the engine believes a character is not in the party. When the character joins the party, the join time value at 0xc is stored.

 

If the value here is 1, the engine believes a character is in the party. When the character is kicked out of the party, the time spent value at 0x8 is stored.

 

If a character is not in the party, and you manually set the byte at 0x10 to 1, when the character joins, the join time value at 0xc will not be stored.

 

If a character is in the party, and you manually set the byte at 0x10 to 0, when the character is kicked out, the time spent value at 0x8 will not be stored. (Additionally, the game either doesn't calculate time spent in party, or more likely only uses the existing value at 0x8 for time spent; everyone I tested had this value at 0, so the game always displayed "0 hours" on the info screen for time spent with party, and I can't be sure if it isn't calculated or is read only from 0x8.)

 

When a character joins the party, the game automatically sets this value to 1. When a character is kicked out, the game automatically sets this value to 0. The check for in party may be !0, since other values will be preserved (although they don't appear to have any additional or different effect). The value is not updated any other time, so setting it to 0 on a party member will persist across multiple saves (if the character is kicked out, it will still be 0, and will only be set to 1 the next time they join).

 

The 2 following bytes (at 0x11) are undetermined. In all tests, the game simply zeroed these bytes in the next save.

 

The value at 0x13 is controlled by engine. Its purpose is unknown. Unlike similar (in value, if not function) fields in the actor headers, which have profound effects on the loaded characters, the byte at 0x13 never seems to do much of anything to GAM characters.

[Avenger]

Are you sure about this:

0x10 is a byte? so anything on 0x10, like 128 (0x80) would be the same effect, while anything on 0x11 has no effect?

This isn't nitpicking, i want to be fully compatible with gemrb

[devSin]

As far as I can tell. I even stuck 0xffffffff in the whole 4 byte range. It had no visible effect; after saving again, it was 0xff00002a, and the 0xff didn't seem to do anything different over 0x1.

 

It could be that they're writing a 2 byte field from a 1 byte number, but it's always only 1 byte, so I'm not sure why they'd bother.

 

I also think the last is also 1 byte, since 0x2a (42) is a very common value for character headers in GAM and ARE files (when saved; the 2 bytes before the animation reference field), but I guess it could be 0x2a00 (10752).

[devSin]

CRE v1.0 items table - Create item (days) uses the word at 0x8 to somehow determine the item "duration." Figuring the field out may take Avenger's skills; I haven't yet been able to determine how exactly the game calculates the time to destroy the item. Probably BG2 only (I don't think the opcode exists in BG; maybe it works in ID or ID2).

 

If you stick stuff in here for normal creatures, the items will eventually disappear. This plagues some of the duergars' items in the starting dungeon -- they have values here, and anybody who picks up all the bullets for Jaheira may have recognized that they eventually disappear (taking all in the stack with them). Demon special items are also common offenders in ToB.

[Avenger]

I'm not sure about this. I think create item creates a remove item opcode.

Try this:

Use create item days (1 day)

Give this item to another person

advance time/sleep etc

Item won't vanish.

 

Try again without giving the item away.

Item will vanish.

[devSin]

All the other create* opcodes do add the remove item effect.

 

This one does not. I will test, but as I stated, there are some duergar in the starting dungeon who have bullets with values at 0x8 (in the CRE files). When these items are acquired (the chars are killed and looted), the bullets retain this value; after a certain amount of time (a day or so), these bullets will disappear (from the party member who has them, and any that have been added to the stack since are also removed).