DavidW

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.

ouch.

But is it EET-compatible?

It’s caused by changes in Wish in BG2EE. v34 fixes it.

I'm not sure of drawing my next breath. But if you saved a game when Jaheira had some spells and then reloaded that save and she had different spells, the only feasible explanation is that the spell filenames changed between saving and loading. SCS doesn't edit the savegame itself. And even if Jaheira didn't join the party, she's present in your savegame as soon as you meet her. (The version of Jaheira in my local copy has the correct spells.) In any case, if you're unsure, just test it. Start a new game, recruit Jaheira (she's in the starting dungeon, assuming you're playing BG2; otherwise, just create a copy with the console.) Should only take five minutes.

This is theoretically possible but I doubt it happens in practice. It is extremely difficult to produce new quest content for IE games, at least if you want reasonable production values - it requires mastery of a wide range of skills (AI scripting, artwork, area design, dialog design, actual ability to plot and write) and most individuals only have a subset. So there aren't many high-quality adventures and those that exist are well known. (Prove me wrong by linking to a 'small, excellent, forgotten adventure'!)

I'm guessing you had a savegame for 33.7 and then loaded it into 34.3? If so some of the spells may have shifted: they get assigned resource names dynamically and they're not guaranteed to be the same between versions (or between installs of the same version, if you change other bits of your mod load). The workaround is to fix it with a savegame editor; future spells she gets when she levels should be fine. (Updating mods mid-game generally runs the risk of this sort of thing, hence the usual advice to start a new game - though I can quite see why that's awkward if you're partway through a long playthrough.)

They ought to be fine. I use Cam's code (the one included in WEIDU) as a base and then just add other functionality. If you don't use that other functionality, the results should be identical. It's always possible I broke something, of course, but I don't think so (I've been using these modified functions for a while, including in SCS and (iirc) Ascension, and problems haven't arisen.

I was talking about how enemies might deal with it (this is how SCS tries to deal with it). I'm not disputing that it's overpowered though! (& SCS mages use blindness.) Oh yes, that does ring a bell. I don't know how well SCS handles that; not terribly, I assume, or I'd have heard about it, but I don't allow for it explicitly.

SCS won't do this if it detects SR, but only because it assumes you've done it already (back in the day this was part of Demi and my discussions of how to align SR and SCS). SCS will get very confused if you use it without this. Incidentally, this is also vanilla-game behavior on the EE as of 2.6.

Except that it's relatively readily reversible. And you do have a few combat options if blinded: run around in confusion, cast self-targeted AoE that you're immune to, summon monsters.

OK, cool. Yes, that's a common situation, and you have the right solution: if you don't want SCS to handle your NPC's AI, you just need to write your own AI for them (which can just be a renamed copy of a vanilla script - all that matters is the name). Provided your script uses your modder prefix, SCS will definitely ignore it. (But make sure you don't leave a WTASIGHT or something lying around in the script list along with your custom script.)