DavidW

On reflection (unless I'm misunderstanding your proposal) this does have the problem that if I add new entries to stratagems.ini they won't be present in the user's copy.

 

On biffing: "Improved Abazigal's Enclave" restores the animations for lizard-man weapons. It's bad practice to put animations in the override as, in aggregate, they lead to major slowdowns (a lesson of IWD-in-BG2) so they get biffed.

This is not true in the Enhanced Edition games. At least there is no notizable difference ... even with large amounts and so forth, unlike with the non-EE where it was the first thing that needed to be done. So you might want to condition the biffing behind that. The EET still biffs, but it's because K4thos likes to put things to biffs that are not likely to be altered, and in there it can be skipped with a god awful console insert.

 

That's useful information. Can anyone else confirm?

 

Oh, I believe you're missing the laziest option of all--a tpa masquerading as an ini file.

Ha! Amazing creativity when you need to "get things done"

 

 

 

It's not intended to be read by anything except SCS itself, which is why it follows no particular format. However, if it would be helpful I don't particularly mind changing it to key = value.

 

I'm aware that the purpose of this file is to be read only by SCS. It would be very helpful to change the format of this file to "Key=Value" pairs because I can parse it via industry standard algorithm.

 

I notice one problem with the way how you designed the "reading SCS custom option from configuration file":

 

Steps to reproduce:

0. Download and extract SCS

1. Edit stratagems.ini and set desired options

2. Install SCS 31

4. New version is released, download and extract SCS 32 > stratagems\stratagems.ini will be introverted to default one, it will happen every time when new version will be released > reinstall SCS

Possible way to fix:

- rename stratagems.ini to configuration-example.ini (reason for renaming - I try to be one-step-ahead of what I will ask/provide by myself next)

- change 'read setting logic' to always read from configuration-example.ini it it is present

If you could fix this before releasing 32, you will save yourself the trouble of receiving bug reports about 'my settings don't work anymore'

 

Interesting point.

 

I am allergic to letting SCS modify itself, so that doesn't quite work as stated, but a variant would work.

Clever. In an INNER_PATCH or something?

 

SCS tries very hard to separate code and data, though, and since I already have an ini-reader function coded it's just a matter of changing a line in that function. (Also, that keeps the ini entries out of the global namespace - I just check them with LAF check_ini STR_VAR ini=whatever_it_is_we_are_checking RET value END. But that's more being fastidious than anything else.)

That's interesting... SCS sets the animations for fiends using the entries in ANIMATE.ids - so (on a non-EE install) for instance Glabrezu's get whatever animation number corresponds to IC_GLAB. It sounds like Infinity Animations messes with the lookups in animate.ids, which is a bit annoying but fairly easily fixed.

 

 

... and yes, having checked, that's exactly right. I wish people wouldn't do that.

 

If the nice people doing the v31 maintenance release are still doing new content, you can fix this by

(i) putting a block to detect Infinity Animations in lib/always.tph and setting infinity_animations to 1 if it's there (checking if animate.ids contains "PIT_FIEND_NWN" is probably the most robust way, since the main IA component isn't DESIGNATED and doesn't drop an obvious marker file)

(ii) editing fiend/fiend_shared.tph to change the four or five animation => blah commands that set animations dependent on whether the enhanced edition is installed, to check for IA too. In almost all cases it looks as if IA and EE use the same conventions so you can just replace "if enhanced_edition" with "if (enhanced_edition or infinity_animations)". For Bone Fiends IA seems to use SKELETONB, which isn't either the vanilla or the EE choice.

 

This isn't worth worrying too much about, though. It won't break the install, and for 90%+ of fiends the animation is right anyway, I'm just doing some systematizing. I'll fix it myself for v32.

Yes, it's a 2da in effect.

 

It's not intended to be read by anything except SCS itself, which is why it follows no particular format. However, if it would be helpful I don't particularly mind changing it to key = value.

Luke, definitely do NOT install IR after SCS. (Unless they are your only two mods, I guess.)

Even if they are, you will confuse SCS's targeting if you install new or modified magical items after it's done its detectable-spells runthrough.

