subtledoctor

Okay I've made a relatively major update, to v0.9.6. First, the Readme is greatly expanded. Check it out, it has lots of important information, especially about the new stuff. Small stuff: There is now a settings file, "TomeandBlood/qd_TnB_setting.ini." The first use of this file is with the Improved Identify spell: it changes Identify to a 2nd-level spell by default, but you can edit the settings before installing to set Identify to whatever spell level you want. (Maybe you want to keep it at 1st level, etc.) The Revised Invisibility code is slightly changed, in ways you hopefully won't notice, apart from this: "Nondetection" is renamed "Protection from Divination" to better reflect its actual function. The new familiar choice icons are reduced and should hopefully look normal now. Bigger stuff: I have completely rewritten the back-end code for the Arcanist kit, turning it into a series of portable functions that enable 5E-style spellcasting on a per-kit, per-class, or game-wide level. (More about that later.) The Arcanist generally works more reliably, and will not require in-game "initialization" of its abilities, and will not have its memorization slots or casting slots messed up on leaving and re-joining the party. When you start the game just wait a few seconds, you will see your "cast spell" button go dark and then be reenabled. This will happen every time you rest, as well. Further, instead of having casting slots controlled by static code, the Arcanist's casting slots are determined by a normal-looking spell table, found at "TomeandBlood/data/arcanist/d5cstarc.2da." By default this table roughly matches a Dragon Disciple's casting slots, but you can modify the table before installing the mod, and the kit's spellcasting slots will follow suit. The same system governs the spellcasting slots for multiclass sorcerers, but they rely on the standard MXSPLSRC.2da table. So Multi Sorcerers can now have their casting slots match vanilla sorcerers - AS LONG AS and changes to that table get made BEFORE you install multiclass sorcerers. I know it's a pain to install a little bit of Tweaks Anthology before TnB and the rest of Tweaks Anthology afterward... but for best results, that is necessary. The "Make Bonus Spell Slot Items Work with Arcanist/Multi Sorcerers" component will now reduce all bonuses from each item to +1; so for example the BG2 Ring of Acuity will only give +1 2nd-level slot instead of +2. There shouldn't be many such changes, and they are minor; in return, these items will be consistent across all kinds of casters, whether traditional mages and sorcerers or multiclass sorcerers or new 5E-style casters like the Arcanist. The two "double spell slot" items I'm aware of - the Evermemory ring and IWDEE's Kontik's Ring - will have that effect replaced by an item ability that, once per day, restores all spell slots of the relevant spell levels. This ability, too, works consistently for all of these different kinds of casters.

Smallish update to v5.29: A bit of text updates, changing the "Fencing" style to "Single-Handed Style" since the former was a bit polarizing. And the ability score-based bonus spells are updated opn the back-end, to conform with the latest systems in Tome & Blood and Might & Guile.

All by itself? Maybe 20-30 minutes. With a hundred other mods installed beforehand? Could be upwards of 2 hours. Which is quick - back in the days of v28 and earlier, it was more like 6 hours. It’s no less true for time than money, you get what you pay for.

You could just remove all of the effects from ND, then load up a save and see what happens... that might suss out the issue.

And they are targetable with II but no ND? My gut says it's something to do with opcode 69, if that's the case. (Though I've been wrong before. This game engine is wacky.) Which would mean this problem is already solved by my mod. (Though, it could create other issues, like Nondetection becoming too strong... at least against priests. Their only counter would seem to be Faerie Fire. ) What happens in SRR with someone has Nondetection and you cast Invisibility Purge? EDIT - it might also be something wacky about the "invisibility detection by script" effect. IIRC this is generally applied in-game to enemies, and those enemies will generally make physical attacks. Maybe this only supports scripted targeting for physical attacks? Anyone recall whether there are enemies with scripted invisibility detection who cast spells? Maybe some fiends? Will they successfully target a player with II + ND?

With vanilla spells, you simply cannot target an enemy who has II + ND. (Heck, you can;t target an enemy who only has II - ND doesn't even factor into it.) So I'm not clear on what you are comparing here. I have definitely had occasions when I turned on player AI by mistake, and one of my characters started attacking an invisible enemy. So invisible enemies can definitely be targeted with SR installed. (In fact that is partly what caused me to go out and make my own invisibility tweak mod.) I don't know whether that enemy had Nondetection cast... probably not. So maybe adding Nondetection into the mix can screw with player scripts? But if so, it sounds like it is something, as you say, "at the opcode level." I can't see how SR could be causing it; SR doesn't really change Nondetection. The only thing SR does to Nondetection is add an opcode 282 effect, setting the value to 3. I have no idea what that is for - I assume it is something to do with Detectable Spells?

I should mention, if there is "going on at the opcode level preventing scripts from appropriately targeting enemies" with ND and II, then it is hardly an issue with SR. If that's really the case, then I would guess it is something hard-coded about Nondetection. The way the game treats invisibility and nondetection has always been screwy. If that's the case, then you might want to look at what I've done with Tome & Blood. It changes Nondetection into "Protection from Divinations" - closer to a true replacement for SI:Div. It does this by adding an opcode 205 effect, blocking spells with the DIVINATIONATTACK sectype. (It also adopts SR's use of opcode 193 for See Invisible and True Seeing, so a caster with True Seeing cannot remove the protected person's invisibility (or Mirror Image etc.), but can still see and target that person. With opcode 205 in place, I suppose there is no need for the vanilla "nondetection" opcode 69. So the lastest master of TnB, just uploaded now but not yet set as a "release," eliminates the opcode 69 effect. If opcode 69 was indeed interfering with player scripts, then maybe they will work better with the TnB tweaks.

Ah, well if you're just talking about player scripts then I confess I don't use those so I don't really pay attention. I've never found them good enough to make me want to cede control to a script (especially for mages - for fighters or thieves or even clerics, it's not as big a deal). But, for the sake of argument: There are only so many spellstates you can add to the game; talking about applying one for each spell like Mage Armor is a start down a path toward infeasibility. Maybe something like a broad "AC buff" category, which could include Armor, Shield, Blur, Ghost Armor, Spirit Armor, etc. If the script finds that you are without any buffs, then it can check what you have memorized and apply something. Some important defensive spells, like Stoneskin, do already apply a detectable state. PfMW might or might not, I forget. As to Mage Armor in particular, I'll not that it has a long casting time and an all-day duration, and is thus clearly meant to be applied before combat starts. If my mage loses his buffs to a Breach and the script starts casting Mage Armor, I would be pretty annoyed at that script. That's not a spell I ever want to cast mid-combat. I still don't really understand what the issue is with Nondetection or Improved Invisibility. What is the behavior you are seeing that you find objectionable? SR's See Invisible and True Seeing apply opcode 193 "invisibility detection by script," which makes anyone - anyone - a valid target for spells or attacks, regardless of invisibility or non-detectibility. If you cast True Seeing and your mage script isn't targeting an invisible enemy, then my guess would be that the problem is in the player script. Player scripts don't account for the player having opcode 193 - it's generally reserved for a select few enemies and scripted cut-scenes. So the player scripts might have conditional stuff like, "if target is not invisible, then cast spell A." With SR installed, that won't work well. The answer is to remove such targeting conditions from the scripts. (Letting spells target improved invisible enemies is not a good solution, because then they could be targeted even if you don't cast True Seeing, and then really what is the point of True Seeing?)

The script only works for Player1... I shudder to think what would be necessary to make it universal. Of course, sure you can code a whole new set of game rules into baldur.bcs. Lots of old mods did that sort of thing once upon a time. The result was... glitchy. I've developed an aversion to relying on bcs for basic game effects that the player expects to be reliable. My method, while complicated to devise, is rock-fracking-solid in actual gameplay.

Mage Armor has a sectype, which SCS knows how to handle. As a combat protection, it can be breached or dispelled. SCS is quite adept at doing such thing, in my experience. Dispelling Screen has a custom sectype, which I think SCS knows about... but even if not, it doesn't really matter. Dispelling Screen blocks one instance of Breach or Dispel Magic; to remove that protection you must cast... Breach or Dispel Magic. Thing thing it protects from is the thing that dispels it; so even if the AI is dumb as a rock and casts Dispel Magic at your Dispelling Screen, it is actually doing precisely what a smart AI would do in the same circumstance.

But then the bonus is applied to anyone carrying a one-handed weapon, regardless of whether they are specialized, proficient, or completely unskilled with the style. Which is contrary to the clearly stated desire of the OP. What were you thinking? (Ah, right: proposing uninspired, simplistic solutions that put the game on autopilot, rather than adding meaningful weight to the choices that players can make... typical.)

If you just want a passive bonus whenever you are holding a one-handed weapon, then yeah it would be trivially simple. If it's just a matter of a relative advantage vs. larger weapons and shields, then absolute easiest thing to do would be to apply a while-equipped casting speed penalty to 2-hand weapons and shields. Balance-wise, it would be the same. But if the goal is to make this a feature of specializing in the Single-Weapon Style proficiency (which is what I took from the OP), and you want it to kick in quickly and reliably when using various different methods to equip weapons, and you want it to be nullified when equipping a shield or an off-hand weapon and then kick in quickly and reliably again when you unequip that shield or off-hand weapon... then it gets more complex.

In my game (heavily modded, but I think this would be the same in any SCS install), the effects of wand13.itm are preceded bya 177 effect calling DW#CLDKI.EFF, which summons DW#CLDKI.CRE, which runs DW#CLDKI.BCS, which has a Shout(404) action. I think it's designed to get AI creatures to run out of the Cloudkill AoE so they don't stand around dying while the player twiddles their thumbs.

Can also do (0 - 2)

Don’t use new patches unless/until they are finalized and confirmed to be working with the mods you want to use.

@argent77 put out TotLM-in-BG2EE in the space of what seemed like a short time. (Unless it was worked on for longer than I realized.) Why? I'll guess it has to do with the lack of scope creep, as you say. Maybe following in those footsteps is a reasonable plan? If I just had a basic step-by-step framework for how that one was done, I could wrap my head around what kind of project it would be to port over the other two IWD adventures. (Probably start with just HoW, since it really is a self-contained thing.) But as of right now, I have no idea.

Thanks!

It's possible in the EEs... see here, between line 446 and line 751. You could squeeze a casting speed bonus for [spec in SWS and using 1-hand weapon] into that. But, as you can see from that code, it's rather complicated.

At this point I’d be much more interested in discrete adventures - add the IWD main quest and HoW to the BG games in precisely the same way Argent77 added TotLM. Put Hjolder in the Druid Grove after Faldorn’s defeat, and let him Wnd Walk me to the North! IWD, HoW, and TotLM can all be separate adventures, no need for them to hang together as one massive campaign. (For that, we can already just play IWDEE.) Alas, I’ve glanced at the TotLM-in-BG2EE code, and I can’t make heads or tails of it. As for this project, it kind of seems like it got lost in the attempt to convert to a 3E ruleset for IWD2 inclusion. And even there, we also have the separate “IWD2EE” project, so this again seems redundant...

I assume some of that stuff is just hard-coded to the damage type...

I notice that some functions can get you an output variable: LAF RES_NUM_OF_SPELL_NAME STR_VAR spell_name = ~WIZARD_MAGIC_MISSILE~ RET spell_res END PRINT ~Magic Missile is %spell_res%.spl~ // "Magic Missile is SPWI112.spl" How do I write a function with that kind of "RET" output? I currently have this: DEFINE_PATCH_FUNCTION find_zclons_spell STR_VAR spell_to_find = ~~ BEGIN // PATCH function run inside new spell to find and use spell entries from d5zclons.2da PATCH_IF (FILE_EXISTS_IN_GAME ~d5zclons.2da~) BEGIN INNER_ACTION BEGIN COPY_EXISTING ~d5zclons.2da~ ~override~ COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW ~r2en_zclons~ cols FOR (row = 0; row < r2en_zclons; ++row) BEGIN READ_2DA_ENTRY_FORMER ~r2en_zclons~ row 0 z_ind READ_2DA_ENTRY_FORMER ~r2en_zclons~ row 1 mem_spell READ_2DA_ENTRY_FORMER ~r2en_zclons~ row 2 cast_spell READ_2DA_ENTRY_FORMER ~r2en_zclons~ row 3 spell_type READ_2DA_ENTRY_FORMER ~r2en_zclons~ row 4 spell_proc PATCH_IF (~%mem_spell%~ STRING_EQUAL_CASE ~%sought_spell%~) BEGIN) SET this_spell_ind = %z_ind% SPRINT spell_to_cast ~%cast_spell%~ SPRINT type_of_spell ~%spell_type%~ END END BUT_ONLY END END END // end function I want to use it more or less like this: COPY ~might_and_guile/lib/d5_base.spl~ ~override/d5zbard.spl~ LPF ADD_SPELL_EFFECT INT_VAR opcode = 171 target = 1 timing = 9 STR_VAR resource = ~d5bp102~ END LPF find_zclons_spell STR_VAR spell_to_find = ~d5bp102~ RET this_spell_ind END LPF ADD_SPELL_EFFECT INT_VAR opcode = 206 target = 1 parameter1 = (0 - 1) timing = 9 STR_VAR resource = EVAL ~d5zb%this_spell_ind%~ END LPF ADD_SPELL_EFFECT INT_VAR opcode = 171 target = 1 timing = 9 STR_VAR resource = ~d5bw219~ END LPF find_zclons_spell STR_VAR spell_to_find = ~d5bw219~ RET this_spell_ind END LPF ADD_SPELL_EFFECT INT_VAR opcode = 206 target = 1 parameter1 = (0 - 1) timing = 9 STR_VAR resource = EVAL ~d5zb%this_spell_ind%~ END

There is an ADD_SPELL_HEADER function floating around... you need it if you use the CREATE function to create new spells, since CREATE makes a spell with no ability headers. (Which is weird and annoying.) If you really want to operate 100% by Weidu, you can get comfortable with that. I think Aquadrizzt, for example, likes to operate entirely by code, and create files on the fly. There is also Camdawg's EXTEND-O-MATIC thing, which I think makes new ability headers with progressing min levels. Not what was asked for, but maybe worth looking at the code. But in general I don't like to mess with ability headers, other than to ALTER_SPELL_HEADER them. I don't use CREATE for spells - I pack a blank .SPL file with a single ability header, and I add effects to the header with code. In my new 5E casting conversion, I manually made a .SPL with 40 blank ability headers, and I clone the file and add effects to each header to simulate with might normally be in a CLAB table. If I need a spell with between 2 and 39 headers, I'll just make the spell manually in NI and simply copy it with Weidu, just like SR. Using code to patch stuff is convenient and make adjusting things a LOT easier, but I'm not religious about it. (Sidebar: there's a reason SR sets so many spell durations to 1/2/5/10 turns. Do I really care whether my Mirror Image lasts 84 seconds or 90 seconds? Making that stuff level-dependent is a TON of extra work, for very little gain.)

For stuff like that it's simpler, and probably just as effective, to use COPY_EXISTING ~clabrn04.2da~ ~override~ REPLACE_TEXTUALLY ~GA_SPCL311~ ~GA_SPCLCBM~ IF_EXISTS BUT_ONLY But as an answer to your original question, since it could be useful in other places, you need to iterate over both rows and columns in order to read every entry. COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW rows cols FOR (row = 0; row < rows; ++row) BEGIN FOR (col = 1; col < cols; ++col) BEGIN READ_2DA_ENTRY_FORMER rows row col ~spell~ PATCH_IF ~%spell%~ STRING_EQUAL_CASE ~GA_SPCL311~ BEGIN do stuff END END END Also you use the same variable "cols" for both the total number of columns, and your iterating column number in the FOR clause. That's gonna screw things up. As you see I use the singular "col" for the latter variable. Finally: not that this is a bit fragile. If you try to iterate through 40 columns but some modder has added a row with only 39 entries, then the operation will fail. CLAB tables, in particular, tend to get pretty disorderly in games with a bunch of mods installed. There's things you can do to firm up the operation, which is why READ_2DA_* functions have that "required column count" field... but that can still fail because an entry you want to read and modify might be in a row that doesn't get handled. Most 2da tables make nice rectangles and don't get screwed up. But CLAB tables are quite prone to becoming disorganized, and so I avoid using READ_2DA_ENTRY on them when I can.

Neither of those actually does what the original "defense adjustment" says. TB#Tweaks gives a straight bonus to all saves vs. Spells, which covers... a LOT of spells. Like, Fireball, Flesh to Stone, etc. All sorts of stuff that is not included in the 2E "Magical Defense Adjustment." Scales of Balance also gives a bonus to saves vs. spells, but for high INT scores. With SoB Wisdom involves something like willpower, so a high WIS score gives you a bonus to saves vs Death and Petrification/Polymorph. Scales of Balance also has a component that rebalances saving throws, reserving the save vs Spells for Enchantments and Illusions; it changes stuff like Fireball to use a save vs. Breath Weapon, and stuff like Flesh to Stone and Disintegration to use a save vs. Petrify/Polymorph. So your best bet to most accurately model the original Magic Defense Adjustment is to Combine the SoB rebalanced saving throws and the TB#Tweaks 3E-style Wisdom. (Although... not sure how TB#Tweaks makes that work. It was made a long time ago before stuff like dynamic arbitrary stat bonuses were really possible. Nothing against that mod - I still use parts of it myself! - but YMMV as far as how it actually works in-game.)

Huh, so like, maybe the SCS mage casts PfMW plus Dispelling Screen, with the expectation that he will be protected from being Breached? I see the point, but I suspect it would be a pretty rare event. From the point of view of SCS scripts, 1) I think DavidW leans toward using Deflections to protect from Breach, since he designed his own version of the mage duel system specifically preventing Breach from bypassing spell protections, and SR shares that design. Plus, 2) for that same 5th-level slot, Spell Delfection is a far superior choice with which to block Breach. Spell Deflection will also block stuff like Disintegrate, Feeblemind, and (with the SR option) Skull Trap and Sunfire. The only thing it doesn't do better than Dispelling Screen is, block Dispel Magic. And if DavidW codes the scripts with some variability and allows them to make slightly suboptimal choices... well, maybe the mage isn't very smart and left himself open to being breached. Frankly, whether Breach goes through or not, I probably wouldn't bother with the Breach. If the enemy has no spell protections up it's easier to just fry him with Lightning Bolts... I don't think it ultimately makes that much difference, and comes down to your preferred house rule. If I have the time I'll probably add an option to my mod to cover whether Breach should be blocked by Dispelling Screen or not. Yeah, I didn't want to mess with 206/321 to prevent stacking and risk AI scripts handling it suboptimally, so I figured better to always stack! For purposes of this project it's no problem to assume no stacking and use the different color animations. For my own mod interacting with this project, I'll figure out later how best to handle it. (Maybe just let the colors mix, maybe find a way for the higher-level spells to suppress the animations of the lesser spells... we'll see.)