DavidW

Just to expand on Jastey's comment: whether you get the 'blocked' icon or the travel-trigger icon is determined by the search map - AR4400SR.BMP in this case. (It's the same file that determines which areas are impassible, and which areas make which footstep sounds.) Edges of the map that you can travel off are colored in a pale blue - you'll see it if you open these files in near Infinity or in an editor. Normally I am super-keen on compatibility, but in this case, editing the search map of an existing area is so rarely done that you could cautiously risk just editing AR4400SR.BMP and distributing the edited version. Export it from Near Infinity and use an editor. It's best to use as low-tech an editor as you can - MS Paint is good, iirc - because the Infinity Engine makes certain assumptions about how search maps are encoded that can get scrambled by sophisticated programs like Photoshop.

You mean the fragments of documentation in the mod folder itself, or the G3 thread on 'functional WEIDU'? (I'm guessing the latter, but I should say that they're a very partial effort, before I realised the amount of work was way more than I was willing to do for the very small number of people it would benefit.) The main thing that the mod folder documentation doesn't mention is that the 'instruction=>value' pairs in SFO's inputs are actually function-argument pairs. 'instruction' is a patch function that takes 'argument' as a STR_VAR (and also some other arguments to facilitate looping through extended offsets); 'value' actually gets plugged into the 'arguments' slot. About three quarters of those patch functions are built automatically, and do simple things like writing to specified offsets; the others are handwritten. The 'functional WEIDU' thread talks a bit about that. What the functional WEIDU thread doesn't tell you is that there is considerable preprocessing done on the argument part of the function-argument pair before it gets slotted in. In patching effects, for instance, the following are legal: duration=>"if duration>0 then duration*2 else 0" resource=>"resource in [spwi205->spwi205a sppr304->sppr304a default->no_change]" With the benefit of seven years' hindsight, it's unclear if that was a good idea - it is in principle very powerful, and drastically simplifies writing some bits of code, but the slowdown is significant and I don't use it *that* much. The underlying code for the preprocessing is in lib_evaluate. In general I would be wary about using SFO to do large-scale patching if you can help it, on speed grounds. It's best suited for complex editing of individual resources (it's great for populating areas in quests, for instance, or doing surgery on specific spells). But applying relatively simple patches to large numbers of spells, say, is much much faster using WEIDU's built-in ALTER_EFFECT family of functions (or my extension of them) than using SFO. And I'd strongly advise against using SFO's 'edit_all_<object>' functionality - if you're looping through every object in the game there will be way faster ways to do it. If necessary, do a hardcoded loop through everything to obtain a resource list, then apply SFO code to that list. (There are lots of examples of this in SCS.) Start a thread. (If there are actual bugs, they're likely to entail SCS (or WoP) bugs.) From the department of expectations management: I'm happy for you, or anyone, to borrow SFO and play with it, and even use it in released mods (with credit) but it's as-is - I don't support it in any way and I'm not at all guaranteeing help with any issue. (Much as with SSL.) I decided a long time ago that working SFO into a genuine community resource wasn't viable unless I was prepared to change my hobby activity from modding to tool-building.

Look in Near Infinity at how other axes in BG(2)EE are coded. You'll see that UNUSABLE_BY_DRUID is unchecked, but that they have an opcode (319) that restricts item use by class, and that blocks druids. Shamans don't count as druids for this check, so they get to use it.

I recommend it to *me*! For anyone else, it depends on use case, programming experience, and willingness to dig through code. It’s significantly more powerful than pretty much any other tool out there - on the other hand, it’s very abstract, almost completely undocumented, can run quite slowly if you’re not careful, and I’m unlikely to provide more than minimal help with it. You have to refer to the code itself quite a lot to use it. The intermediate choice is the ‘sfo_lite’ library which Ascension uses. That’s also undocumented (though it’s somewhat more likely to get documented in the medium term) but it’s conceptually simpler and Ascension’s code itself gives lots of examples.

Yes... sorry, must have had the page number wrong and thought it was recent!

I didn’t intend “whimsical” as an insult, just a statement of personal preference. In the right context, I like whimsy! It’s not to my taste in the Baldur’s Gate setting, and so I wasn’t interested in getting involved with the project myself, but I’d never think that judgement was anything other than a matter of taste. I apologize if it came across as ridicule- it wasn’t intended that way.

It's a direct quote from the 3.5e Player's Handbook version of the spell - so, yes, surely flavor text.

You're welcome. I should probably try to check for game version, but it's not that simple to do.

It looks to me as if you're using an old version of BGEE. If so, update to 2.5.

Hmm. Thinking about this more, "Summon lesser water elemental" is one of the few strings that is added by SCS, not just grabbed from IWDEE. SCS uses HANDLE_CHARSETS to convert all its tra files to UTF-8 on EE installs: the converted files live in weidu_external/lang/stratagems/[language]. Jazira, maybe you could check that your file is being converted correctly. I have to admit that this is not a side of modding that I know well, being monolingual in English.

I've taken to just doing REPLACE_TEXTUALLY "\(%TAB\|%LNL%\|%MNL%\|%WNL%\)" " " before doing any complicated search-and-replace on a BCS file.

It’s probably an issue with “NPC customization”. Try turning on the Party AI for a couple of seconds.

You don't need the fix. (I've also replied in the other thread; Jastey's reply there looks right as regards compatibility.) I recommend BG2 tweaks, which makes a lot of small aspects of the game smoother (but don't install it blindly- look at what you want to use in its readme, and err on the side of caution). The Calling and Lure of the Sirine's Call are nice little quest add-ons. It's actually a long time since my own last playthrough so I'm not very up to date on good mod suggestions.

