Modders' use of limited resources

[subtledoctor]

Some of the things modders can use in the game are rather limited; think, for example, about kit usability flags.  It's probably worth collecting data about the various mods that use such resources, in order to avoid compatibility collisions - or at least identify them and warn people. This kind of thing should be in mods' Readme files, yes, but it might also be nice to have it collected in one place.

I'll go first.  I used a number of limited resources in a number of my mods, because I'm selfish I can do cool things with them and I generally try to limit the compatibility issues that arise as a result.  I'll post what I can remember at the moment; I'll fill this in further if I think of any others.

--------------------------------------------------------------------------------------

Kit Usability Flags.  There are only a few of these that are unused by the vanilla game.  The Lathander/Helm/Talos cleric kits, I think the Undead Hunter, I think the Jester/Blade/Skald, and I think the Totemic Druid.

-- Faiths & Powers uses the cleric kit flags, in order to determine armor usability for the ~50 cleric kits installed by the mod.  I can only justify this by pointing out that they were designed for cleric kit usability, and I am using them for cleric kit usability!  FnP modifies the .ITM files of all armors such that plate mails are restricted from use by the Lathander and Helm kits, and chain mails are restricted from use by the Lathander kit.  Any mod that changes which items can be used by  these three kit flags will be incompatible.

-- Faiths & Powers also makes some changes to druid kit flags.  The base druid class restrictions are replicated in the Totemic kit flag; this has no impact on gameplay by itself.  FnP gives that flag to all druid kits so the druid class flag can be liberalized.  All armors designated as chain mail or plate mail are restricted from the three druid kit flags; then a few are whitelisted later.  This, by and large, should have little impact on compatibility - unless another mod wants to use those kit flags in a different way, let them wear metal armor, etc.  That would be incompatible.

-- Might & Guile's 'Revised Bards' use the Skald usability flag.  It sets all spells from the Invocation, Conjuration, and Necromancy schools to be excluded from use by the Skald flag.  In the base game this only affects the Skald kit itself, and MnG replaces that kit with a new version, so there should be no discernible consequences.  If another mod uses the Skald flag there would be a compatibility issue here.

-- The Mana Sorcerer kit uses the Beastmaster usability flag.  It sets all wizard spells to be unusable by the Beastmaster.  This of course has no discernible effect on the base game, since the Beastmaster is a ranger kit.  The only way a compatibility issue would arise is if another mod also uses the Beastmaster flag in some way that also affects arcane magic.

-- I vaguely recall some other mod using the Undead Hunter kit flag, and maybe one uses the Jester kit flag?  I can't recall off-hand, maybe someone can remind me.

--------------------------------------------------------------------------------------

The Ammo3 Item Slot.  This is a hidden item slot.  The game only displays 3 slots for ammunition, but there is a 4th, invisible slot.  You can insert something into this slot and thereby give a character equipping effects from an item, without any indication in-game of how it is done.  The problem with using this slot is, there is only ONE, ever, anywhere.  Any combined use of this item slot will result in incompatibilities.  My feeling is, it is therefore okay to use the slot in ways that cannot be affected by other mods. 

-- The Multiclass Sorcerers in Tome & Blood, the Multiclass Shamans in Faiths & Powers, and my Mana Sorcerer all use an item in this slot in order to have an at-will ability to learn spells.  In each case the hidden item is restricted to the particular kit added by the mod; if any other mods use this item slot for their own kits, there will be no problem because you can only have one kit. 

--------------------------------------------------------------------------------------

Spellstates.  These are added in the EE 2.0+ engine, and can act as markers that can be checked by opcodes 318/324/326.  For example, you can set an item to jump from +1 to +5 in the hands of "the chosen one;" set an event apply a spellstate or proficiency value to the player; and the sword will suddenly become Excalibur in their hands.  If you are playing IWD-in-EET, this could be a way to implement that sword that is +5, but only within 100 miles of Lac Dinneshere.  SPLSTATE.IDS has about a 80 free slots for added spellstates.

-- About 5 of my mods add ~1-5 spellstates each.  About 15 in total, if you install all of my mods. 

-- From a recent discussion about the EE FixPack, SCS apparently uses roughly 20 custom spellstates.

--------------------------------------------------------------------------------------