So my reluctance to change anything here is partly because that component (which dates back to the first release of SCS) is based on a tiny fragment of the ancient "dark side of the sword coast" mod, and so on nostalgia grounds I don't want to make arbitrary changes to it. That doesn't mean changing things that flatly don't work, but it does mean I won't remove the daggers unless there's a significant problem with them.

 

Here's the list of worries people have mentioned:

 

1) "They're tactically unbalancing." I find that really implausible in practice. They're nonmagical daggers; they do one point of damage per second for six seconds; they have a 5% chance of poisoning the user. That is not going to be competitive as a combat option for most characters. (And if there's an occasional niche build that gets mileage out of the dagger for a level or two, great: that's the sort of emergent behavior that makes the game more interesting.

 

2) "They unbalance the economy." I'd again be pretty surprised if that's true: they cost 75gp and I can't imagine you end up with more than a dozen or so over the course of Nashkel. Still, 75gp is probably a little on the high side; it could be toned down.

 

 

3) "It's unrealistic that kobolds can mass-produce magical daggers." They're not magical.

 

4) "If they're not magical, it's unrealistic that they produce poison indefinitely." Fair enough. It wouldn't be too hard to give them a 10% chance per use of running out, or something similar.

 

 

5) "SCS shouldn't be adding items at all, because IR should be doing that." See Bartimaeus's reply to Luke.

I've done some tidying up on this thread, since it's supposed to be about testing v31, which is a maintenance release only, which I'm not doing, and which doesn't contain new content. Suggestions for new content, or content changes that aren't bugfixes, need to go elsewhere (I've made a new thread for the kobold-dagger issue).

 

 

But a couple of things that are relevant to v31 got swept up in the split, so I'll repeat them here:

 

From Bartimaeus:

(e): I seem to be getting a number of "tried to set nonexistent animate entry" errors with Improved Fiends on RC3 (ignore that it says RC2, because I'm pretty sure the version number just wasn't incremented). weidu log + debug. Should I be concerned? From what I Googled, someone else had this back in 2014, but no explanation as to why it was happening was given, though it was apparently fixed.

On biffing: "Improved Abazigal's Enclave" restores the animations for lizard-man weapons. It's bad practice to put animations in the override as, in aggregate, they lead to major slowdowns (a lesson of IWD-in-BG2) so they get biffed. As of the last update of SCS I don't think it was possible to mod the iOS version (actually, I didn't know it was possible now until reading this thread). If you set "no_lizard_biff" to 1 in stratagems.ini it should disable it.

@DavidW

 

I have two questions:

 

1) Can you confirm SCS does not biff its own content?

Mostly not. I biff some animation files at one point; it's not viable to leave unbiffed animations in the override.

 

2) I should have clarified myself better about that dagger: if SCS adds new items (in particular weapons/armors/shields), then that's bad. As you know, one of the components of IR is meant to alter the base stats of those items and this component is usually installed *before* SCS -----> this means that all those weapons/armors/shields introduced by your mod will be skipped......

Tough. It's not reasonable for a mod to enforce a rule that no other mod may add items. (And, historically, that component of SCS predates IR by several years.) If you want to make global changes to items, separate them off from general "item revisions" and lobby to include it in a late-install mod.

 

 

Eh, whether it's to your taste, this is very much what Demi intended, and part of what (IMHO) makes SR good. Look at it from the perspective of someone making a mod like this: the SI spell(s) is trash, it doesn't exist in PnP, it makes for stupid cheesy gameplay, we want to remove it. But, objection: SCS AI utilizes it. So what do we do? An elegant solution: let the AI do what the AI needs to do, but present the player with a spell list that excludes the trash. Move the basic functions - thematic categorical magical protection - to more suitable spells.

 

tl;dr: SR's treatment of the SI:x effects can maybe be refined a bit, but overall it's gotta remain.

 

IMHO the SI thing really falls into the category of your personal preferences, like the other stuff in your "glaring problems" list. I haven't touched on that stuff because I wanted to clarify some things about the list of bugs first.

