DavidW

I agree. When I say I find it immersion breaking, I mean because there’s no in-game explanation of why the kobolds get to make poisonous attacks, not because of the general - and very useful - undroppable-item trick.

Belated thanks for some very careful sleuthing. The dw#vibon issue is an error in SCS, I think - it replaces that Bone Fiend with a more advanced version, but obviously fails to set the gender correctly.

OK, if so that's a lot easier- I'll just not biff anything on an EE install.

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.

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?

Ha! Amazing creativity when you need to "get things done" 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.

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: 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.

Mostly not. I biff some animation files at one point; it's not viable to leave unbiffed animations in the override. 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.

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... 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.)

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.)

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. At some level we're getting towards "don't install that component then". 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!

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.

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. 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!

No.

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