subtledoctor

Better, I think, to simply do inside the engine what OlvynChuru is currently doing with UI hacks: add a table or something which CharGen/sorcerer level-up/priest level-up would check when displaying available spells. Check the usual namespace for vanilla spells, and also check anything in that 2da table. (Or heck, make it a proper IDS table.) Bonus: modders wouldn't have to deal with ADD_SPELL and not knowing the ResRef of a spell at the time it is installed. (Saving us from the RES_NUM_OF rigamarole that is currently necessary to patch such spells.) EDIT - heck, if we agree on and use a 2da table here, maybe Galactygon/Beamdog will recognize its value and add support for it in 2.7. Consensus is the most important thing, methinks. Agree - that would also match (more or less) the existing format of SPELL.IDS, too.

I have an invisicreature .BCS script that looks like: IF True(A) THEN RESPONSE #100 [ACTION 1] Continue() END IF True(B) THEN RESPONSE #100 [ACTION 2] Continue() END IF True() THEN RESPONSE #100 DesrtoySelf() END Now, say I come along later and I want to add more conditions to the script. My new condition is in a .BAF file like: IF True(C) THEN RESPONSE #100 [ACTION 3] Continue() END Seems like the way to fold this into the existing script is: COMPILE ~mymod/scripts/nuscript.baf~ EXTEND_TOP ~override/script.bcs~ ~override/nuscript.bcs~ My only issue is, this needlessly pollutes the override folder with nuscript.bcs, which has no purpose other than to be prepended to script.bcs. I would prefer to DECOMPILE_AND_PATCH and simply inject the text... but there is no APPEND_TOP command for adding text to the beginning of a file. Is there a better way to do this?

Incidentally, I had not seen this construction before: I would have used "EVAL ~%SOURCE_RES%~" there... is "$SOURCE(RES)" different?

Sorry, I meant it’s worth taking a look at Galactygon’s linked thread. Just for nitty-gritty issues like, is it “WIZARD_EVARD_BLACK_TENTACLES,” or “WIZARD_EVARDS_BLACK_TENTACLES?” If two mods use slightly different names, it can be problematic, in that players would get duplicative spells. That thread shows what consensus has been achieved so far; and if you are adding more spells that might conceivably be added by other mods (core rulebook stuff) you can post it there so others can match what you did.

Pretty sure this one isn't true...

If I ever turn it into a more approachable portable function, I'll drop a note here.

You can set the druid/shaman exclusion flag on all the shaman spells, and add them the same way they are currently added (GA_SPPR150 in the kit ability table) and it will work just fine. You can give any cleric-only spell to rangers this way. In fact it’s how my sphere system works: exclude all spells from all divine casters, and for each kit manually add whichever ones are appropriate. As I said, hidespl.2da and the exclusion flags are performing the same work... in fact exclusion flags are better for being more flexible, letting you discriminate by class or kit. For that matter, an easier and better way to make ranger-only spells would be to simply name them something other than SPPR###. Then you don’t need to bother with hidespl or exclusion flags.

