DavidW

46 minutes ago, Luke said:

Me too, otherwise the SSL compiler would complain... It's simply little weird notation to me... I'd write: scsroot=stratagems&tutu_var=%tutu_var%, but whatever...

But I don’t want the string ‘scsroot’ replaced by ‘stratagems’. I want the string ‘%scsroot%’ replaced.

My experience from various adventures optimizing SCS scripts (all of this is from memory and from some while ago):

- I think OR() blocks evaluate from bottom to top, stopping when they reach a valid condition; I also think they're relatively slow; avoid them if possible. 

- Checking globals is very quick. If there is a global in your check, check it first.

- Scripts are evaluated 30 times per second. If you are doing something complicated that doesn't need to be checked 30 times per second, see if you can slow it down. E.g., use a Delay(), or set a timer to reset every six seconds and put !GlobalTimerNotExpired at the start of your block.

- most importantly, don't worry about it unless you are doing something very complicated indeed. The BG2 engine evaluates scripts very fast; the BGEE engine even more so. SCS scripts are often 10,000 lines long or more, and even so I quite rarely have to worry about optimisation. In normal circumstances, don't worry about this preemptively - wait till you see actual slowdowns.

Reflecting on this, and on the need for something to be iterated across multiple mods, I might be inclined to do something simpler. There are four lots of NPC orderings, yes, with 15 NPCs in each? Insert the new NPC transition at the top of the first one, the bottom of the second, at position 5 of the third, and position 10 of the fourth. That's enough randomness to achieve what you want, I think. The idea isn't to make sure that each NPC is equally likely to be selected, irrespective of party mix (the original script doesn't do that for the original NPCs) - it's just to mix it up a bit so that mod-added NPCs aren't guaranteed to be first or last, and so that the order isn't predictable. I think that suggestion will do it fine, and is (relatively) easy to implement.

Pretty sure it’s correct.

I meant something more elementary: two spells when I’m budgeting for one.

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!

1 hour ago, Luke said:

That's why I said "for now". If someday you use it, then you'll fix it...

Anyway, as I've realized afterwards, "enforce_hp" is working as intended. I apologize. It didn't behave as I expected because:

1. the INI entry "hitpoint_percentage=100" is missing
2. you don't launch it when launching "CRE_postbuild"
3. unlike the other "CRE_enforce" functions, the string "arguments" is not initialized to "" (empty string).

I'm glad I can use it in the end...

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.

1 hour ago, Luke said:

OK, so both "power" and parameter2 are located at 0x18...? That's clearly not possible...?

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.

48 minutes ago, Luke said:

OK, so you're ignoring it for now...? Guess that the HP issue can be "fixed" via using "clone_creature", but it's kinda ugly...

Anyway, you might want to check points #3 and #4, since "enforce_hp=>at_worst" is used a lot...

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.

37 minutes ago, Luke said:

power is located at 0x10, not 0x18.

No it isn't. This is a CRE v2.0 EFF field, not an ITM/SPL v1.0 field.

37 minutes ago, Luke said:

You also need to fix the related functions "CRE_power", "CRE_powerGT", "CRE_powerLT", "CRE_read_power" located in "stratagems/sfo/SFO_autofunc.tpa"...

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.

1 hour ago, Luke said:

the existing documentation is *probably* enough to get started and I'd like to try...

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.) 

1 hour ago, Luke said:

In case I need to report bugs and the like, should I do that via PMs or by starting a new thread in SCS subforum?

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.

4 hours ago, Luke said:

Indeed! So, do you recommend it in the end?

I must admit I'm very interested into trying it out... I just need to slightly tweak "install_sfo.tpa" in order to adjust it to my needs, right?

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!

5 hours ago, Nimloth of Thay said:

I know that modding requires tons of work and expertise, and that's why I respect and admire those who do it. I understand that not every idea can be made into a mod. What I did not like was having my idea being labelled "too whimsical" by a member and getting a solid "WTF" by another. I did not come here to be ridiculed.

I stand by my request to delete my account.

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.