DavidW

You have a remarkable talent for making up claims about the game and speaking them with authority. Lots of liches in the unmodded game, including lich01, have Improved Invisibility memorized, and pretty much every lich script in the unmodded game casts protective spells of 5th level or lower. And the opcode in the lich protective ring is the same one used in Minor Globe of Invulnerability, which the designers obviously knew did not protect against your own spells. I don't see much point engaging further with someone who is just making stuff up.

No news, sorry - it requires me to have a sustained window of time to check it out, and they turn up unreliably. I'll let you know.

I basically agree (and the mod readme agrees) - though since the difficulty slider was introduced, I think a new player could play on Basic without too much trouble and ramp the difficulty up as and when they wanted to.

Then take it down with Pierce Shield, Warding Whip or similar. I don't know how long it's been since I used projected images in SCS, but it must be at least five years. (They're too much hassle.) And even when I did, they didn't get Spell Triggers or similar, so you can kill them before they get their defenses up. There is limited value in engaging with you if you're just making stuff up about the mod. Tell it to Bioware, or to Gary Gygax. Fixing oddities and imbalances in the vanilla spell system isn't SCS's remit, except insofar as I think I have to tweak it to make spell combat viable. It is unsurprising that in a game based on the AD&D rule system, different party mixes are going to find things variably difficult. SCS is, yes, a lot harder if you don't have at least a couple of wizards in the party. That's just the nature of the rule system. To a large extent it's true in the vanilla game too. (That said, it's been solo-no-reloaded by people playing melee classes, so it's clearly not impossible even then.) Nonsense. The game is obviously and explicitly designed to be played by whatever PC class you like. If that wasn't obvious enough from the explicit way the game is presented, the presence of content specifically written for each character class should drive the point home.

Don't worry about it, you were fine. You have a very melee-focussed party, which is challenging in SCS - Aerie is your only wizard, and her multiclassing starts to impose a painful restriction on spell numbers by ToB. You probably want to be using her wizard spells mostly for countering enemy spells. If you're playing SCS on its hardest setting, though, and it's your first playthrough of BG2, I can see why you're finding it hard work. I normally assume people playing at that difficulty have played the game multiple times before.

The basic logic is the same as it's been for over a decade, and isn't far from the implied logic in the vanilla game: - spells like Ruby Ray, Warding Whip etc to drop spell protections - True Seeing, Oracle or a thief's Detect Illusion to remove improved invisibility - Breach to remove PMW (Or else bypass with area effect spells, depending on what other defenses are in play and what level you are.) Wizards have multi-layered protections and you have to do multiple things to drop them. It's totally fine not to like that style of play, but I'm unlikely to alter it now, when SCS has been using roughly this format for 10+ years and remains pretty popular. (Of course, if you turn the difficulty of the mage component down to Basic, it gets simpler.)

That doesn't match my experience or that of quite a lot of people who have given feedback. But sure, if it's your experience, probably don't play SCS or else play on a lower difficulty setting.

No need to be sorry! I don't mind at all (and I'm really glad you're interested in the code), I just wanted to flag that I wasn't always going to respond. I'll probably go back through this thread next time I do a proper update of the library (thouh I'm a bit cautious modifying the existing code too much even when it seems logical, because it's being used all over SCS and you never know when surprise problems will turn up.)

Thanks for the feedback. Pretty much every protective spell in the BG2 ruleset has a counter - Ruby Ray of Reversal for Spell Turning, True Seeing for Improved Invisibility, etc. sounds as if you haven’t tried to use any of them - that’s entirely up to you, the move-and-countermove aspect of the spell system isn’t for everyone, but if so you probably shouldn’t use tactical mods in that spell system (or should turn the difficulty way down, at least for the mage components). I’m not sure what ‘way too long’ means really, but I’m pretty sure the mod is up-front about install times in the readme. (But I’ll check.) There is an unavoidable trade off between install time and complexity/responsiveness to other mods. I’m not going to engage with the technical bug reports for the reason Jastey gives (though I’d be interested in specific examples of the text bugs if you have some).

I think I’m going to use this question to say that I’m probably not going to answer much more, unless it’s an actual bug or it catches my interest for some reason. It’s too time-consuming and goes against my ‘this is as-is, I don’t support it’ intention.

But I don’t want the string ‘scsroot’ replaced by ‘stratagems’. I want the string ‘%scsroot%’ replaced.

My experience from various adventures optimizing SCS scripts (all of this is from memory and from some while ago): - I think OR() blocks evaluate from bottom to top, stopping when they reach a valid condition; I also think they're relatively slow; avoid them if possible. - Checking globals is very quick. If there is a global in your check, check it first. - Scripts are evaluated 30 times per second. If you are doing something complicated that doesn't need to be checked 30 times per second, see if you can slow it down. E.g., use a Delay(), or set a timer to reset every six seconds and put !GlobalTimerNotExpired at the start of your block. - most importantly, don't worry about it unless you are doing something very complicated indeed. The BG2 engine evaluates scripts very fast; the BGEE engine even more so. SCS scripts are often 10,000 lines long or more, and even so I quite rarely have to worry about optimisation. In normal circumstances, don't worry about this preemptively - wait till you see actual slowdowns.

Reflecting on this, and on the need for something to be iterated across multiple mods, I might be inclined to do something simpler. There are four lots of NPC orderings, yes, with 15 NPCs in each? Insert the new NPC transition at the top of the first one, the bottom of the second, at position 5 of the third, and position 10 of the fourth. That's enough randomness to achieve what you want, I think. The idea isn't to make sure that each NPC is equally likely to be selected, irrespective of party mix (the original script doesn't do that for the original NPCs) - it's just to mix it up a bit so that mod-added NPCs aren't guaranteed to be first or last, and so that the order isn't predictable. I think that suggestion will do it fine, and is (relatively) easy to implement.

Pretty sure it’s correct.

I meant something more elementary: two spells when I’m budgeting for one.

Also, it would have led to illegal uses of Spell Trigger.

No, SCS won’t detect SPWI590 (it’s hard coded to avoid all the secondary spells for Spell Immunity; probably I ought to check hidespl instead). Incidentally, as of v32 I don’t use Spell Immunity in contingencies/triggers on SR installs.

No, it should be fine.

You could simulate adding an entry in the middle by adding it at the end but with a bunch of ~OR(2)!Global("BD_Saved_[NPC]",bd4500",0)!IsValidForPartyDialogue([NPC])~ added. Messy, though.

Yes, SCS dynamically patches the underlying string (that saves updating the scroll separately). It works out the patch automatically, and in this case the automatic code is making a mistake. It notices that Dispelling Screen (SPWI510) has secondary type SPELLPROTECTION, and so would be brought down by Spell Thrust. And it's right, in a sense! - but it doesn't realize that SPWI510 only persists for an instant in any case, since it's only job is to cast a secondary spell, SPWI510D. Given how much it uses secondary spells, I should probably leave it to SR to make sure its spell descriptions are accurate, and only apply this patch on non-SR installs. (I wrote it mostly with the IWD spell system changes in mind.)

It would help if I can’t reproduce the bug on clean SCS and can see a way it could be compatibility-related, but at the moment I think that’s unlikely and I’d rather not waste people’s time providing things I don’t need.

Actually I don’t need the WEIDU log yet. It’s probably internal to SCS. There’s no global shift that makes everything handle LOS correctly; it’s fight-by-fight. I’ll look at those examples when I have the chance. Are there others?

Looks good. Enjoy!

I have it set to 75 rather than to 100 by default because hitpoint_percentage determines where a creature's hp lie in the range minimum-to-maximum, and my default choice is to put them about 3/4 of the way along (higher than the 50% you'd expect from random die rolls, but short of being maxed out). That's an SCS design choice (SFO isn't always careful about separating out SCS design choices from tool functionality). The ini value should probably be included (my current local codebase sounds a warning if a nonexistent ini is checked, but that's not backported to SCS yet). I don't remember why I don't launch it in CRE_postbuild. Possibly because hitpoint spread is an active design choice; possibly just by mistake. Like I say, it's not code I use. Not initialising it is sloppy (in my ideal world, WEIDU would fail or at least sound a warning if you call a function with arguments it doesn't have) but I think harmless.

I can't argue with that. Looking more carefully, the first 8 bits of the EFF 2.0 format are left out when it's used internally to a CRE file. So although IESDP lists Power as 0x18, it's 0x10 on a CRE file. I obviously remembered this when I originally coded this section, but forgot it at some later stage when I added that entry. Thanks for catching it.