DavidW

Incidentally (apologies for double posting) as regards Skull Trap vs. Fireball for enemy AI, I don't use Skull Trap except for necromancers. Purely mechanically, invokers and conjurers ought to be using it instead of Fireball, but they don't. At least as of v32, I try quite hard to be a bit thematic as regards who uses which spells, even at some cost in tactical efficacy.

1 hour ago, Bartimaeus said:

@DavidW, any insight into what SCS enemies tend to put in sequencers/chain contingencies?

Look in stratagems/caster_shared/triggers. All the SCS contingencies/triggers/etc are listed there, in a fairly human-readable format. I probably don't pay enough attention to range. 

24 minutes ago, subtledoctor said:

Which occurs because the AI is using the spell as a dumb "better Fireball" instead of as a trap.  But whatever.

If you think it is viable for Infinity Engine AI to use Skull Trap as a trap rather than as a fireball, I would really, really like to see your code. (I'm serious - I'm always happy to learn, and lots has improved in scripting since EE came along. But in general it is really difficult for enemy scripting to show any signs of spatial awareness.)

24 minutes ago, subtledoctor said:

if SCS puts three Vitriolic Spheres into a Spell Sequencer

Guilty as charged. Hey, it's a legal choice!

1 hour ago, Bartimaeus said:

I am not too concerned about the summonables since they're usually summoned at self by the AI anyways (...I think?)

If you're thinking of SCS, then mostly not, actually (I'm not sure about vanilla). Summons are mostly offensive weapons, it makes sense to summon them near squishy enemies.

Sure... but that's from your starting point. From my starting point, I don't see any reason why liches should be immune to L1-L5 buffing spells, and no in-game evidence that the designers thought they should either. So - absent any good argument to the contrary - I'm going to carry on using them in SCS.

Prebuffing: no, ApplySpell() doesn't require the spell to be memorized. But the idea of prebuffing is to simulate spells cast before battle. SCS actually checks if they're memorised and deletes them before prebuffing, but the vanilla game doesn't.

On the broader point: we have different starting points. Yours (I think) is something like: of course liches must be immune to L1-5 self-buffing, because they're immune to L1-5 offensive spells. OK, there might be specific exceptions, but we have to justify them on their merits. Use of a L1-5 prebuff in a vanilla script is, at most, evidence that that particular spell is allowed.

Mine is: there's no obvious reason to think liches are immune to self-buffing spells of L1-5 in the first place. Yes, they're immune to L1-5 attack spells, but there's lots of precedent in the game for protection from hostile spells that doesn't extend to friendly spells of the same type: think Globe of Invulnerability; think Spell Immunity. The L1-5 immunity isn't traceable to anything about liches in AD&D core rules, so there's no origin to find there, and the opcode is quite specifically set up to apply only to spell protections. I guess, though, maybe that's what the designers had in mind - if so, they'll refrain from using self-buffing L1-5 spells in lich scripts. Let's check...oh look, they don't. OK, the original idea looks right: liches can use L1-5 buffing spells just fine.

Vongoethe's Blur is in a Minor Sequencer. (The relevant level for your theory is presumably the level of the spell, not of the sequencer, but even if not: Minor Sequencer is fourth level.) The various ApplySpells are just how vanilla BG2 does prebuffing. And some late-game enemies (Vongoethe, for instance) do most of their vanilla-scripted casting through ForceCast as a (somewhat cheap) way to make the battles more challenging, so their spell list isn't informative of their actual spells.

Even if those don't count (and there's no reason they shouldn't count) there are plenty of examples of conventionally-memorized, conventionally-cast L1-5 spells on the list I gave you: most uses of Vocalize and Shadow Door, for instance.

I'm not going to bother with this at length, but in brief:

• Your original argument was that liches can't and don't use L1-5 self-buffing spells because they are immune to L1-5 spells. 
• That argument can be refuted by giving examples of L1-5 self-buffing spells that vanilla liches use. If they use some L1-5 self-buffing spells, it's false that they can't and don't use L1-5 self-buffing spells.
• There are lots of examples of such spells. The vanilla lich01.cre is scripted to use Vocalize (L2), Stoneskin (L4) and Shadow Door (L5).The lich in the Crooked Crane uses Mirror Image, Stoneskin (L4), Protection from Fire (L3), Fire Shield (L4), and Vocalize (L2). Vongoethe uses Shadow Door (L5), Mirror Image (L2), Blur (L2), and Stoneskin (L4). Azamantes uses Stoneskin (L4), Mirror Image (L2), Protection from Fire (L3), Vocalize (L2), Protection from Evil (L1). And so on. (Note that Vongoethe and Azamantes have bespoke scripts, so in those cases someone has intentionally scripted a lich, specifically, to use those spells.)
• Therefore liches can buff fine with L1-5 spells. 

