DavidW

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.

Compatibility fixes rather than bugfixes; but noted in any case.

I suspected something like that, though I haven't had a chance to test. Something funny probably happens when you do a forced weapon shift on a cursed weapon. Ideally Osmadi ought to be blocked from doing weapon-swaps, since he's presumably cursed. If I can't do that conveniently I'll just put it in inventory. Thanks to all for help finding this.

with or without SCS?

No thanks, I've no idea how to read .dmp. Will investigate.

& the game crashes a moment after that screenshot? I'll have another look. (Don't hold your breath, though; in the short run the best workaround is just to CTRL-Y him)

I have tried and failed to reproduce this bug. (I believe you! several other people have reported it. It's clearly something to do with SCS.) Can you give me: - your WEIDU.log - an exact description of how to cause the crash. (Attach a savegame if you like.) Incidentally, I think BGEE is now at 2.3, not 1.3 - but I doubt that's the issue.

enforce_thac0 ought to be restricted to humanoids (but I think isn't working correctly) so if your familiars aren't humanoids, this should be fixed in v31. If they are humanoids, you can avoid SCS here by using opcode 54.

True, although if you have a thief with detect illusions, the former can be removed without using any spells at all. So it isn't completely clear cut. That's a good point. Thief detect-illusions wasn't something I considered enough when writing SCS.

I don't regard that as a bug. The wording of the wish is: "I wish for my enemies' magical defences to be utterly destroyed!" It doesn't say "Unless they're protected from Spell Shield". And from a source-material perspective, Wish certainly shouldn't be being blocked by a sub-9th level spell. Having said which, if SR changes this it won't break anything in SCS.

Putting aside the issue of visual variety and just considering what's optimal, II + SI:Div needs two spells to penetrate, ST needs only one. But more generally, it's true that Spell Shield adds some flexibility here. When I wrote the buffing routines, SS hadn't been fixed. That's one reason I think it would be worth going through them again.