[BUG] PnP Proficiency for Dual-Classes Grants F/M 1 Extra Spell Per Level

[The_Baffled_King]

I'm playing IWD:EE. When my F/M becomes a level 4 Fighter, she gains one level 1 spell slot and one level 2 spell slot (Total: 3 L1; 2 L2) - obviously she shouldn't get spell slots for gaining Fighter levels! When she becomes a level 4 Mage, she gains a further level 1 spell slot and level 2 spell slot, as of course she should (Total: 4 L1; 3 L2). When she becomes a level 5 Mage, she gains a level 1 spell slot as per usual, but she gains two level 3 spell slots instead of just one (Total: 5 L1; 3 L2; 2 L3). At this point, she has one too many spell slots for every spell level.

It seemed that "Enforce PnP Proficiency Rules on Dual-Classed Characters" was the culprit, so I tested the component on an otherwise vanilla install. It is indeed the culprit. Upon becoming a level 3 Mage, the F/M's kit is changed from Base Class, AKA MAGESCHOOL_GENERALIST, to the mod-added kit D5FIGHT. I'm guessing that the game thinks my F/M is a Specialist Mage, and is awarding an additional spell slot per spell level? Anyway, I've fixed my game - this post is for informational purposes.

[jmerry]

Anything other than TRUECLASS/MAGESCHOOL_GENERALIST grants the bonus spell slot per level to mages and sorcerers, yes. Whether it's a valid kit or not. This applies to multiclass characters, though not to dual-classed characters unless mage is the "original" class.

Checking how this component works... create a new kit which is the same as a trueclass fighter except that it can't go beyond specialization in any weapon. And similarly for rangers. Repeat with clones of every fighter and ranger kit.

Create a new script for a summoned creature. If the summoner has one of the kits we cloned and is a fighter/X or ranger/cleric, assign the new clone kit to that summoner (Start with trueclass, iterate over kits adding to it). Create the creature to use it, and a spell to summon it. Add a spell to summon this creature to every level from 3 on for trueclass clerics, druids, mages, and thieves.

So, you dual from (trueclass) fighter to mage. You gain levels in your new class until your mage level is greater than your fighter level. That completes the dual, and you're a fighter/mage now. The spell fires, summoning an invisible creature which then changes your kit from the original TRUECLASS to the new clone D5FIGHT. Everything's good, working as intended. No bonus spells, since you're a dual and your first class isn't mage. (Though I do see a loophole - the script needs time to work, so I expect the very first level-up that complete the dual won't be bound by the multiclass proficiency restrictions.)

Alternately, you're playing a multiclass fighter/mage. You reach level 3 as a mage, that invisible creature gets summoned, and your kit is changed from the original TRUECLASS to the new clone D5FIGHT. As a multiclass mage that isn't TRUECLASS, you now get +1 spell per level. Not good.

How do we fix this? That kit-changing script needs to detect dual-class status somehow. Search the IESDP...

Quote

0x40EA OriginalClass(O:Object*,I:Class*CLASS)

Returns true if the original class of a dual-classed creature equals the class specified in the 2^nd parameter.

 

That's what we need. There are a series of flags in the CRE file for a character's original class; that's how dual classes are determined. And this script trigger detects it. We need to add this to the script that assigns the new kit, d5_dual.baf:

 

IF
  OR(4)
    Class(LastSummonerOf(Myself),FIGHTER_THIEF)
    Class(LastSummonerOf(Myself),FIGHTER_MAGE)
    Class(LastSummonerOf(Myself),FIGHTER_DRUID)
    Class(LastSummonerOf(Myself),FIGHTER_CLERIC)
  Kit(LastSummonerOf(Myself),TRUECLASS)
  OriginalClass(LastSummonerOf(Myself),FIGHTER) // Add this line
THEN
  RESPONSE #100
    ActionOverride(LastSummonerOf(Myself),AddKit(D5FIGHT))
    DestroySelf()
END

IF
  Class(LastSummonerOf(Myself),CLERIC_RANGER)
  Kit(LastSummonerOf(Myself),TRUECLASS)
  OriginalClass(LastSummonerOf(Myself),RANGER) // Add this line
THEN
  RESPONSE #100
    ActionOverride(LastSummonerOf(Myself),AddKit(D5RANGE))
    DestroySelf()
END

IF
  OR(2)
    Kit(LastSummonerOf(Myself),D5FIGHT)
    Kit(LastSummonerOf(Myself),D5RANGE)
THEN
  RESPONSE #100
    DestroySelf()
END

There. Problem diagnosed, fix proposed. Unfortunately, this fix is EE-only; that trigger doesn't exist in non-EE games. And I don't see a substitute for it.

As for your game ... if you still have the component installed, the problem will reassert itself every time your multiclass character gains a mage level. To actually fix it going forward, edit the d5_dual.bcs script in your game with the new lines as above.

Edited March 12, 2023 by jmerry

[subtledoctor]

Or just apply a -1 penalty to arcane spell slots in the new clone kits... which I thought was actually implemented? Once upon a time? Maybe? I haven't laid eyes on this code since a very long time ago and the version in CDTweaks seems different from (read: better than) the original...

[jmerry]

If you apply that penalty in the clone kits, then the dual class gets too few spell slots. Remember, no automatic bonus in a kit -> mage dual.

[The_Baffled_King]

On 3/12/2023 at 8:37 PM, jmerry said:

As for your game ... if you still have the component installed, the problem will reassert itself every time your multiclass character gains a mage level. To actually fix it going forward, edit the d5_dual.bcs script in your game with the new lines as above.

jmerry:

Sorry for the delayed reply on my part; I thought I had email notifications enabled as a default setting, but apparently I did not. Thanks for the detailed response with the fix. Maybe I should've saved you the effort by clarifying that my "fix" was to edit d5_dual.bcs so that the invisi-creature just destroyed itself... not a fix in the sense that it made the component work as intended, but I wanted to get on with the game at that point rather than check the IESDP - I didn't even have any PCs in my party who were eligible to dual class!

[CamDawg]

Thanks @jmerry, addressed in this commit.

For non-EEs, it's a little more complicated. I've gone with a race=human check since they're the only ones who can dual by default. However, there are a variety of other components in Tweaks that allow for problematic cases (non-humans can dual, humans can multi) on the originals with TobEx. In these cases, the component will be skipped until we can find a clever solution.