I know! That thread is largely my inspiration here. And I think that was actually very useful - even all this time later, there was some discussion of it recently when Spell Revisions changed over to using ADD_SPELL, as it contains some of the same spells as IWDification etc. (Btw that's a good thread for anyone who is adding spells to peruse - @Angel you might want to take a look, if you were not already aware of it.) Anyway, just writing out the posts here have clarified my thoughts a bit. Like, logistically, twinning this with spell.ids could be problematic. What if a spell mod like Olvyn's copies spell.ids to the new "modspls.2da" or whatever; and then a different mod comes after and adds new stuff to spell.ids? Now modspls.2da will be out of date. Further: what would the format of the 2da table be? Are spell pack mods expected to create pseudo-IDS names for their spells, when the spell will not go into spell.ids and the pseudo-IDS name will not and cannot be used with stuff like IDS_OF_SYMBOL? What would the point of that even be? Although conversely, if the spell pack were to use ADD_SPELL then it would have to add an IDS name anyway, so of the point is to add spells usable by sorcerers/shamans, then it is no extra effort. So I guess this might look something like this: ACTION_TRY ADD_SPELL ~mymod/spells/d5nuspl.spl~ 2 5 ~WIZARD_EVARDS_BLACK_TENTACLES~ WITH DEFAULT ADD_MOD_SPELL ~mymod/spells/d5nuspl.spl~ 2 5 ~WIZARD_EVARDS_BLACK_TENTACLES~ END ** ...and our new "ADD_MOD_SPELL" function would write the IDS name and ResRef to modspls.2da, in addition to doing whatever hocus-pocus is necessary for Olvyn's UI modification to capture it. Then a mod that comes along later to poll wizard spells can do something like: COPY_EXISTING ~spell.ids~ ~override~ COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW ~r2en_spls~ cols FOR (row = 0; row < r2en_spls; ++row) BEGIN READ_2DA_ENTRY_FORMER ~r2en_spls~ row 0 ids_num READ_2DA_ENTRY_FORMER ~r2en_spls~ row 1 ids_name PATCH_IF (~ids_name~ STRING_CONTAINS_REGEXP ~WIZARD_~ = 0) BEGIN LPF RES_NUM_OF_SPELL_NAME STR_VAR spell_name = ~%ids_name%~ RET spell_res END PATCH_IF (VARIABLE_IS_SET ~%spell_res%~) BEGIN PATCH_IF (FILE_EXISTS_IN_GAME ~%spell_res%.spl~) BEGIN SPRINT $wiz_spells(~%spell_res%~)~1~ END END END END BUT_ONLY ACTION_IF (FILE_EXISTS_IN_GAME ~modspls.2da~) BEGIN COPY_EXISTING ~modspls.2da~ ~override~ COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW ~r2en_spls~ cols FOR (row = 0; row < r2en_spls; ++row) BEGIN READ_2DA_ENTRY_FORMER ~r2en_spls~ row 0 mod_res READ_2DA_ENTRY_FORMER ~r2en_spls~ row 1 ids_name PATCH_IF (~ids_name~ STRING_CONTAINS_REGEXP ~WIZARD_~ = 0) BEGIN PATCH_IF (FILE_EXISTS_IN_GAME ~%spell_res%.spl~) BEGIN SPRINT $wiz_spells(~%spell_res%~)~1~ END END END BUT_ONLY END ACTION_PHP_EACH wiz_spells AS res => ind BEGIN [do stuff] END So I guess the main things of value would be 1) write up that ADD_MOD_SPELL function and associated functions, nice and portable so any spell pack mod can include them and use them without much extra effort; and 2) having a consensus on the name and form of my hypothetical "modspls.2da" file, so that any other mod will have a stable and consistent place to look for such spells. ** (Or whatever the appropriate syntax is for TRY... I have never fully wrapped my head around it. I wish Weidu had something a bit simpler like TRY [this] ON_ERROR [that] END...)

The stuff crossed out is not doable with NPC_EE. You need L1NPCs, SCS, or EEKeeper for that.

Opcode 214 is the most obvious way, and pretty simple. It has some interesting benefits too: if this is for a class that cannot use arcane magic (and cannot dual-class to mage), then you can have the opcode 214 spell "choose from all known (wizard) spells." Now you can add wizard spells to the character whenever you want (learn at level-up, learn from a magic item, choose from a dialogue, grant it at scripted points in the game, etc.) and they all will be available in the "pool" of abilities. Opcode 214 has some problems though: Cannot choose an ability while the game clock is stopped Cannot simply look at the available abilities without burning a use If you do the wizard spell thing above, it calls the Cowled Wizards down on you in early BG2 The best way to do this, I have already implemented. The way multiclass sorcerers work in our Tome & Blood is actually to create an innate ability corresponding to each spell available to sorcerers, and have the multisorcs use those innates instead of spells. Functionally, in-game, it is completely indistinguishable from a normal sorcerer casting spells. But under the hood it is very different. (It enables some interesting stuff too, like using a mana system instead of spell slots, and adding always-available spells sort of like 3E Domain Spells. But that's neither here nor there.) Problem is, it is also very complicated to implement. Doing it for a handful of innate abilities, instead of recreating the entirety of sorcerers' spellcasting, would be a bit simpler. But still not actually simple. Off the top of my head: Figure out a way to track the number of uses (points, or whatever)... best bet here is to use the Tracking stat and opcode 95. For each innate ability in the pool, set up the following: 1) the innate spell itself; 2) an .EFF with opcode 171 granting the innate spell; 3) a spell with opcode 206 blocking the .EFF; and 4) a spell with opcode 321 canceling the 206 spell. (EDIT: 3 & 4 are only necessary if you want to include the ability to add new abilities to the pool.) Set up a spell with a bunch of opcode 177 effects, triggering all of the .EFFs above. Set up a spell with 1) a 172 effect for every innate ability in the pool; and 2) several opcode 326 effects, polling the Tracking stat, and casting the 177 spell once for each 'point' of the stat's value. Set up a spell that uses opcode 95 to reduce the Tracking stat by 1. Every innate ability in the system will have, in addition to its normal functions, an opcode 146 effect which casts the 95 spell, and then another 146 effect that casts the 172/326 spell. (The order of those effects is important.) Apply a permanent repeating spell or effect on the character which uses opcode 326 to poll the Fatigue value. If it ever finds the Fatigue stat is <1, then it casts a spell that will 1) set Fatigue to 1; and 2) use opcode 321 to cancel the 95 spell; and then 3) cast the 172/326 spell. Now you have a pool of abilities that work exactly like sorcerer casting: they all appear together in the UI and they all show the same number of uses on their button; and when you cast one of them, that number is reduced by one on all of their buttons. When you rest, the number is restored whatever the value of the Tracking stat is... you can increase it over time upon leveling up, or however you want. You can place the abilities behind the 'innate abilities' button, or if the class has the 'cast spell' button then you can place these abilities there, making it really like sorcerers' casting. Not for the faint of heart. But the result is slick. I've been meaning to use a system like this in my Feat System mod, for the "Shadow Pool" and "Illusion Pool" spellcasting feats. Best thing would be write up a portable function, so any mod could drop some spells into it and it would spit out a custom ability pool. But alas, I have not gotten around to doing so, and I have no idea when I might...

