DavidW

Kjeron's trick is very nice. I should play with REPLACE_EVALUATE more often. The use of the function isn't quite right, because of how RET_ARRAY works. (It works correctly! - this isn't a WEIDU bug.) If you do LAF GetIniKeyValue STR_VAR filename="%configuration-default%" RET_ARRAY ini_content END ACTION_IF FILE_EXISTS ~%configuration%~ THEN BEGIN LAF GetIniKeyValue STR_VAR filename="%configuration%" RET_ARRAY ini_content END END then the second call of GetIniKeyValue will return a new ini_content that replaces the old one. So if there is a key present in configuration-default but not in configuration, it won't be returned at all. You need to do either LAF GetIniKeyValue STR_VAR filename="%configuration-default%" RET_ARRAY ini_content END ACTION_IF FILE_EXISTS ~%configuration%~ THEN BEGIN LAF GetIniKeyValue STR_VAR filename="%configuration%" RET_ARRAY ini_content_extra=ini_content END ACTION_PHP_EACH ini_content_extra AS key=>value BEGIN OUTER_SPRINT $ini_content("%key%") "%value%" END END or LAF GetIniKeyValue STR_VAR filename="%configuration-default%" RET_ARRAY ini_content END ACTION_PHP_EACH ini_content AS key=>value BEGIN OUTER_SPRINT "%key%" "%value%" END ACTION_IF FILE_EXISTS ~%configuration%~ THEN BEGIN LAF GetIniKeyValue STR_VAR filename="%configuration%" RET_ARRAY ini_content END ACTION_PHP_EACH ini_content AS key=>value BEGIN OUTER_SPRINT "%key%" "%value%" END END depending on whether you want your ini data in an array or (as in Alien's original use case) a variety of variables. (I prefer the former to avoid having to worry about namespace clashes, but that's a matter of taste.)

You can do that, but you will have to copy it somewhere and strip out the comments. (Also, elegance is in the eye of the beholder; I prefer a more rigid separation of code and data, where I can get it.)

It worked, thanks. Ice golem animation was also problem and I fixed it. Just as a point of interest on the issue of what you can feed to the parser (and because from time to time I try to tempt people into trying out SCS's scripting languages) the following is legal patch syntax in SCS: MAKE_PATCH clone_ability_inline=>"number_to_add=>15 ability_min_level=>entry_index+5" patch_effect_inline=>"match=>~ability_min_level>1~ duration=>~if duration=0 then 0 else (if duration=18 then ability_min_level*6 else (ability_min_level*6 - 1))~" END LAF edit_spell STR_VAR spell=CIRCLE_OF_BONES edits=patch_data END (It changes Circle of Bones from having a fixed 3-round duration to having a 1-round-per-level duration.)

OK: (1) it's a function, so you don't put the particular ini filename in the function *definition*, you put it in the function *call*. (2) A function can't return an open-ended list of variables; it can return an associative array where each key is the variable name and its value is the variable, but you'll have to set the variables outside the function environment. Here's some sample code that does these things (assuming the function has been defined somewhere): LAF read_in_ini STR_VAR ini="INItest/configuration-default" RET_ARRAY ini_content END ACTION_PHP_EACH ini_content AS key=>value BEGIN OUTER_SPRINT "%key%" "%value%" END PRINT "%timer11%" PRINT "%timer12%" PRINT "%timer13%"

I haven't checked it, but probably this: DEFINE_ACTION_FUNCTION read_in_ini STR_VAR filename="" RET_ARRAY ini_contents BEGIN COPY - "%filename%.ini" "%override%" // COPY - means no actual changes to the file REPLACE_TEXTUALLY ";.*" "" REPLACE_TEXTUALLY "#.*" "" REPLACE_TEXTUALLY "=" " " READ_2DA_ENTRIES_NOW ini_entries 2 FOR (i=0;i<ini_entries;i+=1) BEGIN READ_2DA_ENTRY_FORMER ini_entries i 0 key READ_2DA_ENTRY_FORMER ini_entries i 1 value SPRINT $ini_contents("%key%") "%value%" END END

Like I say, SCS doesn’t modify the vanilla game here, though it’s always possible EE 2.5 has changed something.

SI: Abjuration protects from Dispel Magic (that's mostly what it's for).

SCS doesn't alter anything here as far as I recall, but the effectiveness of that strategy is quite delicately dependent on the order in which the engine applies the sequencer components, and I don't know what controls that.

… and this is fixed in v7 of Wheels of Prophecy, just released (the SCS-side fix to the bone fiend will be fixed in the next SCS release).

… aaaand they are. Terrific, thanks.

OK, I'm confused. I want to change some of the text in the UI. As an illustration (this isn't my actual use case), suppose I wanted to change the description of the difficulty slider from "Difficulty" to "SCS settings". In vanilla BG2, that's fairly straightforward: that string is hardcoded to dialog.tlk string 11314, so you just use STRING_SET to change that string. (I did that lots in IWD-in-BG2.) For EE I thought this would be easier, because so many engine strings are (apparently!) externalised to ENGINEST.2DA. For instance, in that file we find STRREF_GUI_MIXED_DIFFICULTY_DIFFICULTY 11314 Changing that to a new strref ought to do it? ... no. The in-game string doesn't change at all, whatever I set the enginest.2da entry to. OK, thought I, let's go back to the old method and change the 11314 string with STRING_SET. That's less elegant, but ought to work fine. ... no. And this is really peculiar, because the engine is displaying a string even though that string *no longer exists in dialog.tlk*. (And yes, I checked to make sure it wasn't duplicated under a different strref.) At this point, I'm really very confused. It's possible I'm doing something completely stupid and not noticing it, but if not, the game is storing text somewhere other than dialog.tlk. My best guess is that at the time the game is initially installed and you choose the language, it reads enginest.2da and dumps all the strings into some kind of hardcoded store, for speed. But despite a fair amount of digging, I can't find any sign of that store. ... any ideas? Any insight from someone who knows the innards of the EE engine? By now, I'm as much interested in the abstract puzzle as in the implications for the small task I was trying to do.

Yes. More precisely: SCS alters the AI of anything using a vanilla-game script (where "vanilla game" means "pre-EE game"). So for instance, if a mod adds a mage who uses the vanilla-game MAGE20 script, or a monster that uses the vanilla-game WTASIGHT script, SCS will replace that with its own AI (and rewrite the creature's spells, HLAs, proficiencies, and class abilities in the process). But if a mod introduce creatures with their own custom scripting, SCS will leave it alone. So for instance, SCS has virtually no effect on Black Pits, because almost everything there has its own custom scripts. That's all intended behavior. SCS replaces the default-game AI. So if a mod is using the default-game AI, its creatures get changed to use SCS AI. If it's using its own AI, they don't get changed.

Do your own research. (Everything in SCS uses my modded prefix, so it shouldn't be difficult.)

It should work, there’s actually a fairly powerful parser built into SCS’s patch interface. If it doesn’t, try If a then 1 else (if b then 2 else 3) But I doubt you need to.

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.