SR removing the SI spell altogether would be the right thing to do (I am with Bartimaeus here).

 

Sorry, I should have been clearer. The goal of SR is, indeed, to remove SI altogether. It is gone from the player, and I think Dispelling Screen is in its place. However...

 

But how does SCS cope with that kind of change?

From what I understand, very poorly.

 

Correct. This is a general issue of good design for mods that change the spell system, not just for SCS: since the AI (vanilla game or modded) doesn't know about any spell-system changes you've made, the existing spells can't be changed in a way that fundamentally alters their functioning. If you want to replace or radically change a spell, do it by putting the original spell into HIDESPL and introducing a new one.

 

Now, SCS does make some attempt to use SR's new resources. In the early days of SR, I said to Demi that it was not realistic for me to allow for SR in the basic interplay of defensive spells, and so the logic of those spells had to remain unchanged for compatibility's sake; Demi agreed. SCS's internals have evolved to the point where it's become more realistic, and the next release of SCS that *I* do (as opposed to the maintenance release that CamDawg and others are very kindly putting together) will probably try to use SR's new defensive spells more and drop the legacy ones. But that "next release" may be a while away given how busy I am these days, and in any case SCS is not the only AI mod (and the vanilla game also has AI), and the basic case for leaving the original spells available for non-SR-aware AI still remains.

Droppable daggers is intentional, not a bug. I'm fairly confident the 5% self-poison chance makes them sufficiently unattractive to PCs that it doesn't unbalance anything (and I find undroppable gear immersion-breaking in general).

 

Contra Luke, there is no systematic "SCS doesn't add items" rule. It doesn't add *many* items, to be sure, because I don't want to unbalance the game's economy, but I put them in from time to time for flavor reasons. (The armor you can make from Anadramatis's skin, and the amulet he gives you if you defeat him without killing him, are the other examples that come to mind.)

 

 

Thanks for this! In addition to my previous suggestions, in my opinion it would be nice to transfer these SCS components:

- Reduced reputation increase

- Increase the price of a licence to practice magic in Athkatla

- Increase the price asked by Gaelan Baele

 

It's because those components are very useful (even without SCS) for medium-large installation when you are dealing with lot of gold and quests. Thoughts?

 

 

I'll let David chime in, but my understanding is that he wants to focus SCS more on tactical matters. These three components affect your approach the game by limiting your economic power, impacting how easily you can gear up the party.

 

I have no desire to monopolize tweaks, and I'm perfectly happy referring folks to SCS for these.

 

Pretty much this; the components I'm moving to Tweaks are really in the ease-of-use / cosmetic space, whereas these components are more substantive modifications to the game.

Well, as I say: technically the solution I sketched should do it. Try it out and see if it works, and if so what the aesthetic and tactical implications are.

Actually, just as an addendum, since I didn't pick up on the Staff of the Magi point: from a game-balance point of view (and I appreciate your objection is partly thematic and aesthetic) the problem with the Staff of the Magi is that it breaks the action economy by applying a power (turning invisible) that's normally gated by action economy. Shapeshifting doesn't itself apply any power; it just changes your attack and protection portfolio - something you can do anyway for free in the IE action economy by equipping a weapon. (Indeed, mechanically the shapeshifter paws in Improved Shapeshifting are literally weapons with a bunch of associated on-equip effects, as you probably know if you've been modding them.)

 

Incidentally, "squeez[ing] spellcasting and physical attacks into the same time period" has been part of BG strategy, and AI scripting, pretty much since the beginning - it's a natural consequence of the real-time-with-pauses implementation of the AD&D ruleset replacing a turn-based one.

There are no polymorph/shapeshifting abilities that work that way. There is no version of D&D that I've ever seen in which shapeshifting wasn't something like (to use recent parlance) an "action."

 

You can shapeshift in Pathfinder as a swift action, as I recall, if you're willing to give up a level or two in creature power; that sounds fairly instant to me.

 

