DavidW

At some point I'm going to need someone to explain to me how I release my own updated version in this Github framework ... as always I'm very grateful to people who release updates when I'm away, but when (if?) I get out from under work and toddler I'd prefer to use my own previous build as the starting point rather than build on others' code. (Among other issues, I would *strongly* prefer to handle SR compatibility through RequireBlock(Demivrgvs) in the SSL rather than through a separate fork.) Not, to put it mildly, an urgent issue! And many thanks to CamDawg and others for doing a v31 in my absence.

They do (or at least: they should).

Also, SCS scripts are adaptive (they install differently according to which magic items are in the game, whether some other mods are installed, which options the player selects at install time, etc) - that requires me to compile at install time.

These last couple are fixed in v31 (no ETA though)

What's the technique, as a point of interest? I was looking at this the other day for random reasons.

At least a sort of bug. I'll update DS.

See my reply to Alien. I don't use megamod installations myself and supporting quick installs on them is not a priority, absent detailed and specific advice as to how. But I don't know any lua and I'm not likely to learn any time soon.

The short answer is probably not. The long answer is that I test SCS on clean or lightly-modded versions of vanilla BG2 and BGEE/BG2EE, and if the install time stays below 20 minutes or so on a reasonably fast PC, I'm contentthat it's not a serious issue and I'd rather prioritise other things. Active support for a short install on megamodded installations is a bit beyond what I really support - I don't have megamodded installs as my main target. That said, if someone looks at the code and identifies specific ways to speed any given bit up, I'm happy to listen. (Though I don't recommend anyone puts the time in until v31 comes out as there are some significant under-the-hood changes - some of which will probably speed things up, others not!)

It's intended to be removed by cleric/mage spells and by the temple Remove Curse. It's clearly not working on some installs but I haven't yet got around to working out whether that's a mod incompatibility issue, a vanilla/EE issue, just a straight SCS bug, or some combination.

Yes, that's unintended and suboptimal.

It's Kreso's set of SR-based tweaks to SCS v30. I didn't have anything to do with it. (Normally this would irritate me a bit, as I wasn't asked - but I was pretty much uncontactable at the time, even by email, so I assume Kreso/Demi tried and failed to get in touch.)

fixed in v31

The ones that are bugfixes for SCS: probably. The ones that are vanilla bugfixes: possibly. The ones that are new content and tweaks: probably not.

I think it includes equivalent patches. (I've worked through the BWS list with thanks, but the implementations are often a bit crude.)

Known bug (known from your own report earlier), fixed in v31.

2) SSL library files now have two more options, alongside the existing TRIGGER and TARGET: TRIGGER_REPLACE and TARGET_REPLACE. These define triggers and targets (respectively) that destructively overwrite the existing trigger/target (the SSL default is to add to the existing one). So: TRIGGER=Imprisonment !CheckSpellState(scstarget,STATE_ENRAGED) TRIGGER=Imprisonment !CheckSpellState(scstarget,IMMUNE_TO_EVERYTHING) leaves the STATE_ENRAGED check in place, whereas TRIGGER=Imprisonment !CheckSpellState(scstarget,STATE_ENRAGED) TRIGGER_REPLACE=Imprisonment !CheckSpellState(scstarget,IMMUNE_TO_EVERYTHING) removes the STATE_ENRAGED check. Obviously this makes the order of libraries fairly crucial. (The point of the functionality is to make it easier to use custom library entries, e.g. for Spell Revisions compatibility.)

