7 replies to this topic

[CamDawg]

Along with NPCs, kits seem to be one of the more popular ideas that folks have for mods. The other day I realized that, despite rarely playing kitted characters, I've become involved with a lot of kit mods and kit-making is becoming more or less second nature. This is part one in a series that will hopefully cover kit creation, from A to Z.

Part One: Engine Limitations

I've seen a lot of ideas for kits across the forums I visit. Every so often, someone has taken a lot of care and thought and come up with a really great idea for a kit. My interest is piqued and I browse through the advantages/disadvantages and I see "Can not use [insert item]" or "Requires 17 Dexterity" and I get that sinking feeling. Unfortunately, the IE was never designed as a modder-friendly engine and we have to deal with many hardcoded limitations and engine quirks. As a result, seemingly innocuous requirements such as these can kill a kit by making it near-impossible to implement or balance. I'll try and cover the broadest limitations.

Item restrictions suck - One of the more common balancing techniques I see in kit proposals are "Can Not Use X" in a kit disadvantages section. Unfortunately item restrictions run into many, many problems.

Item files themselves only have 32 available usability "flags" that restrict them to a particular kit, and these are all used by the existing kits. This means there is no way to implement a unique set of restrictions for a new kit without restructuring usability for other kits.

Even re-using another kit's item usability flags can run into troubles. Using a fighter kit usability flag for a cleric kit could mean that your kit loses access to some cleric items. Some flags also have hardcoded features attached--for example, creating a thief kit that uses Bounty Hunter usability restrictions will also mean your kit will receive fewer thieving points at level-up, just like a Bounty Hunter.

High minimums are an advantage, not a disadvantage - This is another aspect of the engine that tends to surprise folks. In Pen and Paper, a kit with high requirements is difficult to attain since you need to actually roll dice and get the numbers. With the IE, the game will cheat on the rolls and always guarantee that you meet those requirements. A kit that requires 18 in every stat will mean you'll always roll straight 18s. If you're going to use stat minimums as a balancing aspect of your kit, keep this in mind.

Interface buttons are hardcoded - The buttons available to a character (turn undead, stealth, bard song, spellcasting, etc) are set by their class, not their kit. So if you wanted a paladin with a bard song, you can't do it--the bard song button is not available to paladins and there is no way to add it. On the flipside, though, disabling buttons are generally pretty easy--a cleric that can't turn undead or a ranger with no stealth are both pretty easy.

Spellbooks are available only to spellcasters - Any kit can use innate abilities. However, the spellbooks are tied directly to the spellcasting classes so there is no way to allow a thief kit to memorize spells and cast them using the spellbook interface. The spellbooks are also not interchangeable, meaning tht cleric kits can not access the mage spellbook and vice-versa.

Some classes can not be kitted - Sorcerers, monks, barbarians, and wild mages can not be kitted.

Only nine kits for a given class will be shown at character creation - When the player is creating their character, only nine kits can be displayed on the screen. Mages already have nine kits, so to create a mage kit that is selectable by the player you'll need to replace or disable one of the existing kits. This does not mean that you can not create a mage kit for an NPC; this is a restriction purely for PC-selectable kits.

Some of the above limitations have workarounds, but they are either non-intuitive for the player, introduce compatibility problems, are difficult to code, or a combination thereof.

Part Two will cover the files used by kits, what they do, and what you need to modify. For questions and commetns, please refer to the kit creation series discussion thread over at The Gibberlings Three and we will do our best to answer your questions.

Complete Series

• Part One: Limitations of the Engine
  
• Part Two: Game Files Involved
  
• Part Three: Installing with WeiDU
  
• Part Four: Additional WeiDU Functions

[Andyr]

Some classes can not be kitted - Sorcerers, barbarians, and wild mages can not be kitted.

Also monks.

[CamDawg]

I knew I forgot one. Updated.

[CamDawg]