More substantively, in many editions of D&D you can spellcast while shapeshifted. I don't like *that* aesthetic, but it addresses the obvious problem with AD&D shapeshifting, namely that it's just not really effective for a spellcaster in the action economy. That's always been what that component tries to address; the symbolic paws are a means to an end since you can't really do free actions in IE.

 

This turns a spell ability into something like the Staff of the Magi - notable really for how it breaks what you know about the rules of the game, rather than doing interesting things within those rules. Worse, there are all sorts of other shapeshift/polymorph abilities that do play by the rules, so it creates a fairly massive inconsistency that I personally find jarring.

At some level we're getting towards "don't install that component then".

 

Finally, I just don't envision druids turning their bodies into animals as something that happens at the speed of computer programming - faster than my fingers could even do it using a mouse and keyboard. It's basically just an aesthetic issue: that's not how it works in the story my brain tells, and so the visual of druids flipping back and forth like light switches is grating. A very slight delay - not something to change the tactics, but something to visually suggest the druid just underwent a process, would go a long way toward making me want to use that component.

I don't mind looking to see if a very short delay can be made to work - though as I recall you've had a visceral dislike of that component for years and for lots of reasons, so "don't install it" is probably still the best advice!

No, I simply want SCS AI to use the Improved Shapeshifting exactly as it normally does; however, the reason I mention mucking about with install order it, I want to lightly patch the SCS shapeshift paws. It's been a loooong time since I played with that component, but I'm guessing it scripts enemies to operate the way an aggressively optimization-minded human player might: lightning-quick switches between human and animal forms, in order to (more or less) squeeze spellcasting and physical attacks into the same time period.

From a technical perspective, do that by distributing your own copies of DW#SHNxx.ITM and a copy of dw#shapeshift.mrk. SCS will think Improved Shapeshifters is installed and use your versions. (They'll be overwritten if someone installs the actual Improved Shapeshifting component but presumably it's conceptually incompatible anyway.)

 

From a design perspective, I fairly strongly discourage it, because the SCS scripting assumes shapeshifting is instant and optimizes on that behavior. If you slow down the shapeshift, SCS druids will probably behave unwisely.

 

 

Incidentally, "squeez[ing] spellcasting and physical attacks into the same time period" has been part of BG strategy, and AI scripting, pretty much since the beginning - it's a natural consequence of the real-time-with-pauses implementation of the AD&D ruleset replacing a turn-based one.

It's not a great idea to install the "initialize" component early in the install. It does a lot of resource-collecting and item-flagging that will miss things. (Yes, it's arguably flawed design to require that component for the non-AI bits of SCS; v32 won't.)

 

If I've understood what you're after, the reason you want SCS improved shapeshifting installed is because you want SCS's AI components to detect it and use symbolic-paw shapeshifting for opponents?

 

If so, you can probably do a quick-and-dirty version like this:

 

 

- harvest dw#shapeshift.mrk and all the ITM files with names beginning "DW#SHN" from the override of a local copy of SCS with "Improved Shapeshifting" installed.

- include them with your mod and drop them in the override.

 

 

dw#shapeshift.mrk is the marker file that SCS uses to detect the "Improved shapeshifting" component, so putting it in the override will fool SCS into thinking the component is installed. And (I think) the DW#SHNxx.ITM files are the only files actually used by enemy shapeshifters, and don't rely on dialog entries.

 

 

I haven't tested this, though.

Why do you too, regard as a point of intress to dictate what to install in what order ?

You are welcome to install mods and components in whatever order you like. You are, equally, welcome to edit the TP2 at random before installing, to remove and change mod files manually, and to insert your own random strings of binary into WEIDU. It's a free country.

 

But if you do any of these things, don't expect either help or sympathy when you report that your install isn't working.

 

Especially with the help of old readme from years ago. […] You are correct in that the ancient Ascension is generally meant to be installed before SCS. But ... the case was not that here, rather an Ascension with BG2EE.

That readme is still 100% accurate as to install order. Of course you won't be installing the Fixpack on an EE install, and you can *get away* with treating Ascension as just one more of the "mods which add new quests and similar game content" now that its code has been updated, but the conceptual reasons for installing all such mods very early in the install order still apply - and Ascension in particular is sufficiently foundational that it never hurts to put it early, and even though its code is updated it conceptually doesn't need to install differently according to what your game baseline is.

 

 