For the two or three people who use SSL: The version of SSL that will ship with v31 of SCS has two new features: 1) SSL now recognises a set of "Boolean variables", which can be defined when it's run using the -b tag: e.g., ssl.exe testscript.ssl -l ssl/library.slb -o stratagems_external/workspace/ssl_out -b WIZARD_MAGIC_MISSILE WIZARD_FLAME_ARROW sets Booleans WIZARD_MAGIC_MISSILE and WIZARD_FLAME_ARROW. Booleans are referenced in SSL scripts via SSLBoolean(firstBoolean|secondBoolean|etc) which will blank the script unless at least one Boolean is set. The point of this (over and above SSL's existing variables) is that Booleans are evaluated right before a given block is printed (whereas standard SSL variables are evaluated pretty much at the start). So in particular, SSL action arguments can be placed in an SSLBoolean command. Example: BEGIN_ACTION_DEFINITION Name(Spell) TRIGGER SSLBoolean(scsargument1) HaveSpell(scsargument1) ACTION RESPONSE #scsprob1 Spell(scstarget,scsargument1) END IF TRIGGER Target(NearestEnemyOf(Myself)) THEN DO Action(Spell,WIZARD_MAGIC_MISSILE) Action(Spell,WIZARD_CHROMATIC_ORB) compiles to IF See(NearestEnemyOf(Myself)) HaveSpell(WIZARD_MAGIC_MISSILE) THEN RESPONSE #100 Spell(NearestEnemyOf(Myself),WIZARD_MAGIC_MISSILE) END i.e the CHROMATIC_ORB block is skipped.

Have you ever heard of the fact that if "I won't do it, no body else will bother do it either ?" It's not like you couldn't bother to assign the values to the -known and well documented files in question, if they don't have a value assigned, they all have a +x in their names and all. Ouh but you can, actually. So long as won't with mod added, that's the line you shouldn't cross. Or shouldn't bother to try to. Not for the first time, I have no idea what this means. I think it's a judgement call whether subtledoctor's way of detecting armor types or mine is better. Ultimately, there's no 100% reliable way. And ? Iow. So what ? So there's no real reason to think of it as an "enchantment" field and not a "weapon enchantment" field.

Well, I looked, and nominate the chain09-chain20.itm for your observation, they have appropriate enchantment levels... the 01-08 and 21 might be stupidity of itm maker, but what else is new. It's not like the files are 17 years old, ouh yeah, they are.... spoilers, they are likely to come strait from BG1. Well, I looked at BG2EE file, if that matters for you. I'm pretty sure that there's no reason for the enchantment field to be accurate: it's inert except for weapons.

