DavidW

SCS does something a bit similar. Fire/acid damage turns off their regeneration for a round.

Pretty much, yes.

The intended functioning (troll falls unconscious below about 10hp, needs fire or acid to hurt it further, recovers after a couple of rounds) is the same in both. The implementation is quite different. In classic BG2, it's done by scripts and by an extra, near-death, version of the troll creature: the troll's script tells it to polymorph into the near-death troll when its hit points are low enough, and the near-death troll is told to polymorph back into the dead troll after a timer expires. The main problem is that scripts don't always reliably fire, especially if there's a lot going on - sometimes you have to back off for a second to let the troll fall. A secondary problem is that it's easy to introduce bugs where the troll comes back to life as a different creature, since there's no requirement that the sleeping troll script reintroduces the creature that created it. A tertiary problem is that it's awkward for trolls to drop loot. In EE, the troll has an effect on it (actually, on an item it wears) that triggers when it gets to <10hp. The effect casts a spell that knocks the troll unconscious, makes it immune to all damage types except fire and acid, removes its immunity to death so that it can actually be killed, and does a delayed healing effect on the troll. There's no need for anything in the scripts or for an extra creature file. In my experience, the EE version is drastically more robust, though still not quite perfect.

...possibly. With WoP, there are a bunch of different reports; some people seem to be playing it fine, others run into problems. It's too messy for me to sort out without a fairly systematic recode (happening, but no ETA) so I can't recommend it. With Longer Road, I have basically no idea. David Gaider thought the original Sendai was tough enough already. I don't know, sorry.

You need to reinstall SCS to get them. That probably won't mess up your savegames (no promises!), and SCS is towards the end of any sensible install order so you shouldn't have to redo much of your installation otherwise. (Incidentally, it's helpful if people can avoid doubleiposting to both here and at Beamdog. I read both. This one, more frequently.)

I have only a very limited ability to mess with the current automated translation system. If an authenticated user (not a guest) is able to provide me with a set of .tra files for Russian (or any language) that they attest is 100% complete, I'm willing to use it directly and bypass the automated translator. It is not clear to me that it's being helpful in this case.

It's possible (iirc we did it for IWD-in-BG2) but it's not fun. You need to add them as new cycles to states.bam, and then add a line to speldesc.2da.

I don't think I gave you a solution. I suggested you use STRING_SET_EVALUATE; that's still my advice as to how to do this sort of thing in general, but I left it to you to work out the code. Cam offered you some sample code, but forgot to read in and write back the soundset data. (I think it's pretty obvious that when someone offers some code in a textbox, it's the responsibility of the person using the code to check and test it, not the responsibility of the person answering the query.) ACTION_GET_STRREF returns the text part of a strref, ACTION_GET_STRREF_S returns the WAV file, and you have to write them both back with STRING_SET_EVALUATE once you've done whatever search-and-replace you want on the contents.

This is a direct port from IWDEE. Fixing bugs in IWDEE is outside SCS’s scope, unless they’re really critical, not least because for all I know they’ll be fixed in 2.6 anyway.

Probably not, sorry.

Updated to v33.4. This updates the Russian translation and fixes a scattering of bugs - notably, player-summoned fiends should attack properly, sequencers won't be cast while out of range, Aec'letec should use his gaze attack, overenthusiastic NPC wizards won't electrocute themselves and go hostile, and hopefully the Sendai statue fight won't hang. (I'm less certain about that one, I still don't fully understand it.) As with the last couple of releases, this isn't a systematic catch of all the bugs reported - I've fixed the critical ones (the ones that break the game or lead to some relatively-drastic failure in it) and then opportunistically done a few that I could catch and handle quickly.

I've updated to 2.0.13. This updates the Russian translation further (how much, I don't know, not speaking Russian), updates to the latest Detectable Spells (which shouldn't matter to players) and guards against problems with Timestop detection (which might, since I think it's the cause of the occasional, erratic, critical bug in the battle with Sendai's statues).

Solving that problem is a second exercise for the reader. (Hint: look at ACTION_GET_STRREF_S in the Weidu readme).

It's probably compatible, in the sense that adding new spells won't break SCS, but it won't use those new spells. AI mods use new spells only if they've been specifically coded to do so, one spell at a time. I did this with the IWD spells because I wanted to use them myself (and with a longer-term view towards SCS-IWDEE compatibility); I did this with the SR spells because SR is quite popular, is a G3 mod, and because I had good relations with Demivrgvs, its now-retired author. I'm afraid there's not much chance of my doing it with any other spell mod - it's quite a lot of work, both coding and bug management.

Ah yes, got it. A few updated strings for the auto-leveller, and a reversion of the UTF-8 encoding on spell descriptions. I'll do it when I have a chance; no eta though.

Re ranged spells in contingencies/triggers in SCS: I think the problem is fairly small. NPCs don't use the main Spell Sequencer opcode, they fake it. (That's true in vanilla, in SCS, and in any mod I know.) SCS fakes it in one of two ways: (i) if any spell in the sequencer grants a saving throw, the spells are cast using ReallyForceSpell (and a fake, visual-only, spell is cast to simulate the Sequencer itself). (ii) in other cases, I build a bespoke spell that uses opcode 146 to cast the spells. (My v32 alpha always used method (ii), but creatures end up rolling one saving throw and using it for all spells in the sequencer, which isn't desirable.) Method (i) doesn't have a problem with range, because ReallyForceSpell() ignores range. (I suppose I ought to be checking to keep things legal, but life is too short.) Theoretically cone spells are an exception, but I think I do an explicit range check for cone spells. Method (ii) will fail if the range for the envelope spell is larger than the range for the payload spells. Looking down your list, I think that's Vanilla and SR: Call Woodland Beings, Conjure Elemental, Animate Dead/Summon Shadow SR only: also Invisible Stalker, high-level elementals. Looking back across the thread, I think the reported problems with short-range spells were in players' sequencers/triggers, not in SCS's... but if that's wrong, let me know. In the medium term, I can fix this dynamically: I was being lazy and giving my fake spells a hardcoded range, but I ought to just scan the payload spells dynamically and set the bespoke spell range to the smallest of the payload ranges.

SCS 33.1 (released May 31st) updated the Russian translation. If there’s a more recent update than that I’m not aware of it.

Thanks to both. (I didn’t even think to check the BECMI material.)

SCS generally hasn't done that sort of fine-grained work. (It's a general difference between aTweaks and SCS: aTweaks does very detailed careful work on a small number of creatures; SCS affects pretty much everything in the game but inevitably has a bit less attention to detail.) That's a bug. I think player-summoned fiends generally are working a bit oddly in SCS v32/33.

Don't worry about it. Glad it's working now.

It sounds as if the game might have been running when you installed the mod?

The number will depend on the user’s specific install choices.

Use WEIDU’s STRING_SET function instead of AT_NOW.

An accusation of making straw-man arguments is an accusation of intellectual dishonesty.

I've separated off the recent part of the discussion to this thread. Anyone who wants to contribute further to the discussion of lich immunities in the context of SCS is welcome to do so. If they can manage to do so without accusing me of intellectual dishonesty they are more likely to contribute constructively to SCS.