Also, look at dates when you are assessing install advice. That thread about a fix to SCS is from 2016, but SCS v33 was released in 2020. Normally, critical bugs in mods get fixed when a new release is out, so advice on fixes is then outdated.

Take it up with Bioware.

That's not what the spell does.

I think you may be forgetting just how dumb enemy mages are in the unmodded game. Never mind working out how to deal with II+SI:Div - most mages can't even deal with II alone. Hardly any mage in the vanilla game tries to take it down; hell, hardly any mage in the vanilla game checks for it before targetting a single-target spell. You can paralyze most of them just by standing next to them with II running. The more interesting question would be: how *could* a mage, using the unmodded spell system, deal with II+SI:Div? And there I agree, they can't, basically. Add SI:Abj and the logical circle pretty much closes. I realized that very early in the evolution of SCS; Wes Weimer realised it too, which is why every single Tactics mage of level 16+ uses II+Si:Abj+Si:Div in their Spell Trigger. I looked for the minimal set of changes that I could find to the spell system that made mage combat functional, and ended up with the antimagic-bypasses-II trick. SR, of course, has a very different design goal and is happy to make much more sweeping changes - which is fine, but not what I was (or am) interested in, though I have gone a long way towards supporting SR for those who do like it that way It's in practice slightly different, because there are counters to invisibility other than divination spells - noticeably thieves' Detect Illusion ability and the fact that liches/dragons/fiends can see through invisibility. (Also, it protects your other illusions, like Mirror Image). It stops Breach on SCS but not on unmodded games (the unmodded game treats Breach as an anti-spell-defense attack, so it bypasses everything. That's something else that's basically not counterable - hence, again, SCS's tweak.) There is no constraint on having multiple SI variants active, in the unmodded game or in SCS, though there is a perennial myth that there is. It doesn't need simplifying, in that it's perfectly possible to have an effective and enjoyable mage-battle AI inside the system as is. One might have a fun play experience using a mod that simplifies it; that's a different question.

What mods do you have installed other than SCS?

Fair enough - but you are making sharply critical comments about the vanilla system, and its interaction with SCS, and those comments aren't based on fact.

Unless I'm missing something, SCS isn't so easily thwarted. Ruby Ray to bring down the SI:Div, then Truesight to penetrate II.

Can you post your WEIDU.log ?

Fair enough! The 'ds_make_detectable' function that entropy_shield_abjuration uses has quite a lot of processing built into it. Firstly it checks if 'id' (the stat in question, e.g. PRIORITY_DISPEL) is present in STATS.ids in a legal place (i.e. in the shortish range of stats that opcodes 233 and 282 can handle, or - on a classical game, if ToBEx is installed - the longer range that ToBEx opcode 318 can handle). If it's not, and if you're on an Enhanced-Edition game, it checks SPLSTATE, adds the stat if it's not present, and adds it via opcode 328. If you're not on Enhanced edition, it checks for ToBex, and if it finds it, it adds the stat as a new stat in STATS.ids, and applies it with opcode 318. If it doesn't find ToBEx, it gives up. See ds/ds.tph if you want the gory details!

Incidentally, the existing ENTROPY_SHIELD spellstate is already assigned to Entropy Shield (it gets assigned by the main Detectable Spells run, before the spellsystem modifications are installed - look at ds/ds_iwd.tpa). Since that spellstate uniquely identifies Entropy Shield, it's of course right in principle that my AI scripting could work with that spellstate, either by modifying its checks according to whether the Entropy Shield changes are present, or just assuming they are on the grounds that SCS assumes the standard shifts. Applying the SI_ABJURATION spellstate is a relatively quick-and-dirty alternative: since for the most part the AI should react to someone protected by modified Entropy Shield as if they were protected by a combination of original Entropy Shield and SI:Abjuration, setting that spellstate goes most of the way to allowing properly for Entropy Shield's modifications, without any need to tweak things at the script level. At the time that SCS v32 was released, that was of particular significance, because the changes to Entropy Shield were new and might have needed modification, and it was helpful to be able to do that without having to unpick a collection of script changes.

If the button's greyed out, that implies that Imoen doesn't have the prerequisites for dual-classing. She needs DEX 15 and INT 17. Could some other mod have changed those values?

If you want to patch all of them, detecting them isn't a problem. Just do GET_OFFSET_ARRAY and then loop through with PHP_EACH, as demonstrated in the WEIDU tutorial (except that the offsets for triggers are prelisted - ARE_V10_REGIONS - and so you don't need to enter them manually).