Jump to content

DavidW

Gibberlings
  • Posts

    7,825
  • Joined

  • Last visited

7 Followers

About DavidW

Profile Information

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

Recent Profile Visitors

65,563 profile views

DavidW's Achievements

  1. OK, addressing these now: All fixed locally, will be in beta 9. This is intentional: Berserkers already get imprisonment immunity, and I don't see a good thematic, balance or lore reason to deny it to barbarians. The documentation now notes this (in passing). The only one I can see is Feeblemind (which is fixed locally and will be in beta 9; it's a library bug in lib_immunity). If there are others let me know.
  2. 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.
  3. If you use double damage you’re on your own, I’m afraid!
  4. 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.)
  5. 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.
  6. 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.
  7. It’s superficially-plausible gibberish.
  8. 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.
  9. 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.
  10. 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.)
  11. 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]).
×
×
  • Create New...