Nothing too complicated - I just disable the original kit and add a wholly new kit with the same name.

I don't play with them, but I'm pretty sure it is just a flat 50% resistance. Everything is independent and optional. The only exception is component 67, "Choose-Your-Own-Familiars," automatically installs component 69, "Indelible Familiars," along with it.

We have that! This mod has as component that adds several new dragon disciple kits, letting you choose your elemental affinity. (Are fiery red dragons the only ones who ever got busy with humans?) I think it modifies the red dragon disciple kit to make them somewhat uniform. From the v0.7 readme: Dunno. I suppose why not?

I hIghly doubt sneak attacks for spells are feasible in this engine...

Huh, that's true. All of the shaman spells are in hidespl.2da though, so that a must be what stops them being automatically added to clerics and druids. (I didn't even realize hidespl.2da did that.) Then they are added manually in the shaman's kit table. Seems like you could remove them from hidespl.2da and set both exclusion flags, and everything would work identically. But then, that raises (NOT BEGS) the question of why Beamdog coded it the way they did...

It’s not available to clerics/paladins because it has the “cleric” class exclusion flag set. I think it actually has the druid exclusion flag set as well, so nobody gets it by default. IIRC shamans only get it by force - look at clabsh01.2da. (Or clabshgs.2da - I forget which one the class actually uses.)

