Random notes

[Taimon]

CHUI Window (officially named "Panel") +0x1a is a bitfield. Bit 1 should somehow disable it. (It is checked before the allocation.)

 

Does anybody know why proficiency stats have separate methods for manipulating Bits 0-2 and Bits 3-5?

[lynx]

A high bit is used to mark deactivated proficiencies for dual classing purposes. 0-2 is enough to hold the 5 available points.

[Echon]

An interesting read. It is good to see there are still busy bees researching this engine. Anyway, there seemed to be some confusion as to when spawn points respawn in BG:TotSC. Saving and loading are the causes, which tends to be quite annoying as they are never disabled like in BG2.

 

And while I may be the only one left, I am still interested in BG:TotSC research.

[Avenger]

An interesting read. It is good to see there are still busy bees researching this engine. Anyway, there seemed to be some confusion as to when spawn points respawn in BG:TotSC. Saving and loading are the causes, which tends to be quite annoying as they are never disabled like in BG2.

 

And while I may be the only one left, I am still interested in BG:TotSC research.

I'm interested too.

Even if i have a priority, eventually we find everything about ToB, BG1 will be the next to pick apart.

[Taimon]

I suppose this is already known, but just in case:

The game tries to load clabma0[1-9].2da on startup. Shouldn't require any additional kitlist.2da setup to get this working, getClassAbilitiesTable() is aware of the clabma* structures.

 

clabrn05/clabpa05 are for fallen rangers/paladins.

 

And something new:

Find Familiar is more versatile than one might think.

 

In the GAM file there is an additional section after the standard familiars.

+0x48 is a file offset to a resref table.

Starting at +0x4C is a 9 x 9 array of dwords. They "keys" are alignment x mage level and the value indicates how many resref to read for that combination. (from the resref table)

So the first value says how many familiars are in the "lawful good (level 1)" list, the second "lawful good (level 2)", the tenth "lawful neutral (level 1)" and so on.

 

When Find Familiar is invoked it first checks if there are any familiars in the relevant list. If so, it chooses one at random and removes it from the list. It will default to the standard familiars, if the list is empty.

 

Looks like something for the deathmatch mode.

[Avenger]

Now i know why the falling/regaining of xy-hood is handled like a kit change.

It is indeed a kit change with a predefined kit.

 

Of course this sucks greatly, because it disturbs the normal kits (if there are more than 4).

 

 

The familiar thing is an interesting stuff.

This opens the possibility of familiars with increasing abilities and some randomness.

I always missed that, and i was baffled by the large unused space in the .gam file.

Now i gotta improve dltcep with this new structure...

 

Does the AddFamiliar action anything to this list?

[Taimon]

Does the AddFamiliar action anything to this list?

Nothing at all.

AddFamiliar() only sets the allegiance and adds it to the familiar list. (Check my notes, should be in there somewhere. [around 0x39xx])

 

There is a separate list for every alignment/level combination, so you have 81 lists for this feature.

[Avenger]

Just noting: LeaderOf, Protagonist and Player1 are all the same.

 

I was not surprised by Protagonist, but LeaderOf is kinda strange.

[Avenger]

Just a note about damagetypes in item extended header.

 

IWD2 also has the damagetypes (6,7,8).

But IWD2 also has 9 - blunt missile. (used in sling bullets).

[Avenger]

A question, you mentioned 'remove after x seconds' for spawn headers.

Also you mentioned that spawn point don't respawn until their previous critters are killed.

So, this poses the question: how it marks creatures.

 

Maybe you already wrote this, but i couldn't find.

[Taimon]

A question, you mentioned 'remove after x seconds' for spawn headers.

Also you mentioned that spawn point don't respawn until their previous critters are killed.

So, this poses the question: how it marks creatures.

I'm not getting how the first part of your question is related to the second part.

 

Quoting the relevant information for the second part:

0x7a: bitfield

Bit 0: if Bit 2 is set, don't spawn

Bit 2: used internally, to disable the spawn point temporarily

It is set after a spawning, but the engine clears it in two situations:

(1) after the compressTime() method for the spawn point is called with a time amount of at least 16 hours (?)

(2) if Bit 0 is not set and there are no living spawns in the area

 

Every creature has a field that indicates whether it was spawned or not. (Check my notes. )

This is used to keep track of how many spawned creatures are in the current area. (The field in the area get's incremented/decremented when adding/removing spawned creatures to/from the area.)

[donny]

Forgot about that one - it was rather boring.

0xf4 is just what you guessed, only a bool to keep track of in-party-status for the time statistics.

0xf5/0xf6 are as far as I can tell unused.

0xf7 is an ASCII character related to the CRE name. '*' comes to mind here.

Also shares the same field in the CGameSprite class with the actor+0x2e byte.

[Nythrun]

YOUR BANED DONNY

[Taimon]

Door flags (+0x28) Bits 5 & 6 are unknown

Either unreferenced or copied but not used.

I hoped 5 really did have some purpose (they had to set it on purpose in the rare places it's used, at least), but 6 is 99% always set (the WED linkage nonsense from IESDP never made sense to me?), so I guess I'll just call that one Not copyable. ;-)

Coming back to this after quite some time.

Bit 5 is used in BG1 (at least TotSC). If set it prevents the random closing of doors in CGameDoor::CompressTime. (The random closing is only done when more than a hour of ingame time passed.)

[devSin]

Yeah, I end up using "Cannot close" and "Door located" (roughly from the Icewind Dale II door flags INI file; the lower bits all look the same); obviously, cannot (well, do not) close is found accurate (at least in one point in time), so I imagine the located (DETECTED) bit is the same too (just unused).

 

I actually found a place to toggle it too. Hopefully it works! :-)