Jump to content


Member Since 07 Aug 2006
Online Last Active Today, 02:55 PM

Topics I've Started

SCS v32 and the difficulty slider

Yesterday, 04:48 PM

SCS v32 is now feature-complete, and I'm hoping to get it out in the next few weeks. Mostly to fill time while I'm doing install checks, I thought I'd discuss a few of the new features.

One of the big changes in v32 is that it makes really extensive use of the difficulty slider, which I pretty much ignored in earlier versions. This is something I've wanted to do for ages, but couldn't until both ToBEx and the EE allowed the hardcoded features of the slider (extra damage, saving throw modifiers, that sort of thing) to be turned off.

SCS relabels the five difficulty modes as BASIC, IMPROVED, TACTICAL, HARDCORE and INSANE. They have in-game descriptions, but roughly speaking:

- BASIC is roughly equal to the original game's AI, with a few rough corners smoothed off.
- IMPROVED is SCS-lite: most of SCS's intelligence, but a lot of restraint as to what powers and spells get used
- TACTICAL is SCS v30 towards the lower end of its difficulty settings: some but not too much prebuffing, no extra hit points for dragons, etc
- HARDCORE is around what a full install of SCS v30 looks like (and is roughly my own preferred difficulty)
- INSANE is pretty much a full-on no-holds-barred install of SCSv30, including options that I don't really use myself.

Pretty much all the difficulty options that you could choose at install time on v30 are now controlled this way. Because you might want different settings on different components, there's an innate power (I call it a "difficulty widget") granted to your character that lets you override the difficulty slider on a component-by-component basis (so that you might want dragons on INSANE, mages on HARDCORE and mage buffing on IMPROVED, say). If you don't want to use the difficulty widget, you can do this override directly from the console too. (There are also some hidden difficulty settings that you can only access within the difficulty widget - if you want all archmages to get HLAs, for instance, that's difficulty 7.)

There are various reasons for doing this:

(i) it simplifies my install process very substantially, and lets me fine-tune the difficulty options for a creature without having too much install-option bloat.
(ii) it makes decisions about difficulty level less irrevocable for players. I often read accounts of people's experience with SCS where they like some bits but find others too hard work. Now they can tweak this in a matter of monents during play, rather than needing to spend hours reinstalling.
(iii) it makes it easier to support the wide range of difficulty preferences. Case in point: some people like to play SCS with every archmage getting HLAs, and so that's a valid install option in v30, but it's also a brutally difficult option, and it's easy for other players to install it without realising how difficult it is. By gating content like this behind a very high difficulty setting, I think I do a better job of communicating to players what to expect.
(iv) it gives me the option to support players who are intimidated by SCS difficulty but who might still like some of the lighter-touch bits of SCS's AI - smarter calls for help, say, or willingness to use a different range of spells, or to use the Spell Revisions spell system.

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.