Jump to content


  • Posts

  • Joined

  • Last visited

About DavidW

Profile Information

  • Gender
  • Mods Worked On
    Sword Coast Stratagems
    Wheels of Prophecy
    Icewind Dale in BG2 (now incorporated into Icewind Dale: Enhanced Edition)
    Ascension v2.0
    BG2 Fixpack
    Unfinished Business

Recent Profile Visitors

53,738 profile views

DavidW's Achievements

  1. 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.
  2. 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.
  3. I've just updated it. Should work fine on v247 now.
  4. Should be fine (iirc). WEIDU is basically backwards-compatible, there's just this tiny unfortunate exception.
  5. 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.)
  6. 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.
  7. 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!)
  8. Anyone is welcome to use this code in their mods, of course.
  9. 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.
  10. On the question of whether WEIDU is Turing-complete: see here.
  11. 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:
  12. 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).
  13. 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):
  14. (EDIT: actually, skip this one, it's overcomplicating things.)
  15. 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.
  • Create New...