DavidW

This is just a question on how you want the tool to present the factoids. In my mind, if the player wants to, he should be presented with all the options and let them figure things out for themselves.

Among the "options" in (my current local version of) stratagems.ini are

 

- Put_Labels_in_Workspace (changes SCS's default approach to where marker files are stored; optimistically, has no effect on in-game performance; pessimistically, prevents install)

- Debug_Variable (if set to 1 or 2, displays pages of meaningless text; if set to 3 or 4, will FAIL the install after getting part-way through)

- God_Does_Not_Play_Dice (if set to 1, disables all randomness so that you get the same result on each install)

- force_tra_rebuild (if set to 1, significantly slows install time with no effect on in-game results)

- disable_ssl (if set to 1, no scripts will be built, which will make most of the game nonfunctional)

 

 

I think the player can live without having those options presented to them.

 

 

Over and above that, there are other options that I actively think most people shouldn't use. I don't want people choosing them without really knowing what they're doing. Making sure they actually have looked at SCS's readme is a good way to check for that. A line or two of GUI text isn't. (And the very fact of an option being presented to end users in a GUI installer carries some implication that choosing the option is supported.)

... so in light of Ardaniss post, I should revisit this: why do you want to edit stratagems.ini anyway?

Whats the advantage of doing this over just disabling the mechanical effects of the difficulty slider, either through the gameplay screen in EE or via ToBeX?

Neither is intentional, though both are fairly annoyingly difficult to sort out; still, Ill have a look.

I agree with Ardanis; you absolutely dont want to have an autoinstaller algorithmically read the ini and present the options to end users. Several of SCSs ini options will definitely crash the game and only exist for my own modding/testing purposes. Others are for options I really dont recommend and dont want people to touch but put in to support a few vocal people. Others still just externalise choices for my own convenience. I actively want SCSs ini invisible to people who didnt come across it through detailed reading of the Readme.

Isn't it more elegant to format your INI file as valid WeiDU variable assignments and INCLUDE it?

 

Works great for me. Even better: wrap the variable assignments up as a macro. Then in the .tp2 file INCLUDE the file and LAM the macro. And, for ultimate safety, use a modder prefix in all of the variables.

 

If your mod's own internal data needs a modder prefix, your design has some serious problems with encapsulation...

Anyway, since this dagger is meant to be droppable, what about giving it a unique Inventory Icon? If I'm not mistaken, it's currently using that of the ordinary dagger, which is kinda meh.......

Icon design is outside my skill set.

Careful. That's the beginning of the road to becoming an actual modder.

Once you start down the dark path, forever will it dominate your destiny.

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

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.

That's why I asked @DavidW to provide a list of the items (in particular weapons/armors/shields) introduced by his mod ----> it shouldn't be difficult to create a mini mod that can standardize everything introduced by this mod...... Once I know the item code (e.g., dw#[0-9]*[a-z]*.itm), it's just a matter of using COPY_EXISTING along with ALTER_ITEM_HEADER.......)

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.

Ya. The EEs really don't need biffing. (Though EET + IWD-in-EET will be the ultimate test.) I've got 20,000+ files in the override folder on a midrange iPad from 6 years ago (A7 chip, 1GB RAM)... and no slowdowns whatsoever.

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