Jump to content

DavidW

Member Since 07 Aug 2006
Online Last Active Today, 09:38 PM

Topics I've Started

DavidW queries about SR v4b15

27 September 2018 - 08:21 AM

I'm going to use this thread to post silly questions about SR that are coming up in SCS v32. 

 

 

Here's the first: why are there no scrolls of Summon Fiend and (wizard L9) Gate? Both spells have SR versions, neither is in HIDESPL, but both have their scrolls overwritten with Monster Summoning spells. Is this intentional?


Advice on SR stability

26 September 2018 - 05:13 PM

I'm just revising my local v32 to upgrade its allowance for SR, but looking at this thread it's not clear to me what the appropriate version of SR is at the moment - there is the v3 on the download page (very out of date), the GitHub version (about 2 years old), "SRR", which I think is a third party's personal project but also being used by others, and maybe others I'm missing too. And there are continuing discussions about potentially quite large changes to the system.

Can someone advise me as to (a) whether SR is currently stable enough for me to code AI around it, and (b) if so, which is the "official" version I ought to be working with?

Starting XP in Throne of Bhaal

25 September 2018 - 06:18 PM

So far as I can see this is still hardcoded, even in BG2EE 2-5. Anyone able to confirm (or correct)?

Immutability and encapsulation in mod design

18 September 2018 - 05:46 PM

This is a note on a couple of design principles I've been using in my mods in the last few years (since roughly v22 of SCS, I think) and that I thought might be of wider interest, at least for discussion. A lot of this is probably overkill for something like a quest or NPC mod; it's mostly relevant for big complicated multi-component mods that work on multiple game systems. This note assumes you're already familiar with the basics of WEIDU.

The two design principles (both of which, from an academic perspective, come from functional programming) are:

  • Encapsulation: each component of the mod needs to be kept entirely separate from the other components. Nothing that happens in any component should have any effects on anything in another component (except through the effects it has on in-game files). In particular, variables set in one component should be forgotten as soon as the installer moves on to the next component.
  • Immutability: Nothing in your mod folder should change at all when the mod is installed.

(Quite a few mods use encapsulation to some degree, though I don't think many use it systematically. I think I'm the only person who cares about immutability.)

 

Why care about encapsulation?

 

I learned to care about encapsulation the hard way, way back in the prehistory of SCSII testing. Odd situations occurred where the mod would install fine on my computer, and then would throw errors on other people's computers. It turned out that I was installing one component at a time, so that variables set by each component were being forgotten, but my testers were (reasonably enough) installing several at once. Encapsulation is your guarantee that if a component works in isolation, it won't be confused by - or confuse - the wider environment in which it operates.

 

Why care about immutability?

 

This is subtler, but the big benefits of immutability (to me, at least) are:

  • You don't risk accidentally distributing things you didn't intend to, like partly-built files, your backup directory, or UTF-8 tra files. I used to do this all the time in the early days of SCS.
  • It's one fewer source of bug reports, given that users have been known to copy the mod folder from one game to another.
  • You can have the mod simultaneously present on multiple versions of the game. When I'm developing SCS I have one copy of the mod folder, with virtual directory links to every IE game on my harddrive. So I can change a file and have it instantly reflected in all the virtual "copies" - but I can install part of SCS on (say) BGT without that affecting my BG2EE install. This only works given immutability, because otherwise folders in the mod (like your backup folder) keep track of what's installed and you'll hopelessly confuse things if you try the virtual-folder trick. Before SCS was immutable, I used to have to carefully copy it from game to game, and not infrequently had sync errors. (Come to think of it, in the git era there are other ways around it, but the most straightforward require an internet connection, and I often mod on long flights.)
  • It's easier to use online backup services. That "one copy of the mod folder" lives in my Dropbox folder, so gets backed up, and synced between my desktop and my laptop, in real time. That gets very cumbersome if Dropbox has to copy several thousand files out of the Backup directory every time I install a component; more importantly, I can have different install states on different machines without confusing things.

In the next few posts I'll talk about how to do these things.

 


IDS entries for SR spells

18 September 2018 - 10:45 AM

I'm revising the section of SCS that pays attention to SR, both to catch up with SR changes over the last few years and to try to more deeply integrate SR's magic system into my AI. Doing that requires me to assign SPELL.IDS entries to SR spells, since SCS mostly references spells by their IDS entry rather than their filename - none of the new ones have an IDS entry, and some of the ones occupying previously-used slots have really misleading ones that are an invitation for me to make a mistake.

Since other mods might want to do the same (indeed, SR might want to do the same in due course) I thought I'd make the code, and more importantly my choice of public here. The main goals are (1) use the same ids entries as IWD:EE does (and as IWDification does) when an SR spell is a conversion of an IWD spell; (2) make sure names are not radically misleading.

Most of the IDS entries added are for entirely new spells. About 20 overload existing spells (so that WIZARD_EXPEDITIOUS_RETREAT and WIZARD_PROTECTION_FROM_PETRIFICATION both point to SPWI108, for instance). Ideally I wouldn't do this as there are one or two places where it can cause some confusion, but I think it's the least worst option without editing SR itself. Ideally, SR should be changed so that those 20 spells get put in via ADD_SPELL, and the existing spells are hidden via HIDESPL but left in the game. But that's not something I can do in post-SR code, given that SR destructively overwrites the spells.

