DavidW

I have been saying so for years, and mostly people seem convinced. But of course that's a mod design issue, not about WEIDU per se.

If you use double damage you’re on your own, I’m afraid!

Higher-level functionality, saves you doing the (OS-dependent) AT_NOW, COPY, and reset directory each time. (After all, in a certain sense there’s no point in any function, since you can do everything with low level commands.)

I’m not aware of a way.

It might be helpful for this conversation to have a more precise statement of what WEIDU actually does. Here's mine: WEIDU is a programming language with the following main features: 1) It has a very lightweight implementation, distributable as a self-contained executable small enough to be distributed directly with a mod. (The Windows WEIDU executable is 1.33MB.) 2) It contains a bunch of commands to read files into memory and write them back out to file, all of which have built-in reversibility, i.e. all changes can automatically be uninstalled. That uninstallation is very robust: you can tell WEIDU to make irreversible changes, but it takes active effort and expertise. Normally you can install a WEIDU mod component and be confident that it will uninstall cleanly. 3) Its read/write structure interacts very transparently with the BIF system in IE games: commands like COPY_EXISTING and RESOURCE_CONTAINS will fish files out of chitin.key or the override, as appropriate, without a mod developer needing to pay any attention to the BIF structure. Commands like COPY_EXISTING_REGEXP likewise iterate transparently over game files, irrespective of how they are stored. 4) It provides tools to interact with dialog.tlk (transparently as to whether the game is EE or original, and as to which language is installed). There are several ways it does this - RESOLVE_STR_REF, SAY, STRING_SET_EVALUATE, GET_STRREF, READ_STRREF, and more - and in each case the changes are made reversibly. Many of the tools are transparent: if you are giving names to a magic item, for instance, you don't need to know anything about the underlying .tlk reference. 5) It compiles and decompiles (again, reversibly) BCS scripts to and from the BAF format. In doing so it fairly transparently handles strings embedded in BAF files. 6) It compiles and decompiles (again, reversibly) DLG files to and from WEIDU's own D format. It's worth noting that this is a much more involved process than BAF<->BCS compiling: the D format has a lot of pretty advanced features. And again (much more importantly than for BAF) it transparently handles adding strings in a D file to dialog.tlk. 7) It implements the TRA system for localizing strings. 8 ) It contains a bunch of commands (READ_BYTE/SHORT/LONG/ASCII, GET_OFFSET_ARRAY, etc) that are optimized for interacting with IE-type files at a fairly low level, and (I think) do so quite quickly and efficiently. (You would probably want at least the option of this low-level interaction in any tool: if you want to, say, iterate over every CRE file in the game and get some basic information from it, it's going to be inefficient to do that by reading each one into a data structure.) 9) It integrates quick information retrieval from the various IDS files that the game uses, via IDS_OF_SYMBOL and LOOKUP_IDS_SYMBOL_OF_INT. (In addition it has a bunch of commands like ADD_SPELL that operate on files at a higher level, but those are inessential: they could be implemented as functions without much loss.) Let's consider what a WEIDU replacement/successor would require. It would have to be either (i) a new bespoke language written for IE modding, or (ii) an existing language equipped with a robust function library built for IE modding. (i) seems to me a non-starter. The list above hopefully demonstrates how much work it would be to write that new bespoke language, and while WEIDU is no doubt not what one would design from scratch, I don't see the gains from redesigning it would pay for themselves even setting aside the compatibility issues. (ii) is more interesting, and I take it closer to what various people in this thread have in mind: using an existing language gives you powerful and robust features like better data-structure handling, variable localization, functional programming, and a big function library, all for free, and also might increase familiarity. (Set aside my skepticism about how much that really matters.) There is a huge backward-compatibility problem, but perhaps that could be finessed by embedding the language in WEIDU: a component would just do AT_NOW (whatever), or more sensibly wrap everything in a function, and the core of the mod would be in the new language. You would either need to require users to install the new language, or else use something small enough that it could be included in the mod itself. The latter seems the better way to go: LUA, for instance, is probably small enough, albeit its footprint is a lot bigger than WEIDU itself.) I'm still skeptical, for two reasons. Firstly, it would be very difficult to replicate WEIDU's robust uninstallability. Even if one's library of functions for manipulating IE files was carefully built to enforce reversible installation, the user would have native access to LUA, and LUA code itself is under no particular obligation to be reversible. Clean uninstallation would require much more code discipline, rather than happening pretty automatically under WEIDU. Secondly, and MUCH more importantly, replicating all WEIDU's functionality (as listed above) is a Herculean task. Thousands of hours have gone into WEIDU development and I think thousands of hours would have to go into building a full-featured successor. Implementing the D format alone would be a massive amount of work: it would be tempting to use WEIDU itself to compile and decompile dialogs, but then you would struggle to integrate with dialog.tlk editing. Some time could be saved if the new language was OCAML, so that you could re-use existing code, but I'm not sure replacing WEIDU with a fairly obscure functional-paradigm language is really what people considering a successor have in mind. What is more plausible - and this now speaks to the exchange between Suy and myself upthread - is to have some bit of LUA (or other) code embedded in WEIDU to carry out some specific task. It would not be difficult to write a WEIDU function with this schematic form DEFINE_ACTION_FUNCTION lua_execute STR_VAR bin="%MOD_FOLDER%/bin" // path to LUA executable code="" // path to lua code input="" // space-separated list of inputs to the LUA function BEGIN // install LUA if not already installed [blah] // implement the LUA code, which dumps all its output in the folder weidu_external/workspace/lua_out, and // returns variable 'success', equal to 1 if the code successfully implements [blah] // propagate a LUA failure to a WEIDU failure ACTION_IF !(success=1) BEGIN FAIL "lua_execute: failed to execute LUA code %code%" END // sweep LUA output into override (doing it this way lets us use WEIDU uninstall) COPY "weidu_external/workspace/lua_out" override END But it's important to note the limitations of this: without a LOT of extra work, the LUA code could not interact with dialog.tlk, so strings could not be set; similarly, the code couldn't engage with scripts or dialogs, and would need files to be extracted by WEIDU into override in advance. A tool of this kind would be relatively special-purpose, e.g. a more sophisticated, data-structure-style way to edit item or spell files where changing the .tlk entries isn't needed. I think the jury's out how that would compare to building the tool natively in WEIDU. (Speed is one possible advantage: high-level WEIDU functional methods are sometimes a bit sluggish.) What it wouldn't do is obviate the need to learn WEIDU to write a fully-featured mod.

That’s more a feature of how people use WEIDU. You can code in a much more high-level way - look at ToF sometime - though to be sure it’s not as fully-featured as a proper modern language. Mostly when I code low-level it’s for speed.

It’s superficially-plausible gibberish.

It won’t take you a year to learn WEIDU. At least to understand it as a programming language, it will take you an afternoon. What takes somewhat longer is understanding the various built-in WEIDU commands that manipulate IE objects at a low level. But any language will have to manipulate those objects at a low level unless it is actively enriched with functions that manipulate them at a high level. And no such functions exist in other languages. If the issue is a lack of high-level tools to interact with IE objects then I sympathize. But that’s not really about WEIDU per se, it’s about the best way to build those tools.

I don’t think WEIDU is a “unique, unlike other” language. It’s an imperative weakly typed language with basic support for functions and a mildly awkward syntax. Its regexp and control flow is pretty standard. Its array support is slightly idiosyncratic but not radically so. Its low-level I/O is unusually good and I’ve actually used it occasionally for work for that reason. It’s not the language I’d choose to do a general-purpose programming task but it’s perfectly functional.

I repeat my previous observation that mere unfamiliarity is not by itself a good reason to change WEIDU. If you are a competent programmer then it should not be difficult to learn a new language, nor time-consuming compared to the time to execute a complex mod. (I learned LUA in an afternoon.) If you are not a competent programmer then you can’t make a mod that involves complex programming anyway (and it is trivial to learn enough WEIDU to install premade files.)

It might be worth noting that this component of the Calling is borrowed from SCS, where it is a relatively minor modification of the Kaishas dialog and cutscene tacked on to the tactical improved-werewolves component (and I think my first attempt at dialog and cutscene modding). I’m sure there’s scope for a much more drastic werewolf-island mod, but it’s not really something I’m interested in writing (apart from anything else I have too many projects already, including ToF, the WoP rewrite, [redacted], and [redacted]).

I see SCS listed - just to say, SCS also isn’t bound by the 50-spell limit.

Thanks, helpful - will chase.

The original issue is definitely a bug, for sure.

I should do this one too, I guess: [ m.ab_fx.alter{PATCH_IF s_opcode=216 BEGIN PATCH_PRINT ~I drain %s_parameter1% levels~ END} ]

Some belated thoughts: 1) The obvious constraint in a WEIDU replacement (for the moment setting aside the question of whether we want one) is that the existing mod ecosystem is coded in WEIDU (and, at this stage in the community's life cycle, the existing mod ecosystem is much bigger than the mods that will be created in the future). That means any WEIDU replacement will have to be able to handle an install order containing WEIDU mods, and hence must have a complete implementation of WEIDU inside it. That's a horrendously large overhead on what is already a horrendously large task. (Doubly so assuming the replacement is not to be coded in OCAML, which I assume most people wouldn't want, and so has to reimplement WEIDU and not just borrow code.) 2) What is *possibly* realistic is to have WEIDU call out to some external tool (using AT_NOW, I guess) to do file edits, rather than doing them natively. I think that's what Suy has in mind. And certainly there is lots of high-level functionality that WEIDU can't do, or can do only clunkily, using its base tools and the core function library it ships with. The question I'd ask is: what is the advantage of implementing that high-level functionality in a new language that gets called from WEIDU, rather than as functions within WEIDU itself. After all, WEIDU is a fully functional programming language. It has its disadvantages (its syntax is sometimes clunky; its variable typing is rudimentary; it doesn't allow functions as first-order values; it lacks a large library of preexisting resources) but its low-level functionality is very tightly connected to IE mods and of course using it natively avoids a lot of awkward interface issues between WEIDU and an external tool. 3) Ultimately I think the problem with a new tool that replaces WEIDU's functionality is the same as the problem with a rich function library within WEIDU: building and maintaining that resource is a huge outlay of time and no-one has been willing to put it in. My 'SFO', especially in its newer form, is the closest I'm aware of, and I think solves most of the problems that WEIDU critics raise, and one of these days I may get around to finishing documenting it and making it available to others to use, but ultimately I don't have that much free time for modding and what I have is mostly devoted to my own mods rather than maintaining community tools. I think that problem generalizes beyond me. 4) Part of people's problem with WEIDU is just unfamiliarity. This isn't a good reason to look for change. Programming concepts are largely transferrable between languages and the time taken to learn a new language is short compared to the time taken to implement a complicated project. It is true that the resources to learn WEIDU are limited (my Course in WEIDU was an attempt to address this) and that reading mods is a very imperfect way to learn it (90% of WEIDU mods use only 10% of WEIDU's capacities).

In SFO it looks like this: spl.edit[SPCL822] [ m.ab_fx.alter{s_parameter1 = s_parameter1 - 1} ]

I don't know a way to adjust carry weight. The rest is in principle possible but most of it requires UI edits, in some cases quite drastic ones. (I did look at the hidden IWD2 kits when writing ToF but mostly didn't find things worth the effort of implementing.)

To be fair, I have had occasional edge-case issues when I've had sequential mod components with non-increasing DESIGNATED values, and have very occasionally renumbered for that reason.

I'm not sure I like the idea that every single werewolf is able to suppress both peer pressure and their savage nature because the player helps them out.

Thanks for the bug report. FYI: you can also avoid killing Carsa by using any other effect that confuses or immobilizes her or knocks her unconscious, though I don't know if this bug recurs for those routes too.

'Call' for help is an abstraction: it covers creatures engaging opponents when they see that their allies have engaged. And in DnD it's never been the case that a group of skeletons only partially engage.

I think this is on NTotSC. SCS works with what it's given, which in this case is a bunch of spellcasters who are flagged at 12th level. I can adjust for this kind of thing in the core game but I draw the line at handling every mod. If NTotSC doesn't want 12th level orc mages, it should use lower level ones.

I’d be concerned that if you go too far in this direction you start changing the essentially tragic theme of the island. (I mean, you could advance that as a criticism of the Calling change too, but hopefully it gets away with it). Still, implementation is what matters, and if someone wants to write that mod and can do it in a way that works, more power to them.

OK, updated the hotfix to address this too. Sorry about this, it's seriously annoying and I'm not really sure how it crept through.