As promised, part two of the ongoing BG2 kit creation series. This section is going to cover the various files involved with kit creation, what they do, and how to avoid common pitfalls. To view these files, use an editor such as Near Infinity, DLTCEP, or Infinity Explorer. Don't worry too much abot modifying these files--the next part of the tutorial will discuss how to use WeiDU to do this for you.

Game Files

2da files are text files that contain tables of data used to define rules and parameters for the game. Kits rely on data specificaly in many of these tables:

KITLIST.2da - The master list of kits in the game. The kits are referred to by their "internal name" in the first column. Most should be easy to recognize save the FERALAN--this was a ranger kit that was cut and replaced by the archer ranger kit. It's internal name was never changed though. The LOWER, MIXED, and HELP columns contain the string references from dialog.tlk that provide the name and description of the kit that you see in the game. [Dialog.tlk is a collection of every line of text in the game--be it dialogue, item descriptions, names, etc.--indexed by a number. Spells, items, creatures, etc. do not actually contain their description in the file itself, instead they carry a string reference (STRREF for short) that points to the correct entry in dialog.tlk.] The ABILITIES column points to a CLAB****.2da file that contains the abilities that are gained by the kit on leveling up. The PROFICIENCY column is unknown, save that every kit has a unique value. UNUSABLE is a hex value that matches the kit to the proper unusable flag in item files. Item files have a series of flags that determine which classes and kits can use them. One value not listed is 0x00004000, which will give the kit the exact same restrictions as its parent class, i.e. a fighter kit will use the same restrictions as a vanilla fighter. One other note of interest is that these values can be added (use a hexadecimal calulator if you're not familiar with hex numbers) to combine restrictions. If you want a kit that has the item restrictions of a Cavalier and a Shapeshifter (lord knows why!) you would add their respective unusable values: 0x00000008 + 0x10000000 = 0x10000008. The final column, CLASS, refers to the parent class of the kit--i.e. Assassins, Bounty Hunters, and Swashbucklers would have the value for thief in this column. Valid values are 1 (Mage), 2 (Fighter), 3 (Cleric), 4 (Thief), 5 (Bard), 6 (Paladin), 11 (Druid), and 12 (Ranger). The missing values are for the various multi-class and unkittable single-class characters.

ABCLASRQ.2da - This file controls the minimum stat scores or the various kits and classes. The first column lists the classes and kits and the other six correspond to the minimum allowed value in the six attributes: Strength, Dexterity, Constitution, Inteligence, Wisdom, and Charisma.

ABCLSMOD.2da - This file contains the modifiers to stat scores for the various classes and kits, i.e. bonus or penalty to strength. Of the default BG2 kits, only Beast Masters have an adustment to their stats.

ABDCDSRQ.2da - This file contains the minimum stat requirements to dual-class TO the kit/class in question. This is rather pointless for kits, as they can not be the second class of a dual-classed charater, but this file does need to be updated.

ABDCSCRQ.2da - This file contains the minimum stat requirements to dual-class FROM the kit/class in question. This is the 'must have 15 in prime requisite stats to dual-class' rule; allowed dual-classes are handled by another file.

ALIGNMNT.2da - This file controls allowed alignments for a kit. A "1" indicates that the alignment is allowed for the kit while "0" indicates a disalowed alignment.

CLABFI01.2da et al - This file controls what spells and bonuses are applied to te kit at level-up. Each kit and vanilla character class has a unique CLAB file, set by the KITLIST.2da file in the ABILITIES column. The columns correspond to the level at which the kit receives the ability and the rows list the abilities gained. Rows can be added indefinitely. There are three types of entries for the abilities: **** (nothing), AP_spellname (applied) or GA_spellname (gained). Spells that are applied are for permanent abilities such as a Wizard Slayer's inherent magic resistance or a barbarian's speed increase. Gained abilities are for once (or more) per day abilities, such as a Kensai's kai or snares for thieves. The CLAB file will probably be the most important file for creating your kit.

CLASWEAP.2da - This file controls the type of allowed weapons by general class. The kit names run down the first column and the various columns refer to the weapon types. An entry of "1" indicates the weapon type is usable and a "0" indicates unusable.