This is coded as a function. It should be safe to run it multiple times.
DEFINE_ACTION_FUNCTION spell_rev_ids BEGIN
  SILENT
  // removing or changing of obsolete labels
  
  COPY_EXISTING "spell.ids" override
     PATCH_IF INDEX_BUFFER ("CLERIC_PROTECTION_FROM_FIRE_DEPRECATED") <0 BEGIN
            REPLACE_TEXTUALLY "CLERIC_PROTECTION_FROM_FIRE" "CLERIC_PROTECTION_FROM_FIRE_DEPRECATED"
     END
     PATCH_IF INDEX_BUFFER ("CLERIC_PROTECTION_FROM_LIGHTNING_DEPRECATED") <0 BEGIN
            REPLACE_TEXTUALLY "CLERIC_PROTECTION_FROM_LIGHTNING" "CLERIC_PROTECTION_FROM_LIGHTNING_DEPRECATED"
     END
     PATCH_IF INDEX_BUFFER ("CLERIC_STALKER")<0 BEGIN
            REPLACE_TEXTUALLY "CLERIC_CONJURE_EARTH_ELEMENTAL" "CLERIC_STALKER"
     END
     REPLACE_TEXTUALLY "CLERIC_SPACE_WARP" "CLERIC_ANIMAL_SUMMONING_4"
     REPLACE_TEXTUALLY "WIZARD_HOLD_PORTAL" "WIZARD_DIMENSION_JUMP"

  // new spells

  ACTION_DEFINE_ASSOCIATIVE_ARRAY sr_ids BEGIN
  // new cleric spells
  1116 => CLERIC_SUNSCORCH
  1117 => CLERIC_REGENERATE_LIGHT_WOUNDS
  1118 => CLERIC_GOODBERRY_DRUID_VERSION
  1119 => CLERIC_CAUSE_LIGHT_WOUNDS
  1120 => CLERIC_ANIMAL_SUMMONING_SR_LEVEL_1
  1121 => CLERIC_OBSCURING_MIST
  1210 => CLERIC_RESIST_ELEMENTS
  1215 => CLERIC_CURE_MODERATE_WOUNDS
  1216 => CLERIC_FIRE_TRAP
  1217 => CLERIC_REGENERATE_MODERATE_WOUNDS
  1218 => CLERIC_GUST_OF_WIND_DRUID_VERSION
  1219 => CLERIC_CAUSE_MODERATE_WOUNDS
  1220 => CLERIC_ANIMAL_SUMMONING_SR_LEVEL_2
  1320 => CLERIC_ANIMAL_SUMMONING_SR_LEVEL_3
  1321 => CLERIC_CAUSE_MEDIUM_WOUNDS // I know it's called "Cause Serious Wounds" in SR, but this matters for IWD compatibility
  1322 => CLERIC_STORM_SHIELD
  1323 => CLERIC_REGENERATE_SERIOUS_WOUNDS
  1324 => CLERIC_MAGIC_FANG
  1325 => CLERIC_SPIKE_GROWTH
  1326 => CLERIC_ICELANCE
  1418 => CLERIC_ICE_STORM
  1419 => CLERIC_REGENERATE_CRITICAL_WOUNDS
  1520 => CLERIC_PROTECTION_FROM_ACID
  1521 => CLERIC_PROTECTION_FROM_COLD
  1522 => CLERIC_PROTECTION_FROM_LIGHTNING
  1523 => CLERIC_PROTECTION_FROM_FIRE
  1524 => CLERIC_MASS_REGENERATE
  1525 => CLERIC_ANIMAL_GROWTH
  1619 => CLERIC_REGENERATION_DRUID_VERSION
  1620 => CLERIC_BANISHMENT
  1621 => CLERIC_CONJURE_AIR_ELEMENTAL
  1621 => CLERIC_CONJURE_EARTH_ELEMENTAL
  1623 => CLERIC_ANIMATE_SKELETON_WARRIOR
  // new wizard spells
  2226 => WIZARD_MONSTER_SUMMONING_SR_LEVEL_2
  2327 => WIZARD_ICELANCE
  2426 => WIZARD_PROTECTION_FROM_ELEMENTAL_ENERGY
  2427 => WIZARD_VITRIOLIC_SPHERE
  2526 => WIZARD_MESTILS_ACID_SHEATH
  2724 => WIZARD_MONSTER_SUMMONING_5
  2802 => WIZARD_MIND_BLANK
  2819 => WIZARD_MONSTER_SUMMONING_6
  2906 => WIZARD_MONSTER_SUMMONING_7
  // overloading of existing cleric spells
  1114 => CLERIC_FAERIE_FIRE
  1115 => CLERIC_STRENGTH_OF_STONE
  1311 => CLERIC_CONTAGION
  1318 => CLERIC_GUST_OF_WIND
  1515 => CLERIC_REPULSION
  1703 => CLERIC_SUMMON_DEATH_KNIGHT
  1706 => CLERIC_SYMBOL_WEAKNESS
  // overloading of existing wizard spells
  2106 => WIZARD_OBSCURING_MIST
  2107 => WIZARD_MONSTER_SUMMONING_SR_LEVEL_1
  2108 => WIZARD_EXPEDITIOUS_RETREAT
  2111 => WIZARD_TRUE_STRIKE
  2223 => WIZARD_SOUND_BURST
  2501 => WIZARD_SUMMON_SHADOW
  2508 => WIZARD_WAVES_OF_FATIGUE
  2510 => WIZARD_DISPELLING_SCREEN
  2619 => WIZARD_MONSTER_SUMMONING_4 // special case, we want IWDification and the like not to install this
  2623 => WIZARD_ANIMATE_SKELETON_WARRIOR
  2707 => WIZARD_SUMMON_DEATH_KNIGHT
  2811 => WIZARD_SYMBOL_WEAKNESS
  END

  ACTION_PHP_EACH sr_ids AS key=>value BEGIN
       APPEND "spell.ids" "%key% %value%" UNLESS "%key% +%value%"  
  END


END