In particular, SCS specifically mods *Ascension* (i.e., six of its components only apply to Ascension, and won't even be offered as options if Ascension is installed) and so obviously needs to go later in the order.

I have a pretty general policy of not giving advance warning of things I plan to add, sorry!

@DavidW

 

Do you plan to add support for IWD:EE in version 32? That would be great ...........

No.

Btw one possible way to filter this would be to only apply spells that are in rows of the CLAB__ tables whose first entry is "ABILITY[1-9]"

 

That way it would capture all vanilla abilities & effects, and modders could "opt in" to SCS applying their abilities to the AI by simply appending something like this:

ABILITY      ****        AP_MY_ABIL ****        ****     etc.

...but anyone who wants to exempt their abilities from SCS to avoid slowdowns could append:

MYMOD        ****        AP_MY_ABIL ****        ****     etc.

But I imagine plenty of ancient kit mods use the ABILITY nomenclature.

I have some time for this suggestion, but it’s more complicated than it looks.

 

Some of SCS’s tweaks perfectly well could live elsewhere (i.e. in tweaks) and in due course could do so. Various NPC and ease-of-use things, in particular. You’ll notice that those components are mostly for BG1; the fact that they’re there in the first place reflects the fact that when SCS was released as a mod for BG1TUTU there were only fairly minimal tweak mods around (and also the fact that as someone then completely new to the modding scene I didn’t have the reputation to get my content into TutuTweaks that easily).

 

The spell and item tweaks are more closely integrated with the AI than they might look, and have a radically different design philosophy from SR/IR. Those mods say, “let’s do a root-and-branch, systematic, rebalancing of the whole item and spell system”, and they do a pretty good job of it, but that level of change is too radical for some people, and in particular it’s too radical for my own personal playstyle. SCS starts by trying to give effective AI in the context of the existing system, and for the most part, only tweaks it when something is either completely broken (or can be broken by a clever opponent) or where there’s a PC strategy I can’t effectively counter. Some examples:

 

1) Skull Trap damage caps at 20d6. In a Sequencer, that’s an AoE spell that averages 210 points of damage. (Compare with 90, of the same type, from Horrid Wilting). That’s so brutally good that sensible necromancy-inclined spellcasters would use it all the time, but it’s no fun for the party to keep being hit by it. So I have to choose between (a) spoiling immersion by intentionally avoiding a perfectly legit strategy, (b) making things un-fun, or © tweaking the spell.

 

2) As Tactics demonstrated long ago, the combination of Improved Invisibility, Spell Immunity: Divination and Protection from Magic Weapons is basically unbreakable by “normal” means (i.e. by a party that doesn’t have one of a very specific list of abilities). The SR solution is to completely replace the spell. SCS’s more minimal approach is to let anti magic work through improved invisibility, which to be sure has substantial “emergent” effects but doesn’t change the face-value functioning of the individual spells much.

 

So: thematically SCS’s item and spell tweaks are pretty much all themed around supporting the AI, so I’m not inclined to move them. The spell tweaks, in particular, are so integrated into SCS’s AI that there’s an argument I should make a bit clearer in the install process how much they’re recommended (on non-SR installs at any rate).

Well, there's also the fact that this v31 SCS release candidate is not really the official one, but made by you, Cam, angel and Mad Mate... while the official one will be at some point updated by; DavidW himself.

The point is that this is not the AI update, but just the support structure update.

I didn’t see this, but for the avoidance of doubt: I am absolutely fine for this version to be released as the “official” v31. I’ve been through the got and it’s all good. I’ll do a more substantive update as v32, as and when.

I wasn’t offended.

 

As and when I do a full SCS update, I’ll politely ask the community to stop distributing “revised SCS” and return to managing SR support internally to SCS. I don’t think two versions is a good idea in steady state, for all that it was entirely understandable in 2016 when I was away for ages.