There is no residual argument as to why any particular L1-5 spells that liches don't use, they can't use.

No, definitely not.

Try it and find out...

You have replaced all line breaks with spaces, but there is a line break in the line you are matching on. 

Yes, I can see how that could come about. (And my IWD DS testing is mostly with SCS's own version of the IWD spells, and mostly on EE.) I agree that matching oBG2 usage to the EE versions of IWD spells is probably best.

Ok, that makes sense (and sounds vaguely familiar, actually.)

8 minutes ago, Bartimaeus said:

Additionally, creating a backup of dialog.tlk for every component that adds or modifies a string would probably add somewhere between 5 and 10 GB for most non-minimalistic mod installs. That would be a bit annoying for harmless strings.

It's not quite that bad - the uninstaller doesn't just back up the whole of dialog.tlk. It's about 900kB for a SET_STRING component, I think. But agreed, there's no point doing that unless you actually are modifying an in-game string. (I do this on occasion - it's a convenient way to change a string that's multiply referenced, like a spell or class description.)

ds.tph contains the actual detectable_spells function and its helper functions, but also the inlined data that the function uses (so that we can distribute a single file). In this version of DS, that data comes in a bunch of tables - for instance:

- the table in lines 63-147 is spells for which DS clones the portrait (142) effect block (to get durations etc) and sets the appropriate stat to 1. (spells in column 1, stat in column 2). These should work on SR without changes.

- the table in lines 152-209 is spells for which DS clones the portrait effect block and sets the appropriate stat to some other number. (Spells in column 1, stat in column 2, value in column 3.) Again these should work fine on SR.

- the table in lines 223-242 is spells where cloning the portrait effect block doesn't work and we need to clone another effect block. (Spells in column 1, stat in column 2,  opcode to clone in column 4). These are the main ones where I suspect DS may struggle with SR. 

That's just how WEIDU works. If you add a string to dialog.tlk it stays there permanently, even if you uninstall the mod. If you install a new "Swrod of Awesomeenss" and set the name string using SAY, and the first unused string in dialog.tlk is 104,011, WEIDU sets string 104,011 to "Swrod of Awesomeenss" and then sets the name field to 104,011. If you uninstall the mod, the new item file disappears but string 104,011 is still there. If you then correct your spelling and reinstall the 'Sword of Awesomeness', WEIDU will set string 104,012 to "Sword of Awesomeness" and then set the name field to 104,012. String 104,011 is still there, but since no item's name field is set to 104,011, you won't see it in-game.

(As for why it works that way, I think it made WEIDU's backup system easier back in the early days of WEIDU modding, because it meant it didn't need to back up dialog.tlk, and unused strings in dialog.tlk are harmless. )

To be fair, Jarno was making a claim about liches in the vanilla game (originally the claim was that liches don't use self-buffing spells of 5th level or below because they are immune to them, which is demonstrably false, but I lost track of just what it mutated into. Possibly the claim that they don't use Improved Invisibility specifically, which might be true, though many have it memorised and theoretically it shows up in-game if you Control them. They use Shadow Door (L5) instead.

On 8/14/2020 at 12:51 PM, InKal said:

also I have general observation. I observed, a long ago actually, that there is a tendency or whats the word? that if there is something wrong with their game, peeps will kinda automatically blame SCS. Dunno why or how but it kinda works like that: bam! crash or whatever = SCS!! fault!! I know it is, coz my feelings telling me, itz all about my feelz....

I have noticed that too...

[EDIT 8/17/2020: split this discussion off from the 'Jarno Confusions' thread.

Correct. Theoretically that function call is trying to tell subsequently-installed mods (e.g. SCS) that SR has changed a spell so that DS needs to respond to it differently. But it was never fully and consistently used and is now defunct.

That said, there probably still are issues in how DS reacts to SR spell changes - it's never been quite a 100% consistent match, I think largely because DS wasn't really in Demi's comfort zone (reasonably enough). The vast majority of DS stats clone the portrait icon in the spell, which presumably is pretty stable between SR and the vanilla spell system, but there are exceptions - see DS lines 223-242. 

I should have a look myself at some point but I'm afraid it's not a priority. If someone else feels like it (e.g., go through the spells on lines 223-242 on an SR install and see if they're working) I might be willing to help out coding the changes. (It should be quite easy to do the way DS is currently coded.)

Amusing that I haven't noticed that in fourteen years!

(I would have caught it instantly if I'd coded it any time recently, but this is code from long ago.)

I suppose I should ask: is it actively good that Icharyd dispels defenses? My inclination is not, but sometimes accidents lead to serendipitous results, and if people like it I'll keep it.)

Get rid of the backslashes in the second (replacement) string. They're there to indicated that [ and ] are being quoted directly and not used as special characters, but you don't need to do that in the replacement string because it can't contain special characters anyway.

Quick observations:

1) Icharyd is sensitive to the difficulty slider. (It's not documented for some reason). On Improved (or Basic), he doesn't get his hit points restored and you don't get struck by lightning. So the quick way to tone the fight down is just to move the slider for that battle.

2) It's not actually intentional for him to dispel your spells. I think that must be a side effect of my making it dark: it gets implemented by moving the game timer forward. I'll mark that up as a bug.

3) While he does have to be killed to get at the ruins, he's only there in the first place if you install Improved Ulcaster, and that component only does two things: improve Icharyd and improve the Vampiric wolf. So I don't think it's a problem per se that you have to fight him to get in. (Contrast Kahrk, who's affected by one of the core 'improved AI' components, rather than being a tactical challenge.)

4) Icharyd has been essentially unchanged since the release of SCS back in 2006(!) and so I'm reluctant to change him now, especially as feedback has mostly been positive. (But I am inclined to fix the debuffing since it was never intentional, and that may address your concern in any case.)

5) I'm very happy to hear that about stability. That seems to have been consistent feedback about v33 (and to a large extent about v32, putting aside the problems with the NPC customization component.)

