subtledoctor

I like the "ioun stone at feet" thing! Though I guess it can make it hard to spot. In any event if this were to be a mod, it would be simple to remove the ioun stone animations from actual ioun stones, it would be optional after all. I'm curious, did you also disable the normal animations? In my game I have revised Non-Detection, and I just noticed that it creates the big blue bubble, probably because I added an opcode 205 effect and I guess that animation is hard-coded to opcode 205? It's super annoying because it is exactly the opposite of what Non-Detection should look like. I also had the "shimmering ground" vanilla spell shield effect when casting Haste, because I set Haste and Slow up to cancel each other rather than replace each other, via sectype removal. I managed to disable the Haste/Slow animation, I suppose I need to do the same thing for Non-Detection/opcode 205. But it would be super great to have a single mod that makes all of these animation adjustments, and it looks like you have a great start to that! I like that the blue bubble is Spell Shield, since visually it sits outside the other animations and seems to protect them. I wonder if Dispelling Screen should use a similar bubble, in a different color? (White?) I like the different colors of the different Deflections... though, my mod sets them so that if you cast Greater Deflection, it actually gives you all three at the same time. Three versions of the same animation in different colors might look... muddled. How did you come up with the colors for the Deflections? I wonder if it's worth trying to systematize it. To me green says "novice" or "introductory" and gold says "the best." Also, in some of my mods I use purple for more high-level magic, since purple seems like a weird, arcane color to me. E.g. I like the progression of PfNW (green)->PfMW (blue)->Abs. Immunity (pink). Just throwing out random thoughts though, it's not a knock against what you've already done. I'm excited about this - great work! I'm about top publish some major updates to my mods (including a game-wide 5E spellcasting conversion), which will inevitably lead me to reinstall and start a new game. I'd love to have this included when I reinstall...

@DavidNYC I love the concept. The only thing that gives me pause is the floating orbs... I have about 3 party member with ioun stones right now, and if the same animation denoted combat protections, it might be confusing. But that aside, I love it. I had sort of similar ideas, once - though a different concept. This should be its own mod... seems like a lot of fiddly work to me, which is why I never bothered with such a thing. But you've done the fiddly work! So maybe we should talk about weidu-izing it. EDIT - probably in a different thread, as it is not specific to SRR. (Sorry for having continued off-topic discussion, Bartimaeus)

I know, sorry, your post was well thought-out. It's just a pet peeve of mine. That is quite a different issue from good vs. crappy game design. If you want to design a spell that lets you expend a 9th-level slot to go nova and fire off three 8th level spells instantaneously in the middle of battle... that sounds cool! But for Pete's sake write lore and a spell description that is true to what that spell does. If you describe a spells that stores magical effects and allows them to trigger independently later, based on pre-defined contingent circumstances, that sounds cool too. But now design the software to actually work that way! Contrarily, if you create the first spell, and lazily slap the description for the second spell onto it, well then 20 years later we have to listen to people go "dur, my sorcerer is so awesome because I mastered teh Chain Contingency exploit!" ... That's not immersion, or good world building. What it is, is a missed opportunity to put both of those two spells in the game and let players use them creatively. Because all you do is talk a lot of smack without actually looking at what modders have done. Making wands less spammable is a "nerf," but one that forces players to move past lazy gameplay and engage with other abilities and systems in the game. Limiting the number of enchanted garments you can wear leads players to use their class abilities, giving weight to their choices, rather than just shrouding themselves with all the bling that the game throws at you. Limiting resting injects a new layer of resource management into the game. Modding the Shield of Balduran can change fights against beholders from stupid to interesting challenges (well, to an extent). Et cetera.

EEKeeper is Windows-only, and not maintained in any case. It can be run through WINE, but WINE seems annoying to deal with IMHO. NI works fine on Macs - just have to install Java since it is a Java app. (I'm sticking with Mojave, so not sure about Big Sur, but off the top of my head I don't see why it wouldn't work there... maybe otherss can chime in.) In a Finder window, click the "Go" menu, hold down option, select "Library." Then go into Application Support/Steam/SteamApps/common. The game folders should be there. I make an alias of my game folder and put the alias on my desktop, for easy access.

Nothing against you in particular, but I hate reading crap like this. Games make you act within a particular set of constraints; that is what makes them fun and/or interesting. What if Piranha Plants in Super Mario Brothers didn't hurt you, and someone said "hey wouldn't it be interesting if these could hurt you, if you had to avoid them and time your jumps very precisely? And hey, here's a set of modding tools that could accomplish it!" I think it would be completely inappropriate to respond "how about instead of modding that game that way, you just try not to touch them? There would be no consequences if you mess up, but wouldn't that still accomplish what you want?" Because that would not accomplish anything. The entire point of playing the game is to put yourself up against a set of constraints and consequences. I'm all for self-imposed restrictions of various sorts - party composition, role-playing vs. metagaming, etc. But if someone thinks Chain Contingency should not be able to be insta-cast in the middle of combat, and the options for addressing that concern are 1) just don't do it vs. 2) set the "non-combat" flag in the .SPL file, modding the .SPL file is very much the better solution. Nobody wants to hear "just don't do it." I mean cripes, this is a website devoted to discussion of modding the game. How does "don't bother actually modding that" ever advance the discussion in any meaningful way?? /rant Incidentally, My preferred solution is to set these types of spells to be limited to out-of-combat casting. Not a huge change, just eliminates the cheesiest bit of cheese associated with them. As for limiting which spells you can put in them: this might be possible with a UI hack, but it seems like it would be very complex and prone to failure. You could pretty easily limit the level of the spells that can go into it, though. As for limited the conditions/targeting: it could be possible. The easiest way to do this would be to change Chain Contingency to use the same conditions and targeting as the regular Contingency spell. It could still cast three spells, and higher level spells, as you see fit. This can be done by simply editing the .CRE files themselves. Maybe something like install Tweaks Anthology's "TOB-Style NPCs" which sets their stats to the lowest version; and then manually or through new mod, set their XP values to max out at 500K. My mod changes this entire line of spells into variants of Simulacrum, differentiated by how much magic the clones can use. From the scroll? Sure, you can just set the target of the ability to 5 (self). Probably just set the required value to something extremely high? Seems doable. I remember talking about this a while ago; I think the end result was the Tweaks Anthology component that lets you increase the chance of being woken up by monsters. Not that the monsters are much of a threat, but the constant interruption will prevent you recovering your spells, so it makes more sense to just find the nearest inn or other safe place. I think this is already handled by Item Revisions and/or SCS? Something like, if you attack the undead the protection is cancelled. So it's like a species-specific Sanctuary effect. (Makes a lot more sense to me than the vanilla version.) This is way outside my wheelhouse, and it seems both complicated and in need of serious consideration of consequences. What happens if you take too long? Auto-game-over? Players would probably not like that. Maybe an alternative like, apply a penalty of some sort every couple hours. Just being in a vampire lair, surrounded by all that negative energy, should be harmful. Maybe apply an irresistible level drain every time the player rests? I'm generally in favor of making players complete a dungeon with zero or maybe one rest... but I'm not sure how best to accomplish that within this game engine... A lot of good ideas though, and I'm always in favor of +challenge mods!

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: