DavidW

I think that approach will cause trouble: (i) you'll have to hardcode character abilities into the item, which is compatibility-unfriendly (ii) taking the object off and back on again will recharge the ability. My immediate thought is to get the item to set a spellstate. Then edit the spell to block it, and display a 'this power can't be used while wearing blah' message, when the spellstate is set.

I've just updated it. Should work fine on v247 now.

Should be fine (iirc). WEIDU is basically backwards-compatible, there's just this tiny unfortunate exception.

Yes. (And various intermediates; e.g. my recode of Ascension is nothing like as abstracted as SCS but still does things at a fairly high level.)

Well, just being Turing-complete, by itself, isn't enough to make a programming language fit for a given purpose. Turing machines are Turing-complete, but I'm not planning to mod with them! My point was that WEIDU actually is a fairly powerful programming language, in which you can do most of the things you need for high-level programming. The actual Turing machine implementation was a joke, mostly. (Obviously WEIDU is Turing complete - all you need for that is variables and basic control flow, and it obviously has those.) But the fact that I can do a fast smooth implementation of a Turing machine in a few dozen lines of WEIDU code and in twenty minutes of my time does provide a reasonable demonstration that WEIDU can easily be used for abstract programming and not just as a low-level interface into IE files.

No, I don't think so, precisely because the tape isn't just an output: it's also input and working memory. (Not that I put more than 5 seconds thought into what it should be called!)

Anyone is welcome to use this code in their mods, of course.

Oh, you might well be right (though the backwards-compatibility issues are serious). WEIDU is a lot more powerful than it looks, and I actually really enjoy programming in it, but I don't think anyone thinks it's the language that you'd build from scratch for modding.

On the question of whether WEIDU is Turing-complete: see here.

A somewhat tongue-in-cheek response to the discussion of WEIDU on this thread: A WEIDU implementation of a Turing machine, using the conventions here: You use it like this: LAF turing_machine INT_VAR display_steps=1 STR_VAR machine=my_machine END 'my_machine' is an action function encoding the machine's lookup table. Here's an example:

The issue is that the game engine (mostly) doesn't care what the symbolic names are. Take class.ids - it assigns a numeric value to each class, so that class 1 is labeled MAGE and so forth, but the engine (mostly) doesn't store or manipulate the symbolic names, only the numeric values. If you changed 'MAGE' to 'WIZARD' in class.ids, it would (mostly) leave the game unaffected. (The 'mostly' caveat is because dialog files store their fragments of script uncompiled and compile it at run-time. So if there's a trigger in a dialog that checks if you're a mage, that change will confuse it.) So if you change the label on sndslot 9 (currently BATTLE_CRY1) to SELECT_COMMON1, it won't make any difference to how the sound in slot 9 is used by the engine; it'll just mean it's labelled misleadingly. More seriously, if IWDEE uses BATTLECRY1 rather than BATTLE_CRY1, you still want your first battle-cry to be put in that slot. Usually the various EE games are consistent across their ids files so that you can write multi-game code that refers to the ids symbols, at least if we're talking about BG2EE, BGEE, and IWDEE, all of which use the same engine. But there are exceptions, and I don't have much experience modding PSTEE, which has a different version of the engine. (My code above was to make a general point about WEIDU capabilities, not actually to thrash out what a working soundset program would be.) My advice here would probably be to standardize on the BG2EE version of sndslot.ids and just read the symbolic names in from a local copy in your mod folder rather than relying on the in-game version. In WEIDU I'd just read them into an array; I assume you can do something similar in Python (which I think is probably Turing-complete).

I'll stop after this, but here's a direct implementation of Taylan's design spec, in WEIDU rather than Python (again helping myself to a couple of auxiliary functions):

(EDIT: actually, skip this one, it's overcomplicating things.)

I feel the need to defend the honor of WEIDU. Here's how I'd code this task in WEIDU, assuming exactly the input format for descriptions.txt in Taylan's post: It appeals to a couple of subsidiary functions which I haven't defined; they'd be about 5-10 lines long each, I think. It took about 20 minutes to code, and it's about the same length as Taylan's Python script (and without appealing to a hypothetical library of weidu functions). The syntax is a little more cumbersome than python, to be sure. WEIDU isn't perfect, but it's not just nominally Turing-complete; it's a reasonably effective programming language, even if 95% of mods don't use it that way. Would it be nice to have object-orientation, anonymous functions, more sophisticated handling of arrays as values, or a less idiosyncratic syntax? Sure. But it's way more powerful and flexible than it gets credit for.

@Angel: the only caveat I should give is that I have tattered shards of my own rewrite locally, so might not be able to incorporate third-party fixes very directly. (This is what happened for v31/v32 of SCS: CamDawg put together v31; v32 was built on v30 code with some manual incorporation of things from v31.)

I don't at all object. Feel free! (Not basically around right now, too busy in real life.)

Yes. (It reflects the fact that the party are teleported in without warning, so it's implausible for the chess pieces to prebuff.) This is externalized to stratagems\mage\override\[bg1/bg2]\boolean.2da. Setting the Boolean DoNotPrebuff turns off buffing. You'll see that in BG1 it applies to the chess pieces, to a couple of dopplegangers, to Silke in Beregost, and (iirc) to a couple of adventurers you can meet abruptly in Baldur's Gate.

It's because the mod isn't updated to WEIDU v247 yet.

Please do advertise, especially since this version seems to be glitchy (and I don't think there are reports of yours being).

Do many mods have translated READMEs? I would have thought that would be pretty problematic, for exactly the reason you give: they won't generally stay up-to-date.

I don't have anything to add to subtledoctor's sensible comment. (I have no real experience with MacOS.)

The icon trick was the only way I found to display a subrace. You can disguise it as a clone of an icon the creature ought already to have (e.g. magic resistance) if you also give them immunity to the original icon.

Liches don't have any specific immunity to False Dawn or Sunray. But they do often have resistance to fire damage (False Dawn) or magic damage (Sunray) due to their buffs, so I think it's probably that.

Don't overestimate SCS's AI. It's not clever enough to do a relative-armor check on spellcasters. Mostly it's working with a class-based priority list: if for the particular attack we're dealing with that priority list has cleric>bard, clerics will be prioritized. If you think that's anomalous, and it would be better to do bard>cleric, I can tweak it. (Sometimes, e.g. when we're explicitly targeting mages, it's that way round already.)

Priests are sometimes prioritized over bards, so that might be part of it. I don't think it can be a mod conflict - this is a pure AI issue and SCS' AI is pretty much a destructive overwrite of the AI and wouldn't be affected by other mods.