No, it looks completely different. Have a look at bgee.lua (with or without SCS installed) and you'll see how hotkey spells are listed.

SCS just adds the keybindings to bgee.lua. I'll confess freely that I'm not 100% sure how all this works, but it seems functional.

1 hour ago, polytope said:

I generally design my own mods with a view toward retrocompatability with SCS (among others, like Rogue Rebalancing and aTweaks), the only scripting error I could imagine this one creating is that if the option to make 7th circle and higher spells undispellable is used there are potentially times when enemies will waste their round throwing a RM at a character who is buffed exclusively with 7th+ spells... but this is very unlikely considering that excludes all forms of haste, Resist Fear, Death Ward, Chaotic Commands etc. and nailing vulnerable party members with lethal or disabling spells should be higher priority in a script than stripping buffs from those who are protected.

I don't think there's any compatibility problem. I more meant that if implementation was simple enough then I'd consider this for SCS itself. But I don't generally like incorporating other people's code into SCS, because then I struggle to deal with bugs and compatibility issues down the line.

44 minutes ago, Mike1072 said:

Fine, I've updated the mod page and download page.  The mod is still exactly the same, it's still a beta, this is not a "definitive" version, yada yada yada.

Great - I think that's all it needed. ("Beta" has long been a variable feast in modding, in any case.)

On 8/6/2020 at 1:44 PM, subtledoctor said:

But... why?

I still don’t understand what you mean by “finalized.” Just for the G3 link to point to v4 instead of v3? 

That would be nice, actually. I have some time for this objection: if someone comes to G3 and looks for Spell Revisions  (or just looks around under the various mod lists and comes across Spell Revisions), the main website will point them to SR v3.1.03 and will give no indication that there is a later version. Even if they check the forums (and they might well not) they'll come across the fact that there's a 'v4 beta 18', but they could pretty reasonably conclude that they should stay with the stable v3 rather than the clearly-under-development v4 beta. (When I started updating SCS a couple of years ago, I assumed that I should be working with SRv3 as the last stable release given that was what the main site pointed to and given the way v4 is named - it took me a bit of time to work out otherwise, and I'm scarcely new to or uninformed about modding.)

That's interesting: apologies, then, @subtledoctor, I misinterpreted the IESDP. (It would be clearer as 'none of the set bits are common'.)