Very good point. 2da is just as good for these purposes. If necessary, I was just thinking about copying and pasting it into a new “RES_NUM_OF_MODSPL_NAME” function, only changing the targeted table. Put it in a function library along with other stuff here, and then any mod can include and use it. (Though now that I think of it, that’s probably unnecessary. If we just make a big table with IDS names and corresponding ResRefs, then READ_2DA_ENTRY should be sufficient in ~99% of cases.)

I don't think any of Weidu's existing functions need to be altered, or that Wisp needs to be bothered. I envision something like a portable pack of functions that any modder can use, so that 1) they don't have to write the code from scratch, and 2) inter-mod compatibility will be baked in, with no extra effort.

I have been thinking about how to get modders together and ensure compatibility among mods that add, change, or otherwise manipulate player-usable spells. This comes from reading this thread as well as several pleas for compatibility work, which have fallen on deaf ears. The beginning of the issue is this: The number of spells available to sorcerers/shamans at level-up, and to mages/bards/clerics/druids at character generation, is limited to 50 per level. These spells share a naming scheme (SPWI101 through SPWI150, SPWI201 through SPWI250, etc., and ditto with the SPPR prefix), and they all get recorded in SPELL.IDS and get IDS numbers for reference (1101 through 1150, 1201 through 1250, etc. and 2101 through 2150, etc.). These spells are all subject to handy reference and manipulation via Weidu's RES_NUM_OF_SPELL_NAME, and similar functions. A typical use of that function involves first checking whether the spell name exists in SPELL.IDS, and then looking up its ResRef (filename). The vanilla game uses up roughly 30% to 50% of the available slots at any given spell level; mods add more. Mods that add more generally do so via Weidu's ADD_SPELL function, since it handily makes the spells available for lookup and use in game with all the above characteristics, automatically finding the next available slot and assigning a compatible filename. However, if there are no available slots, the ADD_SPELL function will fail, and it will actually cause the entire mod install to fail. (There are reasons for that; let's not litigate it here.) So, now there are several mods that add spells this way, and if a player uses enough of them, the later ones are subject to install failures. Nobody likes to see that. Recently, Olvynchuru has added a new mechanism in his mod that applies a UI modification to the sorcerer/character generation spell-picking screens. My basic understanding is, these modified screens allow you to pick from any of the usual spells, and additionally from spells added by his mod. This solves the problem of his spells being excluded; but it introduces several new issues: I don't know whether his system has hooks to allow other modders to have their spells included in his modified spell-picking screens; this could especially be an issue for mods installed after OlvynSpells. Mods that try to comb through all player-available spells will generally use one of a couple methods: comb through SPELL.IDS; use regexp to match the "SPWI###" and "SPPR###" filenames; (for arcane spells) checking all scrolls from which a spell can be learned, and compiling the spells that can be so learned; etc. OlvynChuru's mechanism will render several of these methods non-functional. I'm not sure how you could accomplish this with spells added by OlvynChuru's system, especially if other mods start using their own variants of the system. There is no equivalent of a RES_NUM_OF_SPELL_NAME function available for spells added by his system. So, me personally, I am not about to add a whole new section of code to my mod just to handle Olvyn's spells in addition to the ones added by traditional means. Set aside that it would be non-trivial and bug-prone; even if I put in the effort, my mods would still not be compatible with the next mod that comes along and adds spells in this new way. (I may understand that @Artemius I may be adapting his mod(s) to such a system...?) Maintaining compatibility will be untenable if more mods do this sort of thing. I think the best solution is, more or less, to make a new and expanded version of SPELL.IDS. Call it MODSPL.IDS. Maybe begin with the full contents of SPELL.IDS (or perhaps just the arcane and divine spells, since this issue doesn't really affect innates). Then any mod adding new spells that may go past SPWI150 can 1) check whether MODSPL.IDS exists; 2) if it doesn't exist, create it; and 3) append information for the new spells to it. These steps can be tucked into a nicely portable function, usable by any mod. Then, on the other side, mods that need to know what spells are in the player's game can 1) check whether MODSPL.IDS exists; 2) if it does exists, do the business with respect to spells in that file; 3) if it does not exist, do the business with respect to spells in SPELL.IDS. MODSPL.IDS can, for mod-added spells, simply list the ResRef in place of the traditional IDS number. This way such spells can uses modder prefixes, but those spells and their modder prefixes would be easily available from a central list to other mods and UI functions, etc. We might also want variants of the RES_NUM_OF_SPELL_NAME functions, but those should be pretty simple to make and will likewise be nicely portable. In conclusion: I honestly don't even kn ow if this is necessary. Maybe it's more trouble than it's worth. But I'm curious to hear the thoughts of other people. Context: I'm tinkering with a total-conversion-ish 5E spellcasting mod that will want to know all spells available to each class. The current beta version of the 5E system (my Arcanist kit) does not work with Olvyn's Spells. If there is consensus for something like what I set out in this post, I would love to bake it into my full mod.

Jaheira gets "Harper's Call." For whatever reason, Beamdog decided that Shamans should not get Raise Dead, but then chickened out and gave them this:

No clue. Has anyone installed them both? If so, ask them how it went. This is how such things are learned.

Don’t they get “Recall Spirit,” which is the same thing?

Good question! It's not clear from the description, and I didn't remember the answer myself, so I just looked at the effect: the on-hit penalty lasts for 3 rounds, and it does stack. So if the Hexblade is in melee and hits the target every round (and the target fails a saving throw every time), then the target will have a total of -4 Luck and -4 to saves. No, "Luck" has a specific meaning in this engine: positive Luck increases the physical damage you deal out (to the top of your damage roll, but not above it like a proper bonus) and reduces the damage you take from incoming spells like Fireball. Negative Luck makes you take more damage from spells and deal out less physical damage. The Luck spell talks about saving throws, so people conflate the two; but the Luck stat has nothing to do with saving throws, so in the kit description I try to be precise by mentioning both Luck and saves separately. So to be clear, if you can get a Hexblade to hit a target a few times, that target: will make weaker physical attacks will take more damage from spells will be less likely to save against spell effects So the Hexblade will take less damage in melee, and if you fire some spells at your opponent while attacking, those spells will be more effective. The idea is to make this kit function well as a "gish" i.e. fighter/mage mixing magic with physical attacks. (Note, this works best against non-magical opponents, and maybe clerics. Against a mage with Stoneskin/PfMW, you can't hit them and therefore can't get this cycle going to weaken them.)

Yup, I just checked and that's how it works in my game as well. I even give Non-Detection (renamed "Protection from Divination") protection against the DivinationAttack sectype, which means it will protect your Blur/Mirror Image etc... but Glitterdust/Faerie Fire bypasses it because they don't have the Divination primary type or the DivinationAttack secondary type. I think it's okay, because unlike Invisibility Purge/True Sight/SR Detect Invisibility, which work over an extended period of time, Glitterdust and Faerie Fire only hit once. (They do prevent the affected targets from going invisible again in SR/SRR... maybe the duration of that should be reduced from 4 rounds to 2-3 rounds? Though now that I look at it, in my setup the affected target can go invisible again, partially anyway... I wonder if I should re-think that...

NPC_EE allows you to make some class changes (within reason) at install-time, and make kit and proficiency changes in-game. I think SCS has a component tgat goes further, letting you choose class, kit, and profs in-game. It comes at the problem from a different direction; each has been shown to be clunky in its way, which I think is inescapable. My mod loadout is a bit different - base SR + Random Tweaks + TnB’s modified invisibility - but I am using Faerie Fire to reveal invisible foes all the time. Don’t honestly know how it interacts with Nondetection, though.