DavidW

As discussed here, the version of DS used in SR (and SRR) creates some (fairly edge-case) bugs due to removing duplicate entries from stats.ids. The more up-to-date version of DS in SCS avoids that (and has other minor advantages) but wasn't previously compatible with SR because it required AUTO_EVAL_STRINGS (which is part of my standard modding environment but breaks SR). The new version of DS I've just coded (see link here) doesn't require AUTO_EVAL_STRINGS, so you might want to update.

& yes, checking the code (and SCS's readme) that section is a verbatim copy from Tactics' "Improved Druid Grove", untouched in SCS since 2011 (and even that was just to fix a namespace problem).

This is a fairly belated comment, because I mostly did it a year ago, but I've coded a new version of Detectable Spells (v4.0.1). You can download it from the SCS github repo (it's not in the most recent live release of SCS). Just put ds.tph somewhere in your mod folder structure, INCLUDE it, and then run the 'detectable_spells' function. It works on the EE games (though it's not all that sensitive to IWD) and on the classic ToB engine, with or without ToBEx. This was a recode from scratch so I can't that easily describe fine-grained changes, but I think it's pretty solid (it's been loose in SCS and Ascension for a year or more without any bug being traceable to it). One of the main changes in this version is that it's radically easier to add detection effects to new spells, over and above the baseline ones included in ds.tph itself. But the use cases for that are relatively niche so ask me if you want them.

I can reproduce this - it shows up in classic BG2 but not in BG2EE, because an opcode is interpreted differently. Thanks for catching it. I'll sort it out next time I do an update. (May not be imminent, sorry.)

Although it's also true that SCS's AI assumes it's fighting level-appropriate adventurers - I suspect I could write anti-Hobgoblin AI for the SCS wizards that would do a lot better against large numbers of low-level mooks.

I suspect it's mine ('improved minor encounters') though I have a feeling I might have borrowed it from Tactics. I don't think artificiality bothers me: if there are hostile plant creatures on the route to Faldorn, my working assumption would be that the Shadow Druids placed them deliberately.

To be fair, they delivered on the ‘far easier to mod in general’ promise, at least by the time IWDEE came out. The EE engine is way beyond classic BG2 now, even with ToBEx.

Back in 2004, when I was first messing with AI for the BG games, I discovered exactly this issue in BG1. So far as I can see it's a hardcoded feature of the engine and can't be worked around. It's the main reason I stopped trying to do AI for BG1 and moved to TUTU.

PfMW, almost certainly. I don't know why you didn't see it being renewed in the log.

Officially, in 2nd edition AD&D, 'bonus to THAC0' and 'attack bonus' are basically synonymous - they're used that way by the text in the 2nd edition Players' Handbook that explains THAC0, certainly. But the spell descriptions in the Players' Handbook don't, on quick inspection, refer to THAC0 - they talk exclusively about 'attack bonus'. At a guess, that's because the text is in most cases taken over with little or no changes from the 1st edition AD&D Players' Handbook, which doesn't have the THAC0 concept. Later sources do use it - for instance, the spell descriptions in the 2nd edition Forgotten Realms Adventures hardback describe various spells as giving attack rolls 'at the caster's THAC0 with a +2 bonus'. 1990s-period TSR almost certainly didn't have the established style rules that (I would bet) WotC or Paizo have, so things are a bit inconstant from product to product. My own feeling, FWIW, is that it's better to talk about 'attack bonuses' than 'THAC0 bonuses' because of the pre-3rd-edition awkwardness that lower THAC0 is better. Strictly, '+2 to THAC0' is a penalty, but it reads so weirdly to talk about a -2 bonus that in practice, +2 is used to mean a 2-point bonus. (Similar problems arise for AC, of course - a ring of protection +2 gives -2 to AC.)

Polygons are part of the illusion of three-dimensionality. Character, and some spell-effect, pixels inside a polygon are dithered, i.e. drawn faded out, to indicate that the sprite is behind something. A tree, for instance, needs a blob on the search map (marking the region that you can't stand in because the tree is there) but also a polygon (marking the region where the tree is in front of you.

It's the smallest rectangle you can draw around all the object's vertices. Presumably the engine checks if a sprite is in the bounding box (which is trivial) before bothering to check if it's in the area itself (which is calculationally harder).

At a guess, your version of BG2EE needs updating.

I do understand (I think) but it might take a few days before I have a chance to address it.

It's not SCS (well, not intentionally anyway, and I can't see a way it could happen accidentally).

