DavidW

Also, it would have led to illegal uses of Spell Trigger.

No, SCS won’t detect SPWI590 (it’s hard coded to avoid all the secondary spells for Spell Immunity; probably I ought to check hidespl instead). Incidentally, as of v32 I don’t use Spell Immunity in contingencies/triggers on SR installs.

No, it should be fine.

You could simulate adding an entry in the middle by adding it at the end but with a bunch of ~OR(2)!Global("BD_Saved_[NPC]",bd4500",0)!IsValidForPartyDialogue([NPC])~ added. Messy, though.

Yes, SCS dynamically patches the underlying string (that saves updating the scroll separately). It works out the patch automatically, and in this case the automatic code is making a mistake. It notices that Dispelling Screen (SPWI510) has secondary type SPELLPROTECTION, and so would be brought down by Spell Thrust. And it's right, in a sense! - but it doesn't realize that SPWI510 only persists for an instant in any case, since it's only job is to cast a secondary spell, SPWI510D. Given how much it uses secondary spells, I should probably leave it to SR to make sure its spell descriptions are accurate, and only apply this patch on non-SR installs. (I wrote it mostly with the IWD spell system changes in mind.)

It would help if I can’t reproduce the bug on clean SCS and can see a way it could be compatibility-related, but at the moment I think that’s unlikely and I’d rather not waste people’s time providing things I don’t need.

Actually I don’t need the WEIDU log yet. It’s probably internal to SCS. There’s no global shift that makes everything handle LOS correctly; it’s fight-by-fight. I’ll look at those examples when I have the chance. Are there others?

Looks good. Enjoy!

I have it set to 75 rather than to 100 by default because hitpoint_percentage determines where a creature's hp lie in the range minimum-to-maximum, and my default choice is to put them about 3/4 of the way along (higher than the 50% you'd expect from random die rolls, but short of being maxed out). That's an SCS design choice (SFO isn't always careful about separating out SCS design choices from tool functionality). The ini value should probably be included (my current local codebase sounds a warning if a nonexistent ini is checked, but that's not backported to SCS yet). I don't remember why I don't launch it in CRE_postbuild. Possibly because hitpoint spread is an active design choice; possibly just by mistake. Like I say, it's not code I use. Not initialising it is sloppy (in my ideal world, WEIDU would fail or at least sound a warning if you call a function with arguments it doesn't have) but I think harmless.

I can't argue with that. Looking more carefully, the first 8 bits of the EFF 2.0 format are left out when it's used internally to a CRE file. So although IESDP lists Power as 0x18, it's 0x10 on a CRE file. I obviously remembered this when I originally coded this section, but forgot it at some later stage when I added that entry. Thanks for catching it.

I'm not just ignoring it 'for now'. I thought I made clear that this was a tool for my own use, not something I'm supporting. Bits of it I haven't in fact used probably have all manner of problems. Using the default value for hitpoint_percentage is intentional. (Though the ini was originally supposed to be exposed for power players' use.) The missing arguments field is a bug that needs fixing.

No it isn't. This is a CRE v2.0 EFF field, not an ITM/SPL v1.0 field. SFO_autofunc is autogenerated. Just delete it, it'll be rebuilt. (But don't do it to fix the above)

Since as you say make_creature isn't code I'm using (or I think have ever used), I doubt I ever debugged it after initial coding.

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.