DUALCLAS.2da - This file controls the allowed dual-class possibilities for a kit. A "1" indicates a valid dual-class, while a "0" indicates the dual-class is not possible. Due to hard-coded limitations, kits of classes that can not dual-class (such as bard and paladin kits) will crash the game if dual-classed, regardless of the settings in this file.

K_C_H.2da et al - These files controls what kits are available to the player on character creation. The secod and third entry correspond to the class and race of the character--K_C_H determines what files are available to a cleric who is human. KITTABLE.2da has a full table that can help you in determining which K_*_*.2da file corresponds to which race and class. In the file itself is a column of descending numbers on the left and a column of numbers on the right that correspond to entries in KITLIST.2da. Please note that the K_*_* files do not override hardcoded limitations--listing a druid kit in K_D_E (druid kits for elves) will not allow elves to become druids, as there is a hardcoded race limitation to the druid class.

LUABBR.2da (ToB only) - This file is an index that matches kits to a table of High Level Abilities (HLAs). The left column lists the kits and classes and the right column corresponds to the HLA index. The index name must be 3 charactes in length; the file for the HLA table is always LUXXX.2da where XXX is the entry in this table.

LUFI0.2da et al (ToB only) - The LUXXX files contain a table of HLAs for a given kit or class. The spell files are listed in the ABILITIES column with the same style GA_ and AP_ prefixes from the CLAB file. The ICON and STRREF columns appear to be unusued, MIN_LEVEL is the first level where the ability becomes available to the player (note that the player must still gain 3 million XP before HLAs are available), MAX_LEVEL is presumably the level at which the ability is no longer offered, NUM_ALLOWED is the number of times the player can select a given HLA before it becomes unavailable, PREREQUISITE determines if another HLA is required before the current one can be selected (greater whirlwind has whirlwind as a prerequisite for example), EXCLUDED_BY is used to make HLAs mutually exclusive (think of Deva/Fallen Deva) and ALIGNMENT_RESTRICT determines if certain alignments can select an ability.

WEAPPROF.2da - This file determines the maximum number of stars that a kit or class can put in a specific weapon proficiency. Note that allowing a kit to place stars in a certain weapon will not grant them the ability to use the weapon--i.e. allowing a cleric kit a proficiency in spears--will not allow the kit to use them. The first column lists the weapons and the various columns match the clases and kits in the game. The CLUB proficiency in spells and items is also referred to as EXTRA1. The other EXTRA proficiencies do not have any function in game.

Keep in mind that any spells that are going to be gained or applied also need to be created and added. How to create spells is beyond the scope of this tutorial; there are many tutorials and tools that cover spell creation. It is a fairly long set of files to modify and not easily digested at first glance. However, the next tutorial will show how WeiDU's ADD_KIT command will do all the work for you.

For questions and commetns, please refer to the kit creation series discussion thread over at The Gibberlings Three and we will do our best to answer your questions.

Complete Series

• Part One: Limitations of the Engine
  
• Part Two: Game Files Involved
  
• Part Three: Installing with WeiDU
  
• Part Four: Additional WeiDU Functions

[CamDawg]

First, I've received PMs and a few emails asking me to hurry up and finish the next part of the tutorial. Thanks all, for your interest, and apologies all, for the delay.

Today's topic will cover using WeiDU as a distribution and installation tool. For those of you who do not know how to use WeiDU or are building your first mod, I've also included a section with a basic WeiDU mod set-up. For those of you already familiar in the ways of tp2, you can skip down to the next section.

Creating a WeiDU Mod ? The Basics

A WeiDU mod is essentially the WeiDU program itself, a list of instructions that tells the WeiDU program what to do (the tp2 file, discussed more below) and the files required for your mod--such as items, spells, etc. Your first step is to grab the actual WeiDU program at weidu.org; the current version is v155. Find the weidu.exe program and rename it to Setup-MyMod.exe. Throughout this tutorial, I will use MyMod; however when creating your mod replace MyMod with the name of your mod.

