kits

[Avenger]

ToB is definitely a hacked up mess.

I want to know how it gets a kitlist row from a plain kit number.

I think it uses the rowname field of kitlist.2da but how does it get a rowname from a kit number?

I know that there is kit.ids, but this doesn't help, because bgmain doesn't use the kit symbols to match them in kitlist (i think, correct me if it does).

A test for this would be to change a label in kit.ids

Another test would be to swap rows in kitlist, if it indeed uses rowname, then the order would be irrelevant.

What i fear is that it is done in the usual hybrid hardcoded/softcoded way.

[the bigg]

kitlist.2da contains lines like WIZARD_SLAYER or TALOS, while kit.ids contains WIZARDSLAYER and TALOS, respectively, so I believe that they aren't associated on the basis of symbols.

 

If you're curious, I recently worked on hacking kits, and what I did was to ignore kit.ids and then use a manual if/then for deriving the kit.ids name from kitlist.2da. (I'd give you the code, but it's part tp2 and part OCaml, and it does kitlist.2da -> kit.ids anyway)

 

For deriving kit.ids -> kitlist.2da, I believe something like the following holds true:

if "kit.ids".numerical > 0x4000 // all but trueclass, barbarian, all mage kits
 "kitlist.2da".numerical = "kit.ids".numerical - 0x4000
 "kitlist.2da".symbol = getFromNumerical()
else if "kit.ids".numerical == 0x4000 // trueclass
 "kitlist.2da".numerical = null
 "kitlist.2da".symbol = "TRUECLASS"
else // barbarian and wild mage are 0x0000, while mage kits are of the form 0b0*10* and is < 0x4000
 "kitlist.2da".symbol = "kit.ids".symbol.removeString("MAGESCHOOL_")
 "kitlist.2da".numerical = getFromSymbol()

 

As an aside, why do you want to have GemRB follow all IE inconsistencies, rather than write things in a logical manner and then translate existing files when converting the games in GemRB format?

[Avenger]

Because i want gemrb to be compatible with all mods whenever possible.

This is the only reason.

 

DLTC already strains compatibility, because GemRB requires the game fonts in a .2da and dltc uses a font not in the original game.

 

I guess there are significantly more mods that use kits, so it would break all of them

[Avenger]

So far i came up with this:

 

alignmnt.2da rows are selected by the correct symbol.

I didn't have SORCERER or BARBARIAN rows, and when i added a SORCEROR row, it still didn't work.

I had to type it correctly.

 

Weapprof.2da columns are selected by the number in the PROFICIENCY column listed in kitlist.2da

 

I don't know how the correct symbol is calculated. I don't have sorcerer/sorceror in weapprof.2da neither in kitlist.2da

[the bigg]

Because i want gemrb to be compatible with all mods whenever possible.

This is the only reason.

 

DLTC already strains compatibility, because GemRB requires the game fonts in a .2da and dltc uses a font not in the original game.

 

I guess there are significantly more mods that use kits, so it would break all of them

In this case, WeiDU ADD_KIT adds the same symbol to kitlist.2da and kit.ids, and the number in kit.ids is 0x4000 + the number in kitlist.2da - which is compatible with my pseudo code.

 

 

I don't know how the correct symbol is calculated. I don't have sorcerer/sorceror in weapprof.2da neither in kitlist.2da

Sorceror is a class, not a kit, thus they aren't listed in kitlist - they are of trueclass kit. They share the item usability bit and the CLAB file with mages, so perhaps they share also weapprof.

[Avenger]

What about barbarian, iirc, it has a special kit value (not trueclass)

 

Also, i don't want to use kit.ids.

 

I know all true kits are 0x4000 + idx. But this doesn't help me finding their appropriate row in kitlist.2da. Unless idx is the row itself

 

Except mage schools (which are 0x40-0x8000) with 0x4000 the generalist and 0x8000 the wildmage. These would be matched by their usability flags (which are accessible from kitlist.2da)

 

Hmm, looking at our DLTC kitlist this seems to be the case, with crap lines stuffed in as filling.

 

[edit]

hmm, rereading your note, now i see that you actually said the same.

[the bigg]

According to bg2FixPack, both Barbarian and Wild Mage are 0x0000. For all kits (except mages & Barbarian) the first coloumn in kitlist.2da is their kit.ids value minus 0x4000.

[Avenger]

The game has a dword for the kit field, but apparently compares only the high word to the kit value.

 

For example:

0x00008000 is wildmage

0x00004000 is barbarian

 

I even managed to get some unusual values:

0x00002000 displayed as avenger (hehe)

0x00001000 displayed as shapeshifter

BUT!!!

0x40120000 is also avenger (and this is the correct one)

 

So, the game truly matches the unusability bits in case the value is not 0x4000+row

 

Is it true beast_friend and avenger are the same?

[Avenger]

Hmm, actually, all kits could be forced to display by setting the kit value to match the unusability field (swapping the two words).

 

Interesting...

 

Now i believe the game tries this:

It first looks for the unusability field for an exact match, if it doesn't find that, and

the kit is 0x4xxxzzzz, then it gets xxx and uses it as a row number in kitlist.

 

YESSS!

 

0x401f is barbarian! - at least it is displayed as barbarian

 

Of course, created characters will be set to 0x00008000.

But i think if you alter 0x00008000 to 0x401f0000 it will still be functional.

Sadly only the high word is detectable by Kit() trigger, but in GemRB i will swap the low word in, so it will work both ways.

Maybe i'll even make so that the two different modes of describing the same thing will be equivalent.

[Nythrun]

0x00008000 is wildmages, 0x00004000 is Barbarians

 

There's some odd funk with setting PC barbarians from 0x00004000 to 0x401f0000 (i.e. it doesn't work using AddKit(), you have to do some intermediate step) Wildmages are similarly screwy. When making PCs, neither kit will have anything other than 0 as the high word in the .cre's kit field regardless of what's in the .2da/.ids files.

 

FERALAN == ARCHER and

BEAST_FRIEND == AVENGER

 

I'm always surprised that the otherwise one-to-one correspondance between unusability flags and kits even allows adding new kits at all.