DavidW

1. Not at all serious. It's a joke, really (I should probably have posted it in Noobermeet) with a 10% admixture of making a point about WEIDU's expressive capabilities. 2. Useless. (The comment about 'you can use this in your mods' is 100% a joke.) 3. It depends what you mean by 'should'. If you mean 'what should they know for modding purposes': nothing. But in case you're interested more broadly: (i) One of the central principles of computer science is that computation is universal, which means that any reasonable model of computation can achieve anything that any other reasonable model of computation can achieve. Alan Turing was one of the pioneers of all this; the 'Turing machine' is his concrete model of computation. A standard way, at least in theory, to demonstrate that a computing device or computing language is 'universal' - that is, that it can do anything that any other model of computation can do - is to show that it can simulate a Turing machine. (The Wikipedia link I put upthread has more.) (ii) The other thread I linked to was a good-natured discussion of the limitations or otherwise of WEIDU. Taylan was complaining about how limited WEIDU is as a computation language and mentioned in passing that it was only 'probably Turing-complete'. I don't think they were very serious - the requirements for Turing completeness are very minimal, WEIDU obviously satisfies them - but nominally my post is a demonstration of Turing completeness. Insofar as it had a more serious purpose, it was to demonstrate that you can use WEIDU to do complex abstract programming tasks very far removed from concrete mod applications like WRITE_ASCII 0x248 ~wtasight~, and so that it's a much more powerful tool than most people treat it as. (iii)...But, like I say, it was mostly a joke. The code took me 20 minutes, it's not a labor of love or anything.

I would be extremely surprised if this is new as of 33.7 - it's standard, documented behavior, and as you say should be ini-deactivatable. (Though if IR modifies them I should probably notice this and leave them alone.)

I like design information. I don't systematically make item mods but I occasionally need one for a quest reward. Being able to get a sense of how someone is thinking about balance and the like is helpful both in deciding whether to look for a specific item, and getting a sense of how deeply the author has thought through the balance and playability implications. I'll bookmark this next time I need an idea.

Not quite. SCS assumes either EE or ToBEx, which has extended stats. Anything SCS uses as a spellstate on EE is used on oBG2 as a ToBEx extended stat. (And SCS's spellstates are mostly (not entirely) the ones introduced by the EEs. (My 'notes on current usage.txt' is the pre-SCS usage.) Of the proficiencies that are still used, a few of them need to have multiple values (WIZARD_SPELL_DEFLECTION, CLERIC_INSECT_PLAGUE, WIZARD_SPELL_TURNING). A few of them are redundant given spellstates/extended stats: CLERIC_CHAOTIC_COMMANDS, WIZARD_FIRE_SHIELD, WIZARD_PROTECTION_FROM_MAGIC_WEAPONS. The rest could be, but so far haven't been, replaced with spellstates. Of course, the problem is backwards compatibility, since plenty of older mods use the old proficiencies. In principle one could write auto-clearout code that mapped an existing installation onto a new system, but I think it would cause as much trouble as it solved (use it too early, and it'll get overwritten by new mods; use it too late, and it might overwrite intentional uses of the new proficiencies). I am in any case *somewhat* inclined to map SCS, at least, over to a new system when I next release it. That would free up 11 proficiencies. Of course, splstate isn't an infinite resource either, but there are about 120 slots spare (of which SCS uses about 30, I think) so that's not too demanding a constraint.

My feeling was/is that a mod designed to move IWD spells to BG2 should keep its changes to the BG2 spell system to a minimum. Moving a spell to a different level is, in my subjective judgement, a lot more minimal than actually changing it into a different spell. I'd probably rather just leave it at 6th level and accept the mismatch with Entropy Shield if the alternative was changing it into a new spell. However, I don't really have a problem with changing a spell level - I don't really see what's 'arbitrary/contradictory' about it, except that it doesn't match PnP... but PnP fidelity was never an IWDification design goal. (All that said, this is an SCS design choice that Cam just inherited; he might feel differently.)

Well, I can certainly confirm that's a bug! What's causing it isn't so obvious to me. SCS's mage-processing goes like this: 1) Adjust the mage's level, on the basis of the spells they actually have learned (in-game levels aren't always reliable; if someone's listed as L18 but only has Magic Missile SCS assumes it's wrong). 2) Allocate spells appropriate to their level and kit. This is destructive: existing spells get wiped (after being checked at stage 1 when we're adjusting levels). 3) Build a script appropriate to those spells. (For reasons of procesing time, the script only tries to cast spells that the creature actually has). Scripts like dw#mg381 are autogenerated, and which one is assigned to which creature will vary from install to install. In this case, the allocation of spells is clearly badly wrong (and the script is then responding to that badly-wrong set). Normally when that happens, it's because something has gone wrong with SCS's determining of level. For instance, if some other mod had given Mutamin Horrid Wilting, then SCS would see it and think 'aha, he must be at least 16th level', and then would give him a set of spells to match. But it sounds like that can't be the case here, because you say Mutamin is still 6th level when you check his cre file (just to check, is that checking post-SCS that he's still 6th level?) So I'm not quite sure what's going on. I suggest you uninstall SCS, look at Mutamin's cre file, and see if it's odd in any way (e.g. what spells does he have). (It's always possible there's just some bug in SCS's mage system - but I think that's unlikely, as I'd be inundated with messages!) Incidentally, extheal isn't a bug (iirc). Some versions of the game have it; for those that don't, it's harmless.

Just to expand on Cam's comments: the spell section of IWDification pulls almost all its strings directly from the IWDEE dialog.tlk. Only the handful of strings in dw_iwdspells_arcane, dw_iwdspells_divine and dw_iwdspells_bard need hand-translation. (I can't speak for the rest of IWDification, which is entirely Cam's baby.) Obviously I have no idea how good the translations in IWDEE are! As Cam says, it would be easy enough to put a community-preferred translation onto IWDEE before the converter does its resource-collection run.

Had you been in the area they spawn in previously, e.g. did you come back to kill Firkraag later? There is a known issue with hardcore hit-point buffs eventually expiring.

Yes, it's SCS (following Ascension). I should have a look and see if it's a bridge too far (and probably ini-gate it at any rate). Might be a little while, though (I'm only semi-around right now given RL). In the meantime, edit fiend/fiend_shared.tph and comment out the relevant lines around 185.

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