The "enchantment" field at 0x60 is really just for weapons - it's what spells like Mantle use to determine if you can hit the creature. So it's not usually set for armor. If you want something more robust than checking the string, you can look at the AC bonuses vs specific types. (So leather armor gives a 2-point AC penalty vs piercing and missiles, while studded leather gives bonuses.) The following works, I think (tested, but not that thoroughly): //////////////////////////////////////////////////////////////////////////////////////// /// Armor-type-finding function /// /// use example: LAF armor_type STR_VAR item=chan01 RET success type END /// /// success=1 if we find the armor type, 0 if we don't /// type is one of: file_does_not_exist, not_armor, robes, leather, studded_leather, hide, chain, splint, plate, full_plate, scale, unknown /// /// if we can't work it out, but it is armor, we try to guess (but still set success=0) //////////////////////////////////////////////////////////////////////////////////////// DEFINE_ACTION_FUNCTION armor_type STR_VAR item="" RET type success BEGIN OUTER_SET success=0 ACTION_IF FILE_EXISTS_IN_GAME "%item%.itm" BEGIN COPY_EXISTING "%item%.itm" override // start by looking at the category, to confirm it's actually armor PATCH_IF !((SHORT_AT 0x1c)=2) BEGIN SET success=1 SPRINT type not_armor END PATCH_IF !success BEGIN // look at the animation type READ_ASCII 0x22 anim_type (2) PATCH_MATCH "%anim_type%" WITH 2W 3W 4W BEGIN // robes SET success=1 SPRINT type robes END // end of 2W 3W 4W section 2A BEGIN // leather armor - could be ordinary,studded,hide LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END PATCH_IF (piercing="-2" && missile="-2") BEGIN // either leather or hide PATCH_IF (SHORT_AT 0x26)=6 BEGIN // if you need strength 6 (rather than 4), it's hide SET success=1 SPRINT type hide END ELSE BEGIN SET success=1 SPRINT type leather END END ELSE PATCH_IF (slashing=2 && piercing=1 && missile=1) BEGIN // studded leather SET success=1 SPRINT type studded_leather END ELSE BEGIN SET success=0 SPRINT type leather // guess leather END END // end of 2A section 3A BEGIN // chain or splint LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END PATCH_IF (slashing=2 && crushing="-2") BEGIN // chain mail SET success=1 SPRINT type chain END ELSE PATCH_IF (piercing=1 && missile=1 && crushing=2) BEGIN SET success=1 SPRINT type splint END ELSE BEGIN SET success=0 SPRINT type chain // guess chain END END // end of 3A section 4A BEGIN // plate or full plate LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END PATCH_IF (slashing=3 && missile=0 && piercing=0) BEGIN // plate mail SET success=1 SPRINT type plate END ELSE PATCH_IF (piercing=3 && missile=3 && slashing=4) BEGIN SET success=1 SPRINT type full_plate END ELSE PATCH_IF (slashing=3 && missile=1 && piercing=1) BEGIN // scale male - just a couple of dragon armors SET success=1 SPRINT type scale END ELSE BEGIN SET success=0 SPRINT type plate // guess plate END END // end of 4A section DEFAULT SET success=0 SPRINT type robes // guess robes END END BUT_ONLY END ELSE BEGIN OUTER_SET success=0 OUTER_SPRINT type file_does_not_exist END END //////////////////////////////////////////////////////////////////////////////////////// /// Helper function. Returns the vs-type bonuses for armor //////////////////////////////////////////////////////////////////////////////////////// DEFINE_PATCH_FUNCTION read_armor_bonus_vs_type RET slashing piercing crushing missile BEGIN DEFINE_ASSOCIATIVE_ARRAY type_map BEGIN 1=>crushing 2=>missile 4=>piercing 8=>slashing END PHP_EACH type_map AS discard=>value BEGIN SET "%value%"=0 END GET_OFFSET_ARRAY offsets ITM_V10_GEN_EFFECTS PHP_EACH offsets AS discard=>offset BEGIN PATCH_IF (SHORT_AT offset)=0 BEGIN // is an AC modification READ_LONG (0x8 + offset) type PHP_EACH type_map AS key=>value BEGIN PATCH_IF type=key BEGIN READ_LONG (0x4 + offset) modifier SET "%value%"=modifier END END END END END

I realise I've slightly lost track of which is the "official" version of SR. On the one hand, the one on the download page is still v3 (or rather v3.1.03), and v4.x is still noted as "open beta"; on the other hand, v4.x seems to be the one in standard use, and it's the one assumed by the unofficial SCS-for-SR mod that was written in my absence. I ask because I need to know what to assume for SCS. Can someone advise?

I don't really want to do this because it gets me into the open-ended process of having to anticipate every third-party mod's change to a combat script, given that SCS rewrites pretty much the entire AI system in the game. Cluttering my scripts with commands that are only there because of other mods that might or might not be installed makes the code harder to read and to maintain. Ultimately, it isn't really possible for multiple mods in IE to make compatible non-destructive changes to the same script - hence the suggestion I made that you insulate your change in a different script that other mods won't edit, that drops Demogorgon's items on the same condition that the vanilla script uses to check for his death. As you point out, that will fail if his death conditions are changed (away from their vanilla default, i.e. <30 hit points and the DemoEffects local variable unset). However: - SCS doesn't change those conditions; - if some other mod does, it almost certainly does so by destructively rewriting DEMOGOR2 as well, so your changes would be overwritten again

Intentional, and not a bug; see my comment at SHS.

Some chance, yes. Don't hold your breath.

No idea. Mostly bugfixes, not entirely.