subtledoctor

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.)

Dude, it's not the fault of NI. The point is, Imoen's .CRE value has a a null value in the dword at 0x244. In conversation we conflate tend to conflate the ideas of "no kit" and "trueclass." When you play a simple fighter and you do not choose a kit, you have no kit. We say you are a "trueclass fighter." From a player's perspective, there is no difference. Either you have one of the various kits, or you don;t have kit and you are a trueclass. But the game engine has two possible values that can represent someone with no kit: 0x0000 0000, and 0x4000 0000. In regular gameplay this makes no difference. So the .CRE files are coded haphazardly, some have one value and some have the other value. But when you start modding things, the difference can become manifest. Like, I don't precisely remember how it bit me in the ass, but I think it was to do with scripts. If you have a script with a Kit() trigger meant to apply some action to trueclass/unkitted people, the script will work correctly for Nalia but it will fail for Imoen. The solution to solve problems like this, as Kjeron suggested earlier, is to change everyone who has 0x0000 to 0x4000. I mean, that entry is present in BGEE, SoD, BG2EE, and IWDEE. It's quite consistent across multiple patches released at different times with different bug-fixes, so it doesn't seem like an error.

Okay Jarno. Now I'm giving you homework. Go look at IMOEN10.CRE and NALIA10.CRE and look at the value for their kits - the 4-byte dword at offset 0x244. They are both "trueclass" - neither one has a kit in the game. But tell me if you find that their values at 0x244 are the same, or different.

Notably, IIRC that Tweaks component has a bug in its .TRA file, so the description is inaccurate. It’s possible he disabled dual-classing when he thought he was enabling it.

Durn't take away mah exploitz!!1!

That SCS component does basically the same thing as Level 1 NPCs, only difference is one lets you customize NPCs when installing and the other lets you customize NPCs inside the game. I very much expect these will interfere with each other and cause problems; mod interactions can be chaotic, and maybe that's interfering with Dual-to-Kit. I don't think we've seen your weidu.log? Maybe you have other mods that could cause the dual-class to fail. Maybe there is another mod that affects the dual-class UI. If i had to guess I would say the problem with dual-classing is caused by something being wrong with your mod picks and/or install order.

Did you install SCS NPC Customization? I've heard of screwy things with its scripted stuff, like removing 10hp and then they die? (It does the same things as Level 1 NPCs anyway, so best not to install both.) Or maybe L1NPCs does something that interacts poorly with Dual to Kit. One way or another, if you're finding dead bodies on the road then I think there is just something messed up with your game, not necessarily a bug in Dual to Kit.

Only thing that occurs to me is, the game considers both 0x0000 and 0x4000 to be "trueclass." But some game functions and Weidu functions do not work with both. I've had trouble in the past when filtering for trueclass, because most NPC .CRE files are set to 0x4000 but Imoen, uniquely, is set to 0x0000. I had to manually patch her .CRE file to 0x4000 in order for some things to work correctly. Maybe the Dual-to-Kit mod only handles one of those kit values? And mt17's character has the other value?