jmerry

To quote the IESDP: And swap "Maximum" to "Minimum" for the other side. There are a few effects - most commonly damage and HP changes - that roll the dice. Everything else uses these fields to impose a level filter, like the classic Sleep spell.

Yes, that's what I meant. Top-level "Effect" entries on an item are normally equip effects. For example, this item has the "set color" effects that govern its equipped appearance. Then you get the equip-adjacent effects like that opcode 319 effect (judging by the "Redfist Sabre" name, it's probably there so shamans can't use it; shamans have the same class usability flags as druids, so anything one class can use that the other can't has to be done with 319s). Anything there with a target other than "self" or a timing other than mode 2 "when equipped" gets very wonky. For an effect like "this weapon hits someone, and that does something", the effect has to belong to the item's attack ability. That "Melee" ability is what lets you swing the weapon and hit a target for damage; any effects you add to that ability will apply after that damage is dealt. The order of effects can matter sometimes, but all it does intrinsically is set the order in which things are resolved. If it's earlier in the list, it gets dealt with earlier. For example, buff spells typically have an opcode 321 effect for anti-stacking purposes. As the very first thing this spell does, remove all currently ongoing effects of this spell from the target. Then apply a new set of those effects. You cast Armor of Faith last round for 25% resistance to everything - casting a new instance of Armor of Faith will just refresh the duration, not increase that resistance to 50%. What if that op321 effect weren't the first? Then we'd be removing the effects we'd applied just now - completely counterproductive. So order matters when effects interact with other effects in the same bunch. Here, with stuff like color changes and that op319, it doesn't matter. Those would do the same thing in any order.

Ah. Well, that isn't something that you can see based on the effect alone. It's about where the effect is. If you want an effect to apply to whatever a weapon hits, it needs to go on the weapon's attack ability.

Yes, the stuff I linked is about IWD spells, not the OP's list.

More specifically, the dw#copxx scripts are meant to handle clones of PC spellcasters. So, fundamentally, they need to be completely generic and handle all of the spells that the SCS caster AI is willing to cast. That said, the individual ssl blocks that go into them on when to cast each spell do need "does the spell exist" checks for anything beyond the base game's spell list. Without that, you'll get parse errors when building the scripts. And some of the IWD spells are missing those checks. See here: https://www.gibberlings3.net/forums/topic/38434-3517-parse-error-in-component-improved-battle-with-irenicus-in-spellhold/?do=findComment&comment=339605 (Link as of 35.17, but I don't see mention of it in the 35.18 changelog, so it's probably still an issue)

It's tied to the abilities that transform between states, so only the "PnP restrictions" version. The components for two-handed axes, katanas, and bastard swords do not have this problem, because they use opcode 123 to remove the old item instead of charge exhaustion.

It's those dice/level parameters. For most opcodes, including stun, those provide a level-based filter on what creatures it can effect. With the numbers you've got there, only creatures with level ≤ 1 and level ≥ 9 are affected. In other words, none of them. Oh, and regarding the probabilities? Setting both to 100 creates an effect with a 0% chance of happening. That 30/0 is a 31% chance, and changing it to 100/0 would be a 100% chance. It's all about the range between the two numbers (and how it intersects with the range from 0 to 99).

And my tweak collection has a component for that too. Stat restrictions that aren't in the description removed, race/class/kit/alignment restrictions beyond the base item mostly removed. (Mazzy's gear still requires a halfling, Keldorn's sword still requires non-evil) So the item usability thing has multiple third-party solutions, but the actual NPC customization mods rarely seem to catch it.

Other SoD characters affected by this specific issue: - The petrified people at the Coast Way Crossing. - Herod, a minor NPC involved with the petrified people quest. - Senderin, a minor NPC at the Bridgefort. - Merome, Senderin's kid.

So, the original state here - Vessanal has three scripts: - BDVESSAN in the override slot. All quest-related stuff. Should be left alone. - SHOUT in the race slot. - RUNENEMY in the general slot. Fitting for a level 1 INNOCENT with no combat capability. So, looking at this, it's got to be the "Better Calls for Help" component that's causing trouble. And here's the offending block: Level 1 innocents with the SHOUT script in BG1 get the new dw#innhl shout script, placed in the override slot with no check for anything already being there. And there's even a comment explaining why this was done: /* A note on SHOUT in BG1 Basically, it's really dangerous. Nearly a thousand creatures have it, and it's indiscriminately given to hostiles and to innocents. BD hacks around this by using alignment as a de facto SPECIFICS. We handle it in a more principled way by: - mapping lots of the users of SHOUT onto their own bespoke scripts - mapping all the remainder, who are people like city guards and merchants, onto a non-specific-keyed help script with a bespoke shout code (119). - giving 57 as the bespoke Shout shout code - creating a new innocents-only shout, that responds both to 119 and to 57. - setting original SHOUT so that it's harmless in any case if a few residual innocents have it */ That new dw#innhl shout script is the innocents-only script. Nothing wrong with using it, but letting it bump off whatever script is in the override slot is bad. Better to find where SHOUT is and replace that instead.

Sources of that charge-draining effect in the vanilla game: - Magic Golem attack - Nishruu/Hakeashar attack - Spellhaunt attack - Hive Mother antimagic ray There's also one of the SPWM spells, but it doesn't appear to be used; instead, the wild surge table doubles up on the next spell.

OK, that's weird. The Hive Mother ray should drain charges from items like nishruu attacks do ... actually, that capability is already there in vanilla. But protection items don't have charges ... unless a mod introduces them. That looks like the most likely culprit. And looking at the code for it, definitely. That component introduces new abilities with the "vanish when drained" flag to handle transforming between states. The ability creates the new version of the item, and the old item vanishes because of that flag. Unfortunately, attacks that drain item charges - which I believe is limited to hive mother antimagic rays and nishruu/hakeashar attacks in the standard game - will drain those protection items and consequently destroy them. An idea for an alternate implementation that fixes this: rather than using the "vanish when drained" flag on the ability, use an opcode 112 effect to remove the old item. It might get a bit weird if you had two copies of the same ring equipped - the left ring would vanish even if you activated the right ring - but that's not nearly as bad. (And of course, if you do this, you use either a daily recharge ability or a no-charge-needed ability so the charge-draining effect doesn't lock it) Summary: This has nothing to do with SCS, and is entirely an issue with that Tweaks Anthology component. With it in its current form, Hive Mother antimagic rays and nishruu/hakeashar melee attacks destroy protection items.

Since Azuredge has the +3 enchantment level - it can definitely hit iron golems and the like - I take it your component there is about the attack and damage bonus? A nonmagical throwing axe is better than unmodified Azuredge unless either the enemy is undead or the enemy needs magical+ weapons to hit.

This forum? Maybe. This thread? No. I started this thread, and I draw the line at mod bugs. Your report of a potential error in one of the components of the incomplete Fixpack really should have been a separate thread.

Szass Tam should have a MINHP1 ring, which renders him immune to the opcode 13 "kill" effect that vorpal weapons use. Clearly, he's bugged for you, but what does this have to do with the Fixpack (which is all about fixing things that are bugged in the base game)?