Smoketest Posted December 8, 2004 Share Posted December 8, 2004 Here's an updated working version of KIT.IDS. I think Dyara figured most of it out, but all I care about is that it works. (Edit: removed dword values as they were tested to be nonfunctional.) The kit variable in a CRE file is a dword, but the Kit() trigger will only read the upper word of that value before comparing it to the value in KIT.IDS. The KIT.IDS that ships with the game is actually a copy of values from the UNUSABLE column of KITLIST.2DA. This makes KIT.IDS wrong for use with the Kit() trigger, though, because when you create characters in the game, they are assigned different kit values as shown below. My previous workaround for detecting barbarians won't work because wildmagi also end up being detected as 0x0000 by Kit(). My new idea involves testing for a kit of 0x0000 and then testing for a Fighter or Mage class to decide which kit is really is. To make this workaround work, you'll still have to modify Anomen, Imoen and Mazzy so they have a kit value of 0x40000000, give Haer'Dalis a kit value of 0x400D0000, and give Korgan a kit value of 0x40010000. They all currently have incorrect kit values, but this only affects their being detected with Kit(). It appears that any word value can be detected with Kit(), but the game will only generate the listed values when a new character is created. IDS 0x0000 BARBARIAN 0x0000 WILDMAGE 0x0040 MAGESCHOOL_ABJURER 0x0080 MAGESCHOOL_CONJURER 0x0100 MAGESCHOOL_DIVINER 0x0200 MAGESCHOOL_ENCHANTER 0x0400 MAGESCHOOL_ILLUSIONIST 0x0800 MAGESCHOOL_INVOKER 0x1000 MAGESCHOOL_NECROMANCER 0x2000 MAGESCHOOL_TRANSMUTER 0x4000 TRUE_CLASS 0x4001 BERSERKER 0x4002 WIZARDSLAYER 0x4003 KENSAI 0x4004 CAVALIER 0x4005 INQUISITOR 0x4006 UNDEADHUNTER 0x4007 FERALAN 0x4008 STALKER 0x4009 BEASTMASTER 0x400A ASSASIN 0x400B BOUNTYHUNTER 0x400C SWASHBUCKLER 0x400D BLADE 0x400E JESTER 0x400F SKALD 0x4010 TOTEMIC 0x4011 SHAPESHIFTER 0x4012 BEASTFRIEND 0x4013 GODTALOS 0x4014 GODHELM 0x4015 GODLATHANDER Link to comment
jester Posted December 8, 2004 Share Posted December 8, 2004 Is there any reason that they have the wrong kits for the game mechanics? Link to comment
CamDawg Posted December 8, 2004 Share Posted December 8, 2004 Idobek had posted this in the workroom, so I'll go ahead and make it public. Code to fix KIT.ids: COPY_EXISTING ~kit.ids~ ~override/kit.ids~ REPLACE_TEXTUALLY ~0x00004000~ ~0x4000~ // TRUECLASS REPLACE_TEXTUALLY ~0x00004000~ ~0x4000~ // MAGESCHOOL_GENERALIST REPLACE_TEXTUALLY ~0x00000040~ ~0x0040~ // MAGESCHOOL_ABJURER REPLACE_TEXTUALLY ~0x00000080~ ~0x0080~ // MAGESCHOOL_CONJURER REPLACE_TEXTUALLY ~0x00000100~ ~0x0100~ // MAGESCHOOL_DIVINER REPLACE_TEXTUALLY ~0x00000200~ ~0x0200~ // MAGESCHOOL_ENCHANTER REPLACE_TEXTUALLY ~0x00000400~ ~0x0400~ // MAGESCHOOL_ILLUSIONIST REPLACE_TEXTUALLY ~0x00000800~ ~0x0800~ // MAGESCHOOL_INVOKER REPLACE_TEXTUALLY ~0x00001000~ ~0x1000~ // MAGESCHOOL_NECROMANCER REPLACE_TEXTUALLY ~0x00002000~ ~0x2000~ // MAGESCHOOL_TRANSMUTER REPLACE_TEXTUALLY ~0x00000001~ ~0x4001~ // BERSERKER REPLACE_TEXTUALLY ~0x00000002~ ~0x4002~ // WIZARDSLAYER REPLACE_TEXTUALLY ~0x00000004~ ~0x4003~ // KENSAI REPLACE_TEXTUALLY ~0x00000008~ ~0x4004~ // CAVALIER REPLACE_TEXTUALLY ~0x00000010~ ~0x4005~ // INQUISITOR REPLACE_TEXTUALLY ~0x00000020~ ~0x4006~ // UNDEADHUNTER REPLACE_TEXTUALLY ~0x00008000~ ~0x4007~ // FERALAN REPLACE_TEXTUALLY ~0x00010000~ ~0x4008~ // STALKER REPLACE_TEXTUALLY ~0x00020000~ ~0x4009~ // BEASTMASTER REPLACE_TEXTUALLY ~0x00040000~ ~0x400A~ // ASSASIN REPLACE_TEXTUALLY ~0x00080000~ ~0x400B~ // BOUNTYHUNTER REPLACE_TEXTUALLY ~0x00100000~ ~0x400C~ // SWASHBUCKLER REPLACE_TEXTUALLY ~0x00200000~ ~0x400D~ // BLADE REPLACE_TEXTUALLY ~0x00400000~ ~0x400E~ // JESTER REPLACE_TEXTUALLY ~0x00800000~ ~0x400F~ // SKALD REPLACE_TEXTUALLY ~0x01000000~ ~0x4013~ // GODTALOS REPLACE_TEXTUALLY ~0x02000000~ ~0x4014~ // GODHELM REPLACE_TEXTUALLY ~0x04000000~ ~0x4015~ // GODLATHANDER REPLACE_TEXTUALLY ~0x08000000~ ~0x4010~ // TOTEMIC REPLACE_TEXTUALLY ~0x10000000~ ~0x4011~ // SHAPESHIFTER REPLACE_TEXTUALLY ~0x20000000~ ~0x4012~ // BEASTFRIEND Link to comment
Smoketest Posted December 8, 2004 Author Share Posted December 8, 2004 Is there any reason that they have the wrong kits for the game mechanics? I have a feeling that triggers to check kits weren't given high priority compared to the actual kits themselves. Otherwise KIT.IDS would have been up to date with current data when the game shipped. The fact that Kit() only uses half of the kit value is another indication, as well as the fact that Kit() is only used, to my knowledge, in the temple district for the cleric stronghold. Cam, that's a nice list, but it leaves off the barbarian. Link to comment
CamDawg Posted December 8, 2004 Share Posted December 8, 2004 True; Idobek wrote this some time agowhen that wasn't an issue. Combined with a REGEXP for creatures based on your new barbarian findings, we could add a line to the code and successfully identify barbarians with kit checks. Link to comment
Littiz Posted December 10, 2004 Share Posted December 10, 2004 The corrected KIT.IDS was indeed posted somewhere by Diara. Ehm, when I "weiDUed" it the first time for Refinements, I forgot the BARBARIAN line... Anyway, it was improved in the last version of Refinements (it handles even some different -and still wrong- versions of KIT.IDS), but there's still a bug in the current BARBARIAN line. The final patch will be in V2. Link to comment
SimDing0 Posted December 10, 2004 Share Posted December 10, 2004 So, hold on... what's the correct patching code for kit.ids? I'm using it as a fairly standard header for all my mods these days, to make sure things don't go wrong, and it's be rather a shame if I was patching it wrong. Link to comment
Smoketest Posted December 10, 2004 Author Share Posted December 10, 2004 So long as the user's KIT.IDS is unmodified by a prior mod, the WeiDU patcher Cam posted should work. The Kit() bug prevents barbarians and wildmagi from detecting properly unless you also patch certain CREs (for the workaround), so it's not critical to add that kit to the TP2 if your project doesn't care about detecting barbarians or wildmagi. I only made this post because IESDP has the old, incorrect version of KIT.IDS for reference. I'm aware that, by now, various people are using it in their work. Link to comment
igi Posted December 11, 2004 Share Posted December 11, 2004 The IESDP has the 'old, incorrect version' as, as you've gathered from this thread, there are about 18 different 'correct' versions laying around. I have them all archived somewhere, anso they can be added when someone tells me which one is right Link to comment
Smoketest Posted December 11, 2004 Author Share Posted December 11, 2004 I can't speak for the other 'versions', but I've tested this one in a game by creating characters of different kits/schools and then talking to a new NPC I made for the test. Her dialog consisted of "Hello!" followed by her telling you which kit/school she thought you were. She had a Kit() trigger that determined which state was next displayed. If no valid kits were detected, she would state that she didn't know what kit/school your character was. After failing to get the original dword values to detect properly (the words were reversed), I changed to the word values Dyara provided and things started working. Then I did some checking for the poor barbarian, who's the only character with a non-zero lower word in his kit value. Thankfully there's a workaround for him. Short answer: the info in this thread is the correct KIT.IDS. That is, it will work properly with the Kit() trigger, and these are the values the game itself generates when we create a new characters. The kit variable is a dword, so you could add 0x0000 to the ends of all the words, but Kit() will ignore them, just as it will ignore the 0x4000 in the lower word of the barbarian's kit variable. (I left it there to remind me his lower word is nonzero. Everyone else's lower word is zero.) Update: It turns out that Kit() and AddKit() will not work properly if dword values are listed in KIT.IDS. Technically, kit value 0x00000000 should not exist in BG2, as its character generator will always produce 0x40000000 for true classes. Eh, I hope that was clear enough. I'm sorta under the effects of medication right now. Link to comment
Avenger Posted December 12, 2004 Share Posted December 12, 2004 I just don't understand how 0x00004000 differs from 0x4000. Both should be 4096 decimal. If Kit() ignores the low word of the barbarian (0x00004000 == 0), then 0x00004001 will also be 0! Link to comment
Smoketest Posted December 12, 2004 Author Share Posted December 12, 2004 That's how you'd normally deal with hex values (and other bases), Avenger, but these values are 'hexfields' (like bitfields, but with hex digits instead of binary) in IDS files. A value like 0x00004000 tells the game this is a dword that has 0x0000 in the upper word and 0x4000 in the lower word. A value of 0x4001 says the high word is 0x4001. No low word is specified, but Kit() doesn't care. However, AddKit and AddSuperKit might (see edit note.) The reason word-sized values work in this particular IDS is because Kit() has a bug that only lets it work with words. In the CRE's kit variable, Kit() reads the upper word. I've updated my first post to show all values as dwords, since that's the size the kit variable is in CRE files. Kit() will ignore the extra 4 digits. (Update: no it won't.) I've also added the Wildmage kit that was previously missing, and a new workaround idea to deal with the fact that Barbarians and Wildmagi will both be detected by Kit() as 0x0000. (Yes, the Wildmage value is also correct. I created a wild mage and read the value from his exported CHR file.) I also discovered that the values in the original KIT.IDS were copied from the usability column of KITLIST.2DA. Edit: the actions AddKit() and AddSuperKit() might like having the full 32-bit values in KIT.IDS, so that's another good reason to leave them in dword format (8 digits). I haven't tested either action. The kit names don't quite match; BEASTFRIEND in KIT.IDS is BEAST_FRIEND in KITLIST.2DA, and the 2DA doesn't have MAGESCHOOL_ appended to the mage school kits. If those actions use the kit names to assign a kit value and the associated CLAB* file, the name differences might be a problem. Edit2: They don't like having 32-bit values. Stick to 16-bit values for Kit() and AddKit(), as per Sim's testing and my initial (updated) post. Link to comment
Littiz Posted December 18, 2004 Share Posted December 18, 2004 So long as the user's KIT.IDS is unmodified by a prior mod, the WeiDU patcher Cam posted should work. The Kit() bug prevents barbarians and wildmagi from detecting properly unless you also patch certain CREs (for the workaround), so it's not critical to add that kit to the TP2 if your project doesn't care about detecting barbarians or wildmagi. I only made this post because IESDP has the old, incorrect version of KIT.IDS for reference. I'm aware that, by now, various people are using it in their work. Oversight puts a wrong version of KIT.IDS (happens with a couple of components). Oversight is pretty popular, so we had to fix even that one in order for Refinements to work more widely. Problem is, if you just use the two "stacks" of REPLACE_TEXTUALLY commands one after the other, they'll just mess between themselves... So there's need to use some workarounds, and the fix becomes rather tricky. As I said, the current version of Refinements has already this fix, but it has also a typo with the Barbarian line (spotted by SimDingo, corrected for V2). Now, should someone find it useful, I would be happy if they will reuse it, but, this time, it would be nice if the modding_etiquette would also be followed. I've done my part from the start crediting Diara (99% of the merit still to her, of course). Link to comment
SimDing0 Posted December 18, 2004 Share Posted December 18, 2004 Smoketest, your revised version doesn't appear to work (I tried it, and Cam confirmed). It's pretty much right if you lop the last 4 digits off each value, including non-zero characters. The correct IDS is, by my findings: IDS 0x0000 SPECIAL_CLASS 0x0000 BARBARIAN 0x0000 WILDMAGE 0x0040 MAGESCHOOL_ABJURER 0x0080 MAGESCHOOL_CONJURER 0x0100 MAGESCHOOL_DIVINER 0x0200 MAGESCHOOL_ENCHANTER 0x0400 MAGESCHOOL_ILLUSIONIST 0x0800 MAGESCHOOL_INVOKER 0x1000 MAGESCHOOL_NECROMANCER 0x2000 MAGESCHOOL_TRANSMUTER 0x4000 TRUE_CLASS 0x4001 BERSERKER 0x4002 WIZARDSLAYER 0x4003 KENSAI 0x4004 CAVALIER 0x4005 INQUISITOR 0x4006 UNDEADHUNTER 0x4007 FERALAN 0x4008 STALKER 0x4009 BEASTMASTER 0x400A ASSASIN 0x400B BOUNTYHUNTER 0x400C SWASHBUCKLER 0x400D BLADE 0x400E JESTER 0x400F SKALD 0x4010 TOTEMIC 0x4011 SHAPESHIFTER 0x4012 BEASTFRIEND 0x4013 GODTALOS 0x4014 GODHELM 0x4015 GODLATHANDER Note the addition of SPECIAL_CLASS for clarity when compiling/decompiling. As you say, some NPC kit fields need to be adjusted to work with these. I've confirmed that they still receive kit abilities with the changes, so the use of usability values in these fields is redundant. The changes, one again, are: Anomen, Imoen, Mazzy: 00 00 00 40 Haer'Dalis: 00 00 0d 40 Korgan: 00 00 01 40 AddKit appears to work with the IDS values above. AddKit(0x1000) creates a Necromancer, for example. Note, however, that AddKit(0x0000) creates a pure-class mage instead of a wild mage. So does AddKit(0x4000), as expected. Incidentally, AddKit(0x00008000) doesn't work either, just for the sake of completeness. If anyone else cares to confirm these findings, that'd be good. It could turn out that I've cocked up somewhere. In any case, I'd propose the creation of some standard code which everybody uses, because it's getting silly lots of people having a different version. This'd involve a C_E_R to cover the NPC creatures, and REPLACE_TEXTUALLY on the IDS. For the IDS patching, I'd suggest using a regexp to overwrite whatever wacky values are there already, rather than assuming that everyone has the Bioware defaults. Link to comment
igi Posted December 18, 2004 Share Posted December 18, 2004 See? I told you everyone has their own 'correct' versions, didnt I? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.