Mike1072

Yes, if you want to uninstall or re-install a mod in the middle of your mod load, all of the mods that were installed after it will need be uninstalled and re-installed. This is an important part of the way WeiDU works and is required for the way we design mods.

Feel free to post modding questions unrelated to kits in the Modding Q&A forum, where you'll likely receive better attention than here.

you got any idea what for spells.2da is?

Yep. The IESDP sums it up well - they have info on all the 2DA/IDS files, along with information on spell effects, file formats, scripting, and random other stuff.

while i'm on it with asking questions, is the limit of weapon slots hardcoded or also controlled in the 2da files? ( meaning, how a mage / cleric etc has only 2 slots, a fighter has 4 )

Hardcoded.

for the variables, I could just take a look at the npc after they just joined, keep a copy of that, and simply copy over the variables of that npc to the other one later, could i not? In some cases, I wouldn't miss the missing dialogue at all. ( who in their right mind would want to hear everything over and over )

That sounds like it'd work. You might be stuck with repeating dialogue regardless, since a lot of it is controlled in global variables (which would be reset when starting a new game) instead of ones local to the creatures.

the variables are all listed as "affect" or "global flags" ( probably later ) in shadowkeeper in the savegame/ cre file, aren't they?

They are effects, so they'll probably be listed under "affects". I haven't used Shadowkeeper in a while, I stick with NearInfinity for most everything now.

I found it easier to manually edit the few halberds etc that there were than getting into the whole patching thing.

There's nothing wrong with that, but if you're making systematic changes for a class/kit and run into unanticipated items from mods, things could look weird. (I'm not sure of what situations you're going to be using the kit in, whether it's for one targeted installation or if you might want to release it for more general use.)

Another question, what exactly controls if a character can be exportet or not? I plan to play through SoA + ToB again and kind of want to keep the NPC's as they are. ( Sure I could just write down their stats, exp, and stuff but that would take a LONG time for all of them. )

There's a flag on .cre files for 'export allowed' at offset 0x10. It sounds like you'll want to modify the .cre files stored within your savegame.

and then, if it's possible to import ( in a mp session ) npc's that usually join you in the run of the game, will they act as custom character or act as the NPC they are?

*shrug* Don't know what'll happen, never tried. It's possible some things might be wonky if it keeps their local variables (LoveTalk) - you may need to do some manual fixing after bringing them in to see if you need to deal with this or any script/dialogue changes.

Oh god, I found the problem. the tag "not useable by cleric/ etc" in each item. christ, this is going to be a LOT of work...

Yeah, this stuff is controlled in .itm files. You may want to look at some mods that patch usabilities for all items. I think the 'no helmets for druids' component from Item Revisions should be a fairly straightforward example:

INCLUDE ~item_rev/lib/macros.tpa~
INCLUDE ~item_rev/lib/description_updates.tpa~

COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~
 PATCH_IF (SOURCE_SIZE > 0x71) BEGIN
READ_SHORT 0x1c item_type
READ_BYTE  0x21 usability4
PATCH_IF (item_type == 0x07) BEGIN // headgear
  PATCH_IF ((usability4 BAND 0b00100000) == 0b00100000) BEGIN // if unusable by monks (ie. only helmets, not ioun stones)
	WRITE_BYTE 0x21 (usability4 BOR 0b01000000) // make unusable by druids
	// update description
	PATCH_IF (~%LANGUAGE%~ STRING_COMPARE_CASE ~english~ == 0) BEGIN // if english
	  SPRINT text_update ~druids_cant_wear_helmets_english~
	  LAUNCH_PATCH_MACRO ~update_item_descriptions~
	END
  END
END
 END
 BUT_ONLY_IF_IT_CHANGES

The description updates rely on regular expressions and are done in an external macro.

This one might actually sound pretty stupid, but I want to restrict the schools of magic more than they are. ( example, right now, only one school opposes another, I want to raise that to each school opposing three others. )

If you happened to know where I might find the necessary file ( I looked in the 2da files but either I just didn't see it or it wasn't there ) I'd appreciate the help.

These are controlled by the usability field. Aside from managing item restrictions, there are a few hidden things the usability field decides for kits, like arcane spell school restrictions, thief skill point allotment, and the Inquisitor's restriction from spellcasting.

You'll want to combine the usabilities of 3 different kits for each of your mage specialists. Take the usability of the kit opposed to one of the schools, and add it to the usabilities of the kits opposed to the other 2 schools.

For example, if you wanted to restrict the Diviner from casting invocation or necromancy in addition to their normal restriction from conjuration, you'd do the following:

• Find out which kits have opposing schools to invocation and necromancy: Enchanters and Illusionists.
  
• Get the usabilities of these kits from kitlist.2da: 0x00000200 and 0x00000400.
  
• Add the value of these usabilities to the Diviner's current usability value (0x00000100). These are hex numbers, indicated by the '0x' in front, and generally the easiest way to do operations on them is to use the Calculator program that comes with Windows. First make sure it is in scientific mode, then click the button in the top left called 'Hex' to change the number system to hexadecimal. Now you can copy the usability values you found earlier into here, and add them together. Make sure to leave out the '0x', though. If all goes well, adding 0x00000100 + 0x00000200 + 0x00000400 should give you 0x00000700. Note that it is possible that some of your combinations will produce a hex number that includes letters from A-F, so don't be worried if this happens.
  

You actually didn't answer my question regarding innate passive abilities.

I saw that a wizard slayer gets the 10% magic fail on hit ability each level but it's a AP not a GA, so I think, if you assign that kit to another class and it levels up, it WOULD gain that ability, wouldn't it?

The same with other innate passive permanent abilities, like resistences and other things.

Yes, if you give a multi-class character a kit like the Wizard Slayer, they will gain all AP_ and GA_ abilities per the character's level in the kit's parent class (Fighter).

Yeah, I'm not sure why a cleric/mage multi-class wouldn't be desirable for this, unless it's relating to casting-in-armor or not wanting to lag behind single classes in levels.

Well, thats not quite was I was looking for but thanks for the help anyway.

I thought I could try to give mage/cleric a kit, but apparently that's really hardcoded and inpossible.

Question, do innate abillites ( such as the wizard slayer's 10% kumulative spell-failure chance upon hit ) work with a multi-classed character if you add the Kit in SK? ( or for that matter, things like natural resistences to fire or acid and the alike. )

Multi-class characters (and sorcerers/monks/mages) can have one kit, there's just no way to make kits for them show up at character creation, so to add it you either have to mess around with an editor or mod something in-game that will apply the kit via a script.

converting spells would probably cause a lot of problems and it'd be a major pain in the ass to actually do it.

Well, the conversion process can be 95% automated, the time consuming part would be choosing which spells to convert and making a kit that learned these spells. If you counted how many free slots are available at each level (I think a maximum of 24 spells can be shown, don't quote me on that), then you'd be able to only add that many spells at that level. Alternately, if it was done as a mage kit, the player would have the option to erase spells they don't need from their spellbook.

Now, one player requested a Kit that makes it possible to have both arcane and divine magic. ( Basically, a Priest of a God that reigns over the arcane )

I thought he could as well just multi-class mage / cleric but he wanted it to be a single class character with a kit.

now the very question is, is it even possible to given a mage ( or cleric ) kit the ability to cast divine ( or arcane for cleric ) magic as a cleric ( or mage ) does.

Not in the normal sense, no - the mage/cleric and F/M/C multi-classes are the only way to give access to both spellbooks. You could do something like convert arcane or divine spells over to the other type, and make a kit that learns these spells, but you'd probably have to limit the number you give them because there's a fixed number of spell slots at each level. Another possibility is to convert specific spells into innate abilities usable a certain number of times per day.

okay. thanks for your time. one last issue. I got it all to install. my items and spells work fine. However when i slect my kit in the character creation menu it just makes the character a normal thief instead of the kit I set up for it.

No obvious errors other than it not actually applying the kit when selected.

Hmm, I forget what sort of things might cause this. If you post the contents of your .tp2, there's a chance someone might spot something.

one mroe question. I read the part about importing items using weidu but i'm a bit lost. I have SPL and ITM files made with various programs. but i don't know what format they need to be in or how to edit them so they install with weidu.

If you've made your own finished .itm/.spl files, you just need to tell WeiDU to copy them over to where the game can use them. Stick them somewhere in your mod folder, perhaps within itm/spl subfolders. Then in your .tp2 somewhere before or after you add your kit, do:

COPY ~mymodfolder/spl/spell01.spl~ ~override~
COPY ~mymodfolder/itm/item01.itm~ ~override~

If you wanted to give them unique names and descriptions, you'd do it like this instead:

COPY ~mymodfolder/spl/spell01.spl~ ~override~
 SAY NAME1 ~Your Spell's Name~
 SAY UNIDENTIFIED_DESC ~Your Spell's Description~

COPY ~mymodfolder/itm/item01.itm~ ~override~
 SAY NAME1 ~Your Item's Unidentified Name~
 SAY NAME2 ~Your Item's Identified Name~
 SAY UNIDENTIFIED_DESC ~Your Item's Unidentified Description~
 SAY DESC ~Your Item's Identified Description~

I was just wondering how I would go about finding the ability list for the kits already in the game so I can learn from them.

The default kits use files named clabXX##.2da for these - you can check which kit maps to which file in kitlist.2da. And while browsing through them, you might also find this page useful.

Tried installing Murneth after a number of other mods (all compatible according to the "State of the Union" post on anorth G3 forum), got worried when I saw it going over all sorts of PIDs (mostly from BG1NPC Project, I guess); after about ten minutes of running through these files, I got this message:

 

ERROR: Cannot perform auto-update, exiting! Sys_error("Setup-Mur'Neth.exe: Too many open files")

 

So, can I uninstall this incomplete program, or are all of my other previous installs screwed (and now I have to start all over again from scratch)?

 

As a side note, the fact that this little NPC mod took longer than almost any other mod I've installed so far (including the degreenifier) just to get to the point where it quit on me, would seem to suggest to me that there's some mighty sloppy coding in there....

The mod did not get to the installing stage, therefore your installation has not been corrupted, nor have you experienced any sloppy coding on behalf of Mur'Neth's author. The PID looping you saw was an attempt to update the installer to the latest version of WeiDU, but it was unable to do so for whatever reason.

If you manually run setup-murn'eth.exe from your game directory it should be able to update okay in most cases and continue on to the installing stage, but if not, you can always replace setup-murn'eth.exe with a newer version of WeiDU renamed to setup-murn'eth.exe, so it won't need to update.

Get a newer version either from here or by copying the setup-modname.exe of another mod (the mod that appeared during your looping in place of Setup-blahblah.exe in the updating messages "Copying [setup-blahblah.exe] -> [setup-Mur'neth.exe]: false" will definitely be the newest version you have, but usually your other mods will have been updated to the newest version as well).

Hey, thanks a lot for the quick response. I really should read tutorials, but I was hoping for a step by step. I understand editing the CLAB file, but is there a reason I would have to duplicate the spell and rename it? Can I just add the assassin's spell to the swashbuckler at level 1 and get the desired effect?

Yeah, you can. If you're making a mod though, it's best to anticipate the worst. Perhaps some other crazy modder decided (or will decide upon reading this post) that they want to give assassins more abilities, and instead of making a new .spl for these abilities, they decide to just change spcl332. Then your leet swashbuckler might also end up with an unintentional permanent Improved Invisibility and 5 proficiency points in daggers.

Edit: For a step-by-step of the THAC0 thing...

Step 1: Make a .spl containing a permanent +1 THAC0 modifier.

Step 2: Make a .spl containing a permanent -1 THAC0 modifier.

Step 3: Add references to these spells to your kit's CLAB file at the appropriate levels to create your desired THAC0 progression.

How would I give the swashbuckler kit a backstab ability?

There's a spell effect that can increase the backstab modifier. I believe the assassin kit uses spcl332.spl for a +1 backstab bonus. If you're planning on making a mod, I'd recommend you make a duplicate of that spell, rename it (with your modder prefix) and stick it in your mod folder, and use the COPY command to copy it over, and add an AP_yourspellname entry to the swashbuckler CLAB file (clabth04.2da) at level one.

How do I change the THAC0 table a kit follows?

I'm not sure what Rogue Rebalancing does here. I think you can only affect this by giving them bonuses and penalties to their THAC0 as applied effects in their CLAB file - their base THAC0 will be their parent class's values from thac0.2da.

Warning: off-topic post starts now.

A while ago, I found a couple of typos and two things that might be bugs, but I haven't had the time/keep forgetting to go through all the files and locate the typos. Hopefully, I'll have to time to do so tomorrow.

To help me remember fishy things I notice in game, I try to take a screenshot whenever I see one. Then, when I get around to looking in the ScrnShot folder a few weeks later, there's a chance I'll see what prompted me to take the screenshot, evaluate whether it's a real problem, and then be able to attribute it to a mod or the vanilla game.

Those who can read .tp2 files can take the knowledge that this mod will be using custom area, script, creature, item, dialogue, etc. files and reasonably determine whether certain existing mods would work with it.

 

Unless you have an active passion to add lots of AI scripting tasks to your workload (in which case, fine) you might want to consider using either BG1 or BG2's core combat scripts. That saves you a lot of work (it also means SCS can latch onto them and be compatible out of the box, so I've got a vested interest).

Ah, yes. I was more referring to area scripts and override scripts and the like. I fully intend on not writing a bunch of combat scripts, so don't worry!

Now, as this is a TC, we shouldn't need any other mods but the EasyTutu, but are there some that won't be compatible with it in this list, if installed after the Shadow Hand TC, except the NPCs. Spell revision.

It really depends on the mod and how it is programmed (and not in a "good" versus "bad" way). Some of those mods (like NPCs and quests) will not be compatible simply because of what they're trying to do.

Those who can read .tp2 files can take the knowledge that this mod will be using custom area, script, creature, item, dialogue, etc. files and reasonably determine whether certain existing mods would work with it.

How will the map system work? I'm guessing only the areas that you've made changes to will be visitable (?) destinations.

Pretty much. The way we have things set up, we don't have to work very hard to 'add' areas. When we decide we are definitely not going to use an area, then we'll remove it.

Oh, and are you actually making any changes to the areas themselves, or are you just using them as they are, and editing dialogue (and such)?

The graphics and physical characteristics (doors, containers, etc.) are the only things I think are staying. The actors will all be brand new, though familiar faces may make an appearance.

In the course of about 30 seconds, you guys have brightened my day, and got me buzzing about a mod I had no idea was in development. Good luck to you both.

Thanks for the encouragement! That goes for everyone.

-will it have a separate install (actually this is more a request for a "separate install" option so we don't need to mess with our Easytutu installation )

Make a copy of your EasyTutu folder.

We intend for the mod be installed on an existing installation. Right now, EasyTutu with TotSC is mandatory. We could potentially just require a BG2 install, but this would mean including the area files in our download and running into both download size and copyright issues, so the Tutu requirement is likely to stay.

-is it restricted to BG1 areas or will there be any forays down to Amn etc?

We will probably be sticking to a subset of BG1 areas. Mostly because BG1 is awesome.

Going from the title (Shards of Ice / Summon Cow Incompatibility), I was hoping this was going to be a joke post.

What DavidW said, plus maybe this, too:

COPY_EXISTING ~xan.cre~  ~override~
		  ~xan4.cre~ ~override~
		  ~xan6.cre~ ~override~
 PATCH_IF (SOURCE_SIZE > 0x2d3) THEN BEGIN // protects against invalid files
WRITE_SHORT 0x246 16384 // change mage type to generalist mage

// fix spell memorisation info
READ_BYTE 0x234 level
READ_LONG 0x2a8 mem_info_off
READ_LONG 0x2ac num_mem_info
FOR (i = 0; i < num_mem_info; i += 1) BEGIN
  READ_SHORT (mem_info_off + 0x10*i) spell_level
  READ_SHORT (mem_info_off + 0x10*i + 0x06) spell_type
  PATCH_IF (level == 2) BEGIN // xan.cre
	PATCH_IF (spell_type == 1 && spell_level == 0) BEGIN // wizard, level 1 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 2
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 2
	END
  END ELSE
  PATCH_IF (level == 4) BEGIN // xan4.cre
	PATCH_IF (spell_type == 1 && spell_level == 0) BEGIN // wizard, level 1 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 3
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 3
	END ELSE
	PATCH_IF (spell_type == 1 && spell_level == 1) BEGIN // wizard, level 2 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 2
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 2
	END
  END ELSE
  PATCH_IF (level == 6) BEGIN // xan6.cre
	PATCH_IF (spell_type == 1 && spell_level == 0) BEGIN // wizard, level 1 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 4
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 4
	END ELSE
	PATCH_IF (spell_type == 1 && spell_level == 1) BEGIN // wizard, level 2 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 2
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 2
	END ELSE
	PATCH_IF (spell_type == 1 && spell_level == 2) BEGIN // wizard, level 3 spells
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x02) 2
	  WRITE_SHORT (mem_info_off + 0x10*i + 0x04) 2
	END
  END
END
 END
 BUT_ONLY_IF_IT_CHANGES

The only real difference is WRITE_BYTE -> WRITE_SHORT, and adjustments for the number of spells memorisable when he joins the party (it would auto-fix on level-up, but this will make sure he has the right number from when he joins to his first level-up).

(While I was doing this, I noticed that default XAN.CRE does not receive the +1 memorisable spells/level that he should - at level 2, he has 2 level 1 spells, instead of 3 level 1 spells, for being a specialist. It looks like Dudleyfix takes care of this.)

Thanks for the variable correction, jastey. Fixed.

 

Strange as it seems, I can't get that error to go away, even though "newtweaks/baf/Z!EmulAreaCheck.BAF" is properly pointed to. To make matters worse, I've another tweak I'm working on using this emulation, and it works with no trouble. I even copied the working code over with no effect. The only difference is the non-working is vanilla BG1, the working is with TotSC...

WeiDU's saying that it can't find the .baf file. Double-check that the files Z!EmulAreaCheck.BAF and Z!EmulAreaCheck1.BAF are named properly and in the right folder (this could be an issue with the tutorial - it doesn't include the prefixes when it describes the .baf files).

(6) The new coder will need of course to understand and modify pre-existing code (Nythrun's) more than create his/her own.

I'm afraid this is beyond most of us.