As an aside, the examples included with WeiDU itself, as well as the documentation, are a source of tutorials in and of themselves.

The next step is to create a folder named MyMod that will hold, among other items, the backup folder and other files for your mod. Inside the MyMod folder, create another folder named backup. When a WeiDU mod is installed, any files that are changed or altered are stored in the backup folder for uninstallation purposes. You?ll also want to add a single text file or something inside your backup folder. (If you compress your mod into ZIP or RAR format, some programs will ignore empty folders when decompressing it. This can lead to a missing backup folder, which, in turn, will cause installation of your mod to fail. We add a meaningless file to the folder to make it non-empty.)

Finally, we create the tp2 file. The tp2 file is a text file that tells WeiDU how to install and uninstall your mod. A tp2 file esentially contains a header--containing information such as the author, language options, etc.--and a section for every mod component. So create a text file named Setup-MyMod.tp2 and place it inside the MyMod folder. (Please note that placing the tp2 file inside the folder is only supported by WeiDU v155 or later.) You can use any text editor for working with the tp2 file, though I would recommend ConTEXT, a free text editor, along with the three syntax highlighters available for it: Idobek's tp2 highlighter, dialogue file highlighter, and Blucher's BAF syntax highlighter.

Once created, open your tp2 in your editor of choice. Throughout the syntax, you'll see comments from me. In the tp2 file anything between a /* and the closing */ is a comment and ignored by WeiDU. Another form of comment is // which tells WeiDU to ignore everything from // to the end of the line. To start with, we need to create the header. So add this to your tp2:

BACKUP ~MyMod/backup~ // so WeiDU can uninstall
AUTHOR ~myemail@mydomain.com~ // contact address displayed if installation fails

These are the bare minimum required for a mod. There are additional commands you can add to the header; I refer the reader to the WeiDU documentations for a full list. After the header, you'll need to add commands for each component of your mod.

BEGIN ~Tutorial Kit~ // name of this component

You can have as many BEGINs as you like; each BEGIN is a new component for your mod. When we discuss using the ADD_KIT command, below, you'll need to add it after BEGIN.

Finally, on to the ADD_KIT command
ADD_KIT is a powerful command for WeiDU that will modify almost all files necessary to create a kit. Probably the best way is to first post code in full, then we'll go back over it line-by-line. This is the Silverstar of Selûne kit from Cleric Remix, which we will use as an example.

// internal name of the kit
ADD_KIT ~C!Selune~

  // appended to CLASWEAP.2da
  ~C!Selune                0           0           1           1           0           1           0           0~

  // appended column-wise to WEAPPROF.2da
  ~C!Selune 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
     
  // appended to ABCLASRQ.2da
  ~C!Selune                0       0       0       0       9       0~

  // appended to ABCLSMOD.2da
  ~C!Selune                0       0       0       0       0       0~

  // appended to ABDCDSRQ.2da
  ~C!Selune                0       0       0       0       17      0~

  // appended to ABDCSCRQ.2da
  ~C!Selune                0       0       0       0       15      0~

  // appended to ALIGNMNT.2da
  ~C!Selune                0       0       0       1       0       0       1       1       0~

  // appended to DUALCLAS.2da
  ~C!Selune                1       0       1       1       0       1~

  // path to your CLAB-style 2da file 
  ~Cleric_Remix/Selune/C!Selune.2da~

  // PC races and classes allowed to use this kit, from KITTABLE.2da
  ~K_C_D K_C_E K_C_G K_C_H K_C_HE K_C_HL K_C_HO~

  // usability flags, added to the end of the KITLIST.2da entry
  ~0x00004000     3~

  // HLA table to use; see LUABBR.2da
  ~C!3~

  // list of starting equipment for PCs starting in ToB. Appended column-wise to 25STWEAP.2da
  ~CHAN09 * HELM07 BAG20 RING06 RING31 * BOOT01 AMUL19 BRAC16 BELT06 AROW11,40 BULL03,40 BOLT06,40 POTN52,5 POTN4,2 POTN14,5 HAM07 SW1H27 STAF08~

  // Lower, mixed, and help kit names and descriptions, added to KITLIST.2da 
  SAY ~Silverstar of Selûne~
  SAY ~Silverstar of Selûne~
  SAY ~SILVERSTAR OF SELÛNE: Description cut due to length~