Proficiencies and Stats.  These are newly useful in the EE 2.0+ engine, since opcode 233 can increase or decrease proficiencies and things like opcodes 318 and 326 can condition spells and effects on stat checks without resort to script.  They can therefore work just like spellstates.  As I said there are only ~100 spellstates available for use by modders , but proficiencies can increase this immensely.  Each actual weapon proficiency only uses the first three bits (of eight) of the first byte (of four) of the associated stat.  That leaves, more or less, 28 bits that can be used in the same way that spellstates can.  There are over 30 proficiencies in the game, so that means there could be over 900 spellstate-equivalent values usable by modders.

Stat 89 through 115 (except for 108 and 109) are used for normal proficiencies by the base game; stats 109 and 116 through 133 are used by the Detectable Spells system; and stats 108 and 134 are not used at all AFAIK.  In addition to using bit-equality checks, those three stats can theoretically be used for simple numerical values; with 4 bytes available, it mean you could track a number up to a value of ~4.25 billion.  (I have no idea of why you would possibly want to do that though, and I don't recommend it. )

-- The 2nd, 3rd, and 4th bytes of stat 108 is used by my multiclass sorcerers, multiclass bards, Arcanist kit, and 5E arcane casters. The 1st byte is left untouched; it can be used as a new proficiency or for seven pseudo-spellstates, without any impact on compatibility.

-- The 3rd byte of stat 109 is used by Tome & Blood to distinguish among different kinds of simulacra. And multiclass sorcerers, multiclass bards, the Arcanist kit, and 5E arcane casters use the 4th byte of stat 109. The 2nd byte of stat 109 is (as of this writing 5/22) unused. The first byte is either unused, or used by SCS to track weapon enchantment in some way. (IIRC Davidw said he planned to discontinue its use, but I'm not sure what the current status is.)

-- The 2nd, 3rd, and 4th bytes of stat 134 are used by Faiths & Powers spontaneous spellcasting and 5E divine casters. The first byte is unused AFAIK; it could be used for a new proficiency or for seven pseudo-spellstates, or whatever. 

-- The 4th byte of stat 115 (club proficiency) is used by Might & Guile, Faiths & Powers, and Scales of Balance for pseudo-spellstates, to add new effects to fighting styles and for other purposes.

-- I believe the Eldritch Magic mod uses the 2nd byte of stat 113 (single-weapon style).  This has no impact on the style proficiency itself, which works with the default two stars and can be extended up to seven stars.  And the 3rd and 4th byte of the stat are still available for use.

-- Stat 33 ("tracking") is used by my Mana Sorcerer and Psionicist mods to track mana points/psionic strength points.  Stat 33 is unlike proficiencies; it can only be used for basic numeric values, between 0 and 127.  Another mod that uses stat 33 in a different way would conflict with these mods.

-- I believe Tweaks Anthology uses stat 33 for the "breakable armor" component.  This is only in Tutu games, or maybe actually only in old BG1 games.  It does this in a way that will be incompatible with most other uses of the stat; however, it does not use the stat in EE games so any EE-only uses of stat 33 (like mine) will be fine.

--------------------------------------------------------------------------------------

SPECIFIC.IDS.  This file has 255 entries, similar to SPLSTATE.IDS.  In some ways these values can be used similarly; even better, they work on the pre-EE engine and can be used for conditional effects in opcode 177.  (Spellstates and proficiencies/stats only work with the EE opcodes 318/324/326.)  However, these are severely limited in several respects:

• The hard limit of values that can be used in the game is 255, period, end of story.  The base game only uses a few, but Siege of Dragonspear (and presumably EET) use a bunch more (see below), and lots of old mods add lots of entries here.  The .IDS file can fill up very quickly.
• SPECIFIC values are used for red- and blue-circle AI programming, especially in the recent Beamdog games.  This should be used very carefully because it can screw up the enemy AI if applied to the wrong characters.
• A character can only have ONE value for this.  If you set a character to get a new SPECIFIC value, either by a scripted game event or for a spell or item or something, it will knock out any other SPECIFIC value they have.  Therefore, if two mods use this and they both affect the same character, one of the two mods will stop functioning properly.

I tend to consider this as similar to the Ammo3 slot: the best way to make use of it is in a way that is entirely contained by the content of the mod.  Refinements might use this for thief kits; another mod could successfully use it for clerics, or for a custom non-thief NPC, or something like that.

-- My version of Refinements (v4) and Might & Guile add an entry to SPECIFIC.IDS to implement the Use Magical Device ability (which is a more limited form of UAI, merely allowing thieves to use scrolls and wands).  It only affects party members, and only in the thief class or thief multiclasses.

-- I recall reading that the Shadow Magic mod uses this as well... I think for a wizard or monk kit.

--------------------------------------------------------------------------------------

That's all I have for now.   Feel free to post any other uses of limited resources that you have implemented or know of, and I'll try to update this first post. 

Edited September 16, 2022 by subtledoctor

[jastey]

What are kit usability flags?

I think this is a very good thread to start.

But I don't even know whether my Wolfhound and Drow kits (for specific NPCs only -Grey, Solaufein) use it?

[Jarno Mikkola]

3 hours ago, jastey said:

What are kit usability flags?

In .cre file; offset 0x0244,

In .itm files; offset 0x001c (class) and 0x0029 ... 0x002f.

2 hours ago, subtledoctor said:

0x2f, and 0x2f

The first "f" is actually a "d". Tipos are nice.

Edited February 7, 2020 by Jarno Mikkola

[subtledoctor]

Offsets 0x29, 0x2b, 0x2f, and 0x2f in .ITM files.  (0x2a, 0x2c, and 0x2e are min stat requirements.)

Offsets 0x1e, 0x1f, 0x20, and 0x21 in .SPL files.

And kitlist.2da controls which kit operates via which flag, it is in the 8th column labeled "UNUSABLE"

These are hex values and they can be combined - e.g. my multiclass bard kits are "0x00800200" which is a combination of both the Skald flag (0x00800000) and the Enchanter flag (0x00000200).  This means these kits cannot use any items or learn any spells that are excluded from either the Skald or the Enchanter kits.  (I.e. flags restrict use, so combining flags results in more use restrictions.)

Most mod kits will generally use some kit usability flag or other - I have kits that I give the Barbarian flag, if I want them to be limited to splint mail, and I used to give my Bladesinger kit the Archer flag, since I wanted to limit it to leather armor + elven chain.  Generally there is zero problem with this sort of thing.  The conflicts can arise when a mod changes what the flag does - e.g. by patching .ITM files to behave differently with regard to one or more flags.  (You would see a "COPY_REGEXP GLOB" for all .ITM files, and something like "WRITE_BYTE 0x2f (THIS BOR 0b00000010)".)

(Lots of kits mods have had the idea to give item use bonuses - "I want a druid that can use bows," or "I want a cleric that can use swords" etc.  This cannot be done because there is no flag that reduces restrictions.  Look at how Beamdog dealt with Shamans: they enabled the entire druid class to use bows and axes, and then added special handling (opcode 319) to re-enable the druid exclusion.  But this is problematic because any mod that, say, adds a bow but doesn't add the opcode 319 handling, will find that its bow is usable by druids, contrary to the modder's intent.  Messing with item usability (and even moreso, spell learning) generally involves broad effects that are very likely to impact inter-mod compatibility.  For that reason I generally suggest it only be done in game-wide usability overhauls like the one in Faiths & Powers, not for a single kit benefit.  (I have fairly extensive experience with this stuff and if anyone does want to play with item/spell usability, I'm happy to give advice about what I have seen work well.))

Edited February 7, 2020 by subtledoctor

[Gwendolyne]

2 hours ago, subtledoctor said:

Lots of kits mods have had the idea to give item use bonuses - "I want a druid that can use bows," or "I want a cleric that can use swords" etc.  This cannot be done because there is no flag that reduces restrictions.  Look at how Beamdog dealt with Shamans: they enabled the entire druid class to use bows and axes, and then added special handling (opcode 319) to re-enable the druid exclusion.  But this is problematic because any mod that, say, adds a bow but doesn't add the opcode 319 handling, will find that its bow is usable by druids, contrary to the modder's intent.  Messing with item usability (and even moreso, spell learning) generally involves broad effects that are very likely to impact inter-mod compatibility.  For that reason I generally suggest it only be done in game-wide usability overhauls like the one in Faiths & Powers, not for a single kit benefit.  (I have fairly extensive experience with this stuff and if anyone does want to play with item/spell usability, I'm happy to give advice about what I have seen work well.)

When updating old SHS items mods, I updated this function I wrote for my mod. Variable %GW_shaman% automatically handles items shaman usability flags in EE games.

Edited February 7, 2020 by Gwendolyne

[subtledoctor]

Cool.  I've submitted code for Item Revisions to deal with it, and most new mods do.  But as usual, the tricky thing is older mods that don't get updated.

By the way, I very much did not intend to limit this discussion to kit flags and spellstates and proficiencies.  If there is some other useful but in-short supply resource that a modder has decided to use, feel free to mention it!  Anything like that would be relevant. 

(My motivation is, I had a minor cow when I noticed quite by accident that CDTweaks was making use of the Tracking stat.  It turns out fine, because it is only on pre-EE games.  But it would be really useful to have all such information in a single place.)

[Jarno Mikkola]

File names.... also area names etc that use lib's functions to define themselves.

A lot of my old kits use the kit flags as their restrictors, but they don't usually allow much added items and even if that were the casewith the few that allow more, thing with the other kits is, they won't then have the proficiency allowance to use the items, so for example mage kit that can use an axe will still usually get the +5 Thac0 penalty even if they can oddly use them.

Of course I like most the kinda mod that allows nearly everyone use nearly all kinds of items, just not proficiencly and they might not get the benefits, like spell slot bonuses, as they don't have the capability to get any. This is nearly always compatible to a guite high decree.

Edited February 7, 2020 by Jarno Mikkola

[Gwendolyne]

For old kit mods (classic game), it is very easy to play with kits unusability flags as long as you follow good rules (for example, your kit can't wear leather armors, add the shapeshiper flag to your kit flag, your kit can't use use daggers, add one of the cleric kit flag...) and it won't screw up all other kit mods. And DON'T FORGET to never use this flag in EE games. As far as I saw, it is not a good idea.

[Luke]

Yeah, I do hope the incoming update will drastically increase the maximum number of Spellstates: they're invaluable for any Quest / AI mod. Alternatively, we need an 'ImmuneToOpcode()' script trigger...

[subtledoctor]

On 2/8/2020 at 6:52 AM, Luke said:

Yeah, I do hope the incoming update will drastically increase the maximum number of Spellstates: they're invaluable for any Quest / AI mod. Alternatively, we need an 'ImmuneToOpcode()' script trigger...

That brings up an important point: AFAIK there is no easy way to check for stat bit-equality in scripts.  Quick primer on bit-equality: it checks for whether a stat's value encompasses a particular bit.  You can use the Proficiency() trigger to check for whether the player has grandmastery in long swords; and GM is 5 stars which means the 1st bit ("bit0," or 1) plus the 3rd bit ("bit2," or 4).  So checking whether someone has 5 stars in long sword proficiency is identical to checking bit0 plus bit2 in stat 90.

Opcodes can filter by bit-equality in any stats in STATS.IDS; but scripts cannot.  The Proficiency() trigger only checks the first 3 bits of the proficiency stat.  What this means is, while the upper bits and bytes of proficiencies can fill in as an extra 900 spellstates for some purposes, they cannot do so for script-related purposes.  In such cases you really need to use spellstates.  (Or SPECIFICs in some circumstances, but you have to be careful with that, and anyway there are even fewer free SPECIFIC values than there are spellstates.). The upshot is, if your mod adds a spellstate but only uses it for spells or items - if it doesn't use the CheckState() trigger anywhere - then you should consider using opcode 233 and a proficiency instead.

Incidentally SPECIFICs are another good example of a limited resource for modders.  If any mods add or use SPECIFIC.IDS values, it's worth mentioning that either here or in the Readme.

EDIT for clarity regarding bit0 and bit2

Edited February 14, 2022 by subtledoctor

[Luke]

15 hours ago, subtledoctor said:

... and GM is 5 stars which means bit 1 (1) plus bit 3 (4).  So checking whether someone has 5 stars is long sword proficiency is identical to checking bit 1 plus bit 3 in stat 90.

Minor nitpick: it's bit 0 (2^0 = 1) plus bit 2 (2^2 = 4)...

Anyway, the best way to flag a certain ITM / SPL is that of using spellstates, opcode #328 and the CheckSpellState() trigger.

Alternatively, you could use an unused STAT, opcode #233 and the CheckStat() trigger, but that's not ideal because you have to be sure that the STAT you choose is really unused, or opcode #233 will fail when setting the desired value.

For instance, think of Fighter-Mages and Black Blade of Disaster: if you already have some proficiency points in Long Sword, then the spell will not grant you GM in Long Sword. To tell the truth, this issue can be fixed via putting opcode #233 in the main spell (timing mode = 0 or 10) instead of attaching it to the "sword" item (timing mode = 2). But unfortunately, this is not the case for "real" (not magically created / not temporary) items that grant a particular immunity when they're equipped: in this case you need to use opcode #233 with timing mode 2 and that might be a problem if the STAT you chose is already used...

So, to sum up: if you use opcode #328 with your personal (unique!) identifier and the CheckSpellState() trigger, then you're 100% sure everything is fine... As matter of fact, SCS does exactly that (as a result, it adds a certain amount of entries to SPLSTATE.IDS...)

15 hours ago, subtledoctor said:

... and anyway there are even fewer free SPECIFIC values than there are spellstates.

Unless I'm missing something, the hard limit for EA, RACE, GENERAL, GENDER, SPECIFIC, CLASS and SPLSTATE is 256 (from 0 to 255...)

And finally, you might want to mention SPELL.IDS: this is another limited resource (even though I think it's rarely used. As far as I know, the only mods that add a certain amount of entries to this file are IWDification and Spell Revisions...)

Edited February 9, 2020 by Luke

[subtledoctor]

On 2/9/2020 at 5:18 AM, Luke said:

Minor nitpick: it's bit 0 (2^0 = 1) plus bit 2 (2^2 = 4)...

Edited for clarity. 

Quote

Anyway, the best way to flag a certain ITM / SPL is that of using spellstates, opcode #328 and the CheckSpellState() trigger.

Alternatively, you could use an unused STAT, opcode #233 and the CheckStat() trigger, but that's not ideal because you have to be sure that the STAT you choose is really unused, or opcode #233 will fail when setting the desired value.

This is not really true.  Or at least, it doesn't encapsulate the nuances of how to make the most efficient use of resources:

• flagging someone or something in a way meant to be identified by .ITM or .SPL: use a proficiency
• flagging someone or something in a permanent way meant to be identified by a script: use a local variable
• flagging someone in a way meant to be identified by script OR .ITM/.SPL, or flagging with while-equipped timing: use a spellstate

(Even that is a kind of oversimplified way of describing it, but it really depends on the circumstances.)

Quote

So, to sum up: if you use opcode #328 with your personal (unique!) identifier and the CheckSpellState() trigger, then you're 100% sure everything is fine... As matter of fact, SCS does exactly that (as a result, it adds a certain amount of entries to SPLSTATE.IDS...)

I guess that makes sense for AI/Detectable Spells purposes.  The EEs have also moved from using proficiencies (ExtraProf1 through ExtraProf19) for this purpose, using spellstates instead.  That is a noble goal, but the fact is that so many old mods still use proficiency-based Detectable Spells, and always will, that this solution just splits the baby.  Modders still can't use the ExtraProf proficiencies for fear of disturbing old-style Detectable Spells; and now they have fewer spellstates to work with as well.  Probably better would be to keep using the ExtraProf proficiencies, but change all checks from CheckStat() to Proficiency().  I think that new trigger limits the check to the first three bits, leaving all the other bits free for other uses. 

For making spells detectable, you can't really use local variables, because they are set permenently.  You could have a subspell remove the variable at the end of the spell's duration, but this would be problematic for spells that are dispellable.  So this use really wants either spellstates or proficiencies.  And since there is no bitwise version of the CheckStat() trigger*, spellstates end up a better fit than proficiencies.

(*Note, that new Proficiency() trigger really is a bit-wise version of the CheckStat() trigger - at least for the first three bits of each stat.  Theoretically this means that the number of possible Detectable Spells uses for the existing ExtraProf stats has at least tripled... but in practice, no one is going to make use of that.    EDIT - but if you’re concerned with detecting weapon enchantment, I think you could do that with this trigger, using the first 3 bits of, say, stat 109 instead of 5/6/7 spellstates.)

If doing this in an item, you could actually use local variables.  Set the variable permanently via a subspell upon equipping the weapon; and have a timing mode 2 177/232 .EFF checking HP<102%, casting a subspell that uses opcode 321 to cancel the local variable spell (or, alternatively, setting the LV to 0).  Give the item 206 immunity to the cancellation subspell with timing mode 2, and voila: you have a local variable only when an item is equipped.  For purposes of detection by script triggers, this would be equivalent to a spellstate, and there is no functional limit to the number of local variables in the game.

But this is a whole conversation all its own.

Quote

For instance, think of Fighter-Mages and Black Blade of Disaster: if you already have some proficiency points in Long Sword, then the spell will not grant you GM in Long Sword. To tell the truth, this issue can be fixed via putting opcode #233 in the main spell (timing mode = 0 or 10) instead of attaching it to the "sword" item (timing mode = 2). But unfortunately, this is not the case for "real" (not magically created / not temporary) items that grant a particular immunity when they're equipped: in this case you need to use opcode #233 with timing mode 2 and that might be a problem if the STAT you chose is already used...

The BBoD thing (bug?) is why I advocate using proficiency 108 or or 109 or 134 for proficiencies with weapons created by spells.  Then each spell can decide how it want to grant the skill to use the summoned weapon.  (It's extremely annoying for, say, a F/C to summon a spell weapon like Moonblade, and see his/her combat effectiveness go down instead of up.)

In any event, for purposes of replicating a spellstate, you would use opcode 233 to increase the proficiency, not to set it.  As an example let's look at look at something like the Finesse ability, to add DEX modifiers to melee thac0.  A very (very) rough version might look like: set daggers and short swords to give the wielder a thac0 bonus via opcode 177/.EFF with timing = 2, but precede it with a 318 effect blocking the bonus if you don't have the "d5_finesse" spellstate.  So far so good - the daggers and short swords will operate normally, until you apply a 328 effect with the d5_finesses spellstate, after which that person will get an extra thac0 bonus. 

In this case, there is no need to do this with a spellstate.  Instead of opcode 328 to apply the spellstate, you could apply opcode 233 to increase the bastard sword proficiency by 256 points.  Change your 318 effect to block the bonus when stat 89 is not bit-equal to the 9th bit (bit8, i.e. 256,  i.e. 1 << 8).  Now you have freed up one of ~100 spellstates by instead using one of ~900 proficiency bits.  And it will have no effect on your use of bastard swords. 

You can do interesting things with this.  Say you equip 2 daggers or short swords and dual-wield: now your bastard sword proficiency will be increased by 512.  You can put another check for the 10th bit of stat 89 (i.e. bit9 / 2 << 8 ) and have an entirely different bonus effect kick in only when you dual-wield.

Quote

Unless I'm missing something, the hard limit for EA, RACE, GENERAL, GENDER, SPECIFIC, CLASS and SPLSTATE is 256 (from 0 to 255...)

Right.  I wasn't clear... I think what I meant to say is, in medium/heavily-modded games, I have seen that SPLSTATE.IDS ends up having about 160 entries (leaving plenty more for me to add) while SPECIFIC.IDS had upwards of 240 entries.  I don't recall which mods are adding lots of SPECIFIC values, to note here... but some mods are definitely doing it.

Quote

And finally, you might want to mention SPELL.IDS: this is another limited resource (even though I think it's rarely used. As far as I know, the only mods that add a certain amount of entries to this file are IWDification and Spell Revisions...)

Good point.  There are about 25-30 spots available for ADD_SPELL to work at each spell level, among both arcane and divine spells.  IWDification, SCS IWD spells, b_Spells, Faiths & Powers, and Spell Revisions all use about 3-5 such slots at each spell level. (The first four largely overlap, so with both SR and a source of IWD spells,there will still be 10-20 slots remaining at each level.)

Edited February 14, 2022 by subtledoctor

[Luke]

22 hours ago, subtledoctor said:

There are about 25-20 spots available for ADD_SPELL to work at each spell level, among both arcane and divine spells. 

Right. But as far as Innate and Class abilities are concerned, the situation is way better (also because 'level' is irrelevant).

An unmodded BG:EE install uses:

• 367 SPIN slots (out of 1,000)
• 41 SPCL slots (out of 1,000)

An unmodded BG2:EE install uses:

• 482 SPIN slots (out of 1,000)
• 69 SPCL slots (out of 1,000)

An unmodded IWD:EE install uses:

• 120 SPIN slots (out of 1,000)
• 87 SPCL slots (out of 1,000)

[kjeron]

6 minutes ago, Luke said:

Right. But as far as Innate and Class abilities are concerned, the situation is way better (also because 'level' is irrelevant).

An unmodded BG:EE install uses:

• 367 SPIN slots (out of 1,000)
• 41 SPCL slots (out of 1,000)

An unmodded BG2:EE install uses:

• 482 SPIN slots (out of 1,000)
• 69 SPCL slots (out of 1,000)

An unmodded IWD:EE install uses:

• 120 SPIN slots (out of 1,000)
• 87 SPCL slots (out of 1,000)

SPIN and SPCL slots are irrelevant though.

The only action/trigger without a RES equivalent is HaveSpellParty(), which can be achieved with 6 instances of HaveSpellRES(), one for each party member slot.

[subtledoctor]

Right.  The most important aspect of the ~25 free slots per level in the arcane and divine spells is that those are the only spells that 1) are available to know and memorize at character generation, and 2) are available for sorcerers and shamans to learn.  If, say, an early mod fills up all of the slots from SPWI101 through SPWI150 (like some of the old megamods used to do), then no later mod will be able to add more 1st-level spells for sorcerers.