DavidW

The AI rarely needs to know what spell has just been cast by an opponent, so the issue doesn't really arise. It's responsive to the effects of spells, but those are tracked by things like STATE_CONFUSED, not by the spell name. That said, swapping Chaos for Cone of Cold will confuse SCS in a different way: when enemy Avengers learn spells. They probably will be confused and will try to cast Cone of Cold in situations where Chaos would be appropriate. There's only so much I can do about that without looking into the guts of every kit mod: I normally assume that mods won't replace a spell with a completely different one and leave the resref unchanged, but unfortunately SR chose to do so. (The compatibility-friendly thing would be to introduce a spell with a new resref and then swap GA_SPDR501 for GA_[new_resref] in the Avenger CLAB file.)

I'm not really sure how to answer that. It's not as if I ever intentionally release unstable versions; however, testing in the wild usually produces instabilities. I'm not currently aware of anything significant but I only do updates as and when I have time and I only carefully comb this thread when that happens. Professional software would have a bunch of beta or prerelease versions, a further assessment period, then an official 'stable' release, but this is not professional software, it's a hobby project I do in my spare time (and even for professional software the 'stable' release isn't always).

If you don’t have the NPC customization component installed then this is vanilla-game behavior: no other part of SCS messes with NPC xp.

Just look at the IESDP (or NI) for things like this.

The wavs are at +0x30 and after in the ambient structure.

Cycle through all the ambients with GET_OFFSET_ARRAY. (Look at the WEIDU tutorial on it.)

That switch is obsolete (iirc) - I must have missed it when updating the readme.

https://github.com/Gibberlings3/Descriptifier

This isn’t’t really in SCS’s scope.

If you want the nearest one, do SpellCastOnMe(Nearest([PC],0). (Iirc)

OK: some of this is easy to fix. the deleted dragon plate text was a dumb error: I was deleting too enthusiastically, and ended up deleting any text row starting with 'D'. (!) I hadn't anticipated complex alignment restrictions because the vanilla game seems to use only one set at a time, but they're not too hard to allow for. Extending the previous fix to the more minimal itemdesc_armor is easy enough. These are all corrected on github now. The other issues are a bit more fundamental. The converter generates basic details like AC, usability restrictions, weight, speed factor, etc. directly from the CRE file, and just deletes those details from the description before rebuilding them. (So your 'Lawful Good characters' line isn't being split up: it's just being deleted, and then the converter was adding 'Lawful-aligned characters' and 'Good-aligned characters' as a result of parsing the usability flags.) But it's not viable to auto-generate special abilities (or at the least: it's not viable in the time I was willing to give to the project!) so those are just left in place from the original description text. For the most part I couldn't work out any systematic conventions for where that information is supposed to go in the STATISTICS block - oBG2 seems to put it in any old place - so I just let it float to the top of the STATISTICS section and rebuilt the standard block underneath it. (Exception: there seemed to be a systematic convention that 'Special: xx' or 'Bonus: xx' went underneath the Damage: line in weapon descriptions, so I think I do reproduce that.) If you can describe (what you take to be) the actual conventions for how oBG2 STATISTICS blocks lay out special abilities, I can try to replicate them.

SpellCastOnMe([identifier],0) returns true if the object that cast a spell on the creature matches the identifier.

Why would that matter?

You are missing something. A (simplified) SSL block to, say, cast Magic Missile on a nearby enemy might look like IF TRIGGER TargetBlock(PCsInOrder) TriggerBlock(SpellTurn|MinorGlobe) THEN DO Action(Spell,WIZARD_MAGIC_MISSILE) END and would expand into IF HaveSpell(WIZARD_MAGIC_MISSILE) See([PC]) !CheckStatGT([PC],0,MINORGLOBE) !CheckStatGT([PC],0,WIZARD_SPELL_TURNING) THEN RESPONSE #100 Spell([PC],WIZARD_MAGIC_MISSILE) END IF HaveSpell(WIZARD_MAGIC_MISSILE) See(SecondNearest([PC])) !CheckStatGT(SecondNearest([PC]),0,MINORGLOBE) !CheckStatGT(SecondNearest([PC]),0,WIZARD_SPELL_TURNING) THEN RESPONSE #100 Spell(SecondNearest([PC]),WIZARD_MAGIC_MISSILE) END IF HaveSpell(WIZARD_MAGIC_MISSILE) See(ThirdNearest([PC])) !CheckStatGT(ThirdNearest([PC]),0,MINORGLOBE) !CheckStatGT(ThirdNearest([PC]),0,WIZARD_SPELL_TURNING) THEN RESPONSE #100 Spell(ThirdNearest([PC]),WIZARD_MAGIC_MISSILE) END On your proposal we'd only get the first block. Now suppose the three nearest PCs to the caster are, in order, (1) Aerie, who is protected by Minor Globe of Invulnerability; (2) Nalia, who is protected by Spell Turning; (3) Minsc. The object identifiers [PC], SecondNearest([PC]), and ThirdNearest([PC]) resolve, respectively, to Aerie, Nalia, and Minsc. The first and second blocks' trigger sections return false. The third block triggers, and the mage casts Magic Missile at Minsc. On your proposal, the first block returns false, because Aerie has Minor Globe. The script doesn't check Nalia or Minsc; it moves on to whatever its next spell is. Sequentially checking multiple targets for the same spell is space-consuming and tedious to do manually (this more than anything else is what I wrote SSL for) but it's central to how SCS spell-targeting works.

Oh, yes, I missed the no-description possibility. I read the UNIDENTIFIED_DESCRIPTION field, get -1, try to look up strref -1 in dialog.tlk, and hijinks ensure. New version fixes it. (I've put this on github to make it easier to update.) As for kits: it would be very easy to add them to the usable/unusable list, but it looked to me as if classic BG2 usually doesn't do this? E.g armor isn't marked as unusable by kensai, potions aren't marked as unusable by wizard slayers. Happy to do whatever's more sensible here - I've made only a fairly cursory examination of classic BG2's display conventions.

no mod hosted here can be called 'forgotten'

Can you post the contents of your 'weidu.log' file?

FWIW, here is code that just enables the extended night for an area: DEFINE_ACTION_FUNCTION are_extended_night STR_VAR are="" BEGIN // get the WED file; add the extended_night flag COPY_EXISTING "%are%.are" override READ_ASCII 0x8 wed // get wed file WRITE_LONG 0x48 (THIS BOR BIT6) // set extended night // already done? If so don't worry ACTION_IF !FILE_EXISTS_IN_GAME "%wed%n.wed" BEGIN // clone the wed file COPY_EXISTING "%wed%.wed" "override/%wed%n.wed" READ_ASCII 0x24 tis WRITE_ASCIIE 0x24 "%tis%N" BUT_ONLY // clone the tis file COPY_EXISTING "%tis%.tis" "override/%tis%n.tis" // clone the PVRZ files OUTER_PATCH_SAVE pvrz_base "%tis%" BEGIN DELETE_BYTES 0x1 1 // get the (dumb) BD convention for PVRZ file names END ACTION_CLEAR_ARRAY pvrz_copy OUTER_FOR (digit1=0;digit1<10;++digit1) BEGIN OUTER_FOR (digit2=0;digit2<10;++digit2) BEGIN ACTION_IF FILE_EXISTS_IN_GAME "%pvrz_base%%digit1%%digit2%.pvrz" BEGIN COPY_EXISTING "%pvrz_base%%digit1%%digit2%.pvrz" "override/%pvrz_base%N%digit1%%digit2%.pvrz" END END END // clone the light map COPY_EXISTING "%tis%lm.bmp" "override/%tis%ln.bmp" END END If you include this function and just do LAF are_extended_night STR_VAR are=ar3300 END then extended night should work without CTDs. That said, this won't give you all that you want, because the new 'night' TIS is just a daytime TIS, so it won't get dark. You still need to recolor the TIS. But it might be helpful to use this as a starting point, so that at least you know the game isn't going to crash on you.

I've written a bit of code that tries to automatically update the 'STATISTICS' field of an item description. It automatically sets the standard weapon and armor features, the weight, and (on classic BG2) the 'usable by/unusable by' descriptions. The description is formatted in either EE or classic format, as appropriate. The code can't automatically build special details like bonuses to hit against certain creatures, on-equip powers, or special abilities, but it does leave them in place from the existing description. I've packaged it as a mod for clarity, but there are really only 2 files: the code (lib_itemdesc.tph) and a tra file (dw_itemdesc.tra). You need to INCLUDE the former and put the latter wherever you keep your .tra files, and you need to set the variable 'sfo_tra_loc' to the path for your tra files. Here's an example of use: INCLUDE "%MOD_FOLDER%/lib/lib_itemdesc.tph" // includes the library OUTER_SPRINT "sfo_tra_loc" "%MOD_FOLDER%/lang" // needs to point to wherever you keep tra files LAM itemdesc_initialize // do once, to set the code up COPY_EXISTING "chan03.itm" override // whatever your item might be LPF itemdesc END BUT_ONLY There's also a much more lightweight version that just updates the armor string: INCLUDE "%MOD_FOLDER%/lib/lib_itemdesc.tph" // includes the library OUTER_SPRINT "sfo_tra_loc" "%MOD_FOLDER%/lang" // needs to point to wherever you keep tra files LAM itemdesc_initialize // do once, to set the code up COPY_EXISTING "chan03.itm" override // whatever your item might be LPF itemdesc_armor END BUT_ONLY EDIT: I've moved this to github. Gibberlings3/itemdesc: Automated generation of item descriptions (this is a tool for mod-users) (github.com

Thanks - this is a really helpful detailed run through. Will attend to shortly (may end up not being for a week or two for RL reasons.)

Just creating a 'night' copy is fairly trivial, iirc. Copy the tileset and add an 'N' suffix; copy the light map and change 'LM' to 'LN', and set the extended night flag. There might be one or two more steps (I haven't done it for a while) but that's basically all you need. To get different lighting effects, you need to alter the lightmap, the bitmap that determines lighting. To actually get beams of visible light from the windows, and the like, you need to alter the artwork.

Due to the technical complexity of the mod, this is a rare example where it's probably best installed after SCS.

That's compatible with my theory: if SCS detects an Acid Storm spell, it won't install its own, and it assumes anyone else who's installed it has provided a scroll. I suspect some earlier mod in your install is doing a partial/broken install of Acid Storm.

Guest Mantis: just on time management grounds I can’t help with problems either with old versions of the mod or old versions of the EEs. palanthis: no, I can’t confirm T&B is compatible. I expect it is, though, since its author usually codes with SCS in mind. & yes, install SCS last.

You'll need to post your actual mod list (weidu.log is simplest). My guess is some other mod in your list has installed Acid Storm but not provided a scroll.