OK, so now line by line. You'll notice that with most of these I've removed the comments.

ADD_KIT ~C!Selune~

C!Selune, in this example, is the internal name of the kit as it will be referred to in the game files. The internal name you specify here will need to be consistent throughout the rest of the ADD_KIT command.

 // appended to CLASWEAP.2da
  ~C!Selune                0           0           1           1           0           1           0           0~
  // appended column-wise to WEAPPROF.2da
  ~C!Selune 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
  // appended to ABCLASRQ.2da
  ~C!Selune                0       0       0       0       9       0~
  // appended to ABCLSMOD.2da
  ~C!Selune                0       0       0       0       0       0~
  // appended to ABDCDSRQ.2da
  ~C!Selune                0       0       0       0       17      0~
  // appended to ABDCSCRQ.2da
  ~C!Selune                0       0       0       0       15      0~
  // appended to ALIGNMNT.2da
  ~C!Selune                0       0       0       1       0       0       1       1       0~
  // appended to DUALCLAS.2da
  ~C!Selune                1       0       1       1       0       1~

Appends data to the various 2da files. For a refresher on the various 2das, see part two of the tutorial. The spacing between entries is actually unimportant, as it can be one space or several. However, for convenience, I have spaced out the entries here so that they will line up with the columns in a default installation. Data that is appended column-wise is added in a column, rather than a row.

 ~Cleric_Remix/Selune/C!Selune.2da~

This is the path to your CLAB-style 2da file for the kit. If you were to use MYKIT.2da and put it inside the MyMod folder, than this line would be ~MyMod/MYKIT.2da~ instead. The filename can not exceed eight characters.

 ~K_C_D K_C_E K_C_G K_C_H K_C_HE K_C_HL K_C_HO~

This line determines what combinations of class and race to make the kit available for a player character, as found in KITTABLE.2da. If you want the kit to not be available to the characters created by the player, then use ~~ instead. Creating non-player kits can be useful if you want to give an NPC or a monster a powerful or unique kit, but don't want the player to have access to it. It can also be used for special modifications to an existing kit for an NPC. Chloe, for example, uses a Kensai kit that is not available to the PC that disallows dual-classing.

 ~0x00004000     3~

The usability flags for KITLIST.2da. I have again spaced these to match the columns, though this is not strictly necessary. Refer back to part two for more information on the usability flags.

 ~C!3~

Determines which HLA table to use for the kit. (If the kit is installed on an SoA-only game, the lines delaing with ToB are ignored.) If you use a custom table, you'll need to copy it over separately (covered below).

 ~CHAN09 * HELM07 BAG20 RING06 RING31 * BOOT01 AMUL19 BRAC16 BELT06 AROW11,40 BULL03,40 BOLT06,40 POTN52,5 POTN4,2 POTN14,5 HAM07 SW1H27 STAF08~

A list of starting equipment for a PC using this kit in ToB, appended column-wise to 25STWEAP.2da. If you don't want a kit to have a piece of equipment in a particular slot, you can use a * instead. This line is also ignored on a ToB-only installation.

 SAY ~Silverstar of Selûne~
  SAY ~Silverstar of Selûne~
  SAY ~SILVERSTAR OF SELÛNE: Description cut due to length~

And finally, the name and description of your kit. These correspond to the lower, mixed, and help descriptions of your kit in KITLIST.2da. While many mods treat the mixed and lower strngs differently, I have yet to see a difference and usually use the same string for them. The third SAY, with its longer description, can run over more than one line.

So if we were to combine these, and exclude the comments. it would look like:

ADD_KIT ~C!Selune~
  ~C!Selune                0           0           1           1           0           1           0           0~
  ~C!Selune 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
  ~C!Selune                0       0       0       0       9       0~
  ~C!Selune                0       0       0       0       0       0~
  ~C!Selune                0       0       0       0       17      0~
  ~C!Selune                0       0       0       0       15      0~
  ~C!Selune                0       0       0       1       0       0       1       1       0~
  ~C!Selune                1       0       1       1       0       1~
  ~Cleric_Remix/Selune/C!Selune.2da~
  ~K_C_D K_C_E K_C_G K_C_H K_C_HE K_C_HL K_C_HO~
  ~0x00004000     3~
  ~C!3~
  ~CHAN09 * HELM07 BAG20 RING06 RING31 * BOOT01 AMUL19 BRAC16 BELT06 AROW11,40 BULL03,40 BOLT06,40 POTN52,5 POTN4,2 POTN14,5 HAM07 SW1H27 STAF08~
  SAY ~Silverstar of Selûne~
  SAY ~Silverstar of Selûne~
  SAY ~SILVERSTAR OF SELÛNE: Description cut due to length~

Cool, but what about all the spells, items, and other fun stuff I need for the mod?
Adding spells, items, and other nifty WeiDU commands pertaining to kits will be covered in the fourth and final installment.

For questions and commetns, please refer to the kit creation series discussion thread over at The Gibberlings Three and we will do our best to answer your questions.

Complete Series

• Part One: Limitations of the Engine
  
• Part Two: Game Files Involved
  
• Part Three: Installing with WeiDU
  
• Part Four: Additional WeiDU Functions

[CamDawg]

My original post of Part IV was lost in the sands of the move from FW, so here's a repost for y'all.

____________________
OK, so far we've covered what's generally possible in kit creation, the files involved, and creating a basic WeiDU installer and the ADD_KIT command. However, there's still a lot more that needs to be done to install your kit. What about adding spells and items? Interacting with other mods? Assigning a kit to a creature? That's what we're going to cover in this fourth and final installment. I'm going to cover some basic commands and flags/options; I refer the reader to the WeiDU readme for additional WeiDU tricks, commands, and options.

Basic file transfers: the COPY command
COPY is one of the most basic commands to transfer files. Syntax, and likely options you will need, is:

COPY ~MyMod/MySpell.spl~ ~override~
  SAY NAME1 ~General Name~ // unidentified name for items OR spell name
  SAY NAME2 ~Identified Name~ // identified name for items; not used for spells
  SAY UNIDENTIFIED_DESC ~Unidentified Description~ // unidentified description for items, spell description for spells
  SAY DESC ~Identified Description~ // identified description for items, unused for spells

The COPY command takes your file and moves it, in this example, to the override folder, making it accessible to the game. The SAY commands are optional; they set the strings in dialog.tlk for your item or spell. When creating your items or spells for the kit, don't bother adding the strings to dialog.tlk--WeiDU does it automatically and in an uninstallable fashion. The four SAY commands are all optional, so include the SAYs that you need. COPY can also be used for multiple files, either by copying a directory (in his example, the folder named bams inside the MyMod folder)

COPY ~MyMod/bams~ ~override~

or by specifying more than one file with COPY

COPY ~MyMod/bam1.bam~ ~override~
      ~MyMod/bam2.bam~ ~override~
      ~MyMod/eff1.bam~ ~override~

SAY can be used in conjunction with a multiple file COPY; however the SAY will apply to every file copied with the function.

Using COPY and COPY_EXISTING to assign a kit to a creature
Assigning a kit to a creature is more difficult tha it seems. Creature files (.CRE) use the kit number from KITLIST.2da to determine their kit. However, depending if the player has more than one kit mod installed, the reference will change. So, you need assign the kit at the time of installation. If you're adding a new creature and want it to have the new kit, you could use

COPY ~Delainy/cre/C!DELA10.cre~ ~override/C!DELA10.cre~ // Level 10 Delainy
  SAY NAME1 ~Delainy~
  SAY NAME2 ~Delainy~
  WRITE_SHORT 0x244 0 // doesn't change
  WRITE_BYTE  0x246 ~%C!WWBARD%~ // the internal name of your kit, surrounded by %
  WRITE_BYTE  0x247 0x40 // doesn't change

This is code I use to assign the C!WWBARD kit to Delainy. If you want to assign a kit to an existing creature, for example assigning Viconia a Nightcloak of Shar kit, you can use COPY_EXISTING. COPY_EXISTING is similar to COPY, except that it searches for the file in game and makes the changes you specify to it. It can also take multiple souce and destination files, similar to COPY.

COPY_EXISTING ~Viconi6.cre~ ~override~
               ~Viconi8.cre~ ~override~
               ~Viconi9.cre~ ~override~
               ~Viconi11.cre~ ~override~
               ~Viconi13.cre~ ~override~
               ~Viconi16.cre~ ~override~ // ToB only, see below on ACTION_IF
  WRITE_SHORT 0x244 0 // doesn't change
  WRITE_BYTE  0x246 ~%A#SHAR%~ // the internal name of your kit, surrounded by %
  WRITE_BYTE  0x247 0x40 // doesn't change

Viconia has multiple CRE files depending on the level she spawns, so this code will patch all of them. However, this is bad code: if you use COPY_EXISTING and WeiDU can not find the file specified, installation will fail. In the example above, Viconi16.cre is a ToB-only file, so using this code on an SoA-only install will cause it to fail. The solution to that is our next command, ACTION_IF.

Conditional installations: using ACTION_IF for detection
ACTION_IF is a great way to make your mod compatible with other mods and to avoid problems with SoA-only installs. ACTION_IF is essentially a list of WeiDU commands that only occur if a certain condition is met. Syntax is as follows:

ACTION_IF FILE_EXISTS ~override/item.itm~ THEN BEGIN
  (WeiDU commands such as COPY if the condition is true)
  END
  ELSE BEGIN // the ELSE clause is entirely optional
  (WeiDU commands such as COPY if the condition is false)
  END

There are conditions other than FILE_EXISTS (again, check the WeiDU docs), but it's the most likely one you will need and so I'll focus on it. One use that is directly applicable to kit-making is to only copy over HLA spells if ToB is installed. In ths case, you could look for ~data/25dialog.bif~ as it is only present in ToB installations.

To fix the bad Viconia example from above, you use this instead (note that only the Viconi16.cre patch is conditional; all other files are always patched since they are not inside the ACTION_IF:

COPY_EXISTING ~Viconi6.cre~ ~override~
               ~Viconi8.cre~ ~override~
               ~Viconi9.cre~ ~override~
               ~Viconi11.cre~ ~override~
               ~Viconi13.cre~ ~override~ // Viconi16.cre has moved to the ACTION_IF, below
  WRITE_SHORT 0x244 0 // doesn't change
  WRITE_BYTE  0x246 ~%A#SHAR%~ // the internal name of your kit, surrounded by %
  WRITE_BYTE  0x247 0x40 // doesn't change

ACTION_IF FILE_EXISTS ~data/25dialog.bif~ THEN BEGIN
  COPY_EXISTING ~Viconi16.cre~ ~override~ // ToB only
    WRITE_SHORT 0x244 0 // doesn't change
    WRITE_BYTE  0x246 ~%A#SHAR%~ // the internal name of your kit, surrounded by %
    WRITE_BYTE  0x247 0x40 // doesn't change
  END

Any WeiDU command can be used inside an ACTION_IF, including ADD_KIT. Two popular mods that affect classes and kits in general are Ghreyfain's Ashes of Embers (universal weapons, aka CLERICS WITH SWORDS) and aVENGER's Rogue Rebalancing (thieves get 3 stars in dual-wielding). You can use ACTION_IF to detect if they're installed and modify the kit accordingly. For example, here's the same Silverstar of Selûne kit of Cleric Remix that we used in part three, as it appears in the tp2. I include a check for ~override/bola01.itm~, an item added by AoE.

ACTION_IF FILE_EXISTS ~override/bola01.itm~ THEN BEGIN // if Ashes of Embers is installed
    ADD_KIT ~C!Selune~
      ~C!Selune                1           1           1           1           1           1           1           1~ // no weapon restrictions
      ~C!Selune 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1~ // no weapon restrictions
      ~C!Selune                0       0       0       0       9       0~
      ~C!Selune                0       0       0       0       0       0~
      ~C!Selune                0       0       0       0       17      0~
      ~C!Selune                0       0       0       0       15      0~
      ~C!Selune                0       0       0       1       0       0       1       1       0~
      ~C!Selune                1       0       1       1       0       1~
      ~Cleric_Remix/Selune/C!Selune.2da~
      ~K_C_D K_C_E K_C_G K_C_H K_C_HE K_C_HL K_C_HO~
      ~0x00004000     3~
      ~C!3~
      ~CHAN09 * HELM07 BAG20 RING06 RING31 * BOOT01 AMUL19 BRAC16 BELT06 AROW11,40 BULL03,40 BOLT06,40 POTN52,5 POTN4,2 POTN14,5 HAM07 SW1H27 STAF08~
    SAY ~Silverstar of Selûne~
    SAY ~Silverstar of Selûne~
    SAY ~SILVERSTAR OF SELÛNE: Description cut due to length~
  END
  ELSE BEGIN // if Ashes of Embers is NOT installed
    ADD_KIT ~C!Selune~
      ~C!Selune                0           0           1           1           0           1           0           0~ // normal weapon restrictions
      ~C!Selune 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~ // normal weapon restrictions
      ~C!Selune                0       0       0       0       9       0~
      ~C!Selune                0       0       0       0       0       0~
      ~C!Selune                0       0       0       0       17      0~
      ~C!Selune                0       0       0       0       15      0~
      ~C!Selune                0       0       0       1       0       0       1       1       0~
      ~C!Selune                1       0       1       1       0       1~
      ~Cleric_Remix/Selune/C!Selune.2da~
      ~K_C_D K_C_E K_C_G K_C_H K_C_HE K_C_HL K_C_HO~
      ~0x00004000     3~
      ~C!3~
      ~CHAN09 * HELM07 BAG20 RING06 RING31 * BOOT01 AMUL19 BRAC16 BELT06 AROW11,40 BULL03,40 BOLT06,40 POTN52,5 POTN4,2 POTN14,5 HAM07 SW1H27 STAF08~
    SAY ~Silverstar of Selûne~
    SAY ~Silverstar of Selûne~
    SAY ~SILVERSTAR OF SELÛNE: Description cut due to length~
  END

If AoE is installed, you'll notice that the kit now allows proficiencies in all weapons, matching the changes made by AoE. If AoE is not present, then the kit has the typical proficiency set of a cleric. The same could be used for thief kits and Rogue Rebalancing--by checking for an item only added by Rogue Rebalancing, you could install a thief kit with one or three stars in dual-wielding, as appropriate.

Summary
Ive tried to cover the majority of Kit creation and installation with this tutorial series, but there will inevitably be areas I have missed or additional questions to be asked. As such, please refer to the kit creation series discussion thread here at The Gibberlings Three and we will do our best to answer your questions.

Complete Series

• Part One: Limitations of the Engine
  
• Part Two: Game Files Involved
  
• Part Three: Installing with WeiDU
  
• Part Four: Additional WeiDU Functions

[The Imp]

and how to do kit in BG2EE ? There are only bif files

Just like with the regular files for kits, you have got to have Infinity Engine tools to modify the .spl and .cre etc files for the kits.

Also looking at this code in a web browser, not in the raw format the link gives, and it will give all the extra Enhanced Edition info you need.