As for the clash between SR and AUTO_EVAL_STRINGS... I guess in hindsight it was antisocial for me to code the latest ds.tph to assume it. I'll see if I can work out a version that doesn't require it (it may be difficult; I've been coding with AUTO_EVAL_STRINGS for seven years...)

SFO definitely doesn't work without it, in that it does a sanity-check for it: /////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // Sanity check for AUTO_EVAL_STRINGS /////////////////////////////////////////////////////////////////////////////////////////////////////////////////// OUTER_SPRINT var testers OUTER_SPRINT players var ACTION_IF !"%%players%%" STRING_EQUAL testers BEGIN FAIL "AUTO_EVAL_STRINGS is not set (you need to include it in your tp2 preamble to use SFO)" END

Do you have AUTO_EVAL_STRINGS in your tp2 preamble?

Oh - got it. Yes, version 3.x has some functionality (installed via the ds_altered_spell function) intended to tell later mods how to allow for changes to spells when installing DS, and SR makes (a very small amount of) use of it. My view was that it wasn't really robust and changes would have to be allowed for explicitly to work, so I deprecated it in v4. I think the v4 DS should handle SR fine (well, at least as fine as the v3.9x DS) without that functionality. I would just add DEFINE_ACTION_FUNCTION ds_altered_spell BEGIN END somewhere, if you don't want to strip out the ds_altered_spell functions manually.

Are you sure? It looks like the unaltered v3.95 (which, absolutely, was written by Ardanis). SR's code uses DS to load a custom table of spell changes, but that table is empty in any case so it doesn't matter. Which macro is missing when you try SCS's version? I just tried installing it on a clean test mod (no other function libraries) and it seemed to work fine.

This works, I think (testing required). You need my extension of the ALTER_EFFECT family. DEFINE_PATCH_FUNCTION match_fog RET value BEGIN READ_ASCII 0x14 resource PATCH_MATCH "%resource%" WITH "\(%WIZARD_STINKING_CLOUD%D?\|%WIZARD_CLOUDKILL%D?\|%WIZARD_DEATH_FOG%D?\|%WIZARD_INCENDIARY_CLOUD%D?\|%CLERIC_WRITHING_FOG%\|RR#WI502\|DVCKILL2?\|DVWCKILL\|WAND13\)" BEGIN value=1 END DEFAULT value=0 END END COPY_EXISTING_REGEXP ".*\.spl$" override PATCH_IF INDEX_BUFFER ("\(%WIZARD_STINKING_CLOUD%\|%WIZARD_CLOUDKILL%\|%WIZARD_DEATH_FOG%\|%WIZARD_INCENDIARY_CLOUD%\|%CLERIC_WRITHING_FOG%\|RR#WI502\|DVCKILL\|DVWCKILL\|WAND13\)" >=0 BEGIN LPF CLONE_EFFECT INT_VAR multi_match=1 match_opcode=206 opcode=142 target=1 parameter2=icon_ref insert_point=99 STR_VAR match_function=match_fog END LPF CLONE_EFFECT INT_VAR multi_match=1 match_opcode=206 opcode=139 target=1 timing=1 parameter1=RESOLVE_STR_REF (@1000117) insert_point=99 STR_VAR match_function=match_fog END END BUT_ONLY You don't need the INDEX_BUFFER, it's there for performance. (COMBINING COPY_EXISTING with ALTER_EFFECT/CLONE_EFFECT can be slow.)

Use READ_SBYTE, which interprets a byte as lying between -127 and +128. READ_BYTE interprets it as lying between 0 and 255.

That makes sense. DS sorts stats.ids after appending all the new entries, but the sort used by DS 3.9x (the one in SR) is destructive, and ends up deleting duplicates. The version in SCS 33 (let's call it v.4.0) sorts nondestructively (iirc).

SSL itself doesn't need Detectable Spells. But you're probably using the SSL library (library.slb) that SCS uses? That has stats.ids entries that are added by DS.

In modding prehistory, there were a bunch of Detectable Spells, with G3 (iirc) eventually maintaining a more-or-less shared one. I recoded it, and more-or-less took ownership of it, quite early in SCS's history. (I think roughly when SCSII was released.) Since then, it's bounced around the small number of people who do tactical/AI modding in a sophisticated way - I've coded various versions, I think Wisp might have done one for aTweaks, and Ardanis has done a couple, including one that was used in Siege of Dragonspear. I released a new version along with SCS v32, and I think I still have ownership. Annoyingly, I seem to have managed to leave out version numbering on the current SCS version, and should reinstate it. But I think the version in Angel's mods is the current SCS version or near enough. In any case, taking the one from the current SCS edition is probably the best strategy. The version in SR is somewhat out of date and probably worth updating. Can you say more about the 'removing entries in stats.ids' issue - i.e. is that SR's version, or Angel's/mine, that's doing it? And which stats? (The current version shouldn't be able to remove stats.ids entries, but might be misbehaving.)