Jump to content


  • Content Count

  • Joined

  • Last visited

About Wisp

Profile Information

  • Gender

Recent Profile Visitors

42,683 profile views
  1. @AL|EN In that case, I don't understand. You want to propose a second new packaging convention, only this one retains platform-specific stuff inside the mod archive? And at that, one that does not include WeiDU in the mod archive, but instead downloads a mod-specific WeiDU at run-time? It seems nonsensical. You are still including WeiDU in the mod archive, just in a roundabout way. Or have I misunderstood? Edit: yes, I have. The WeiDU would be shared amongst mods. Perhaps also relevant is that the interactive-installer parts that setup-mymod.exe and equivalent solutions rely on are slated to be removed (when this happens is, of course, a fun guessing game).
  2. @AL|ENThat's not what desktop entries are for. To associate a file type with a program, you edit one of the mimeapps.list files, or use the desktop file to announce which types the program supports. The desktop file is for the program, not the mod archive.
  3. Can you describe your testing method? When I assign lowercase portraits to Imoen, they show up properly in the dialogue window, sidebar and record screen (BGEE 2.5.17, picking her up after the cutscene with Gorion). They are also in lowercase in the GAM file. Worth noting is perhaps that NI will always show the resrefs in uppercase, even though they are not in uppercase on disk.
  4. I'm okay if people prefer to continue distributing mods as they do now. Hopefully a unified distribution format and graphical front-end for installation has enough merit to stand on their own. But a mod mananger is a de facto requirement for Skyrim, for example, and it does not seem to be any source of unrest.
  5. Worldmap, link entries: IESDP. I can't remember how the probability works. There is the SetEncounterProbability() script action, too.
  6. Sure. It's not particularly viable for the EEs, anyway. OT, but I can't reproduce this. Lowercase portrait resrefs seem to work fine.
  7. Wisp

    Ascension 2.0.7 out; report bugs here

    A regexp in balthazar_compatibility.tpa is incorrect. swap_out=~IsValidForPartyDialog?u?e("Edwin")~ (? is a postfix construct.)
  8. Wisp

    fj_add_are_structure --> Calculating Vertex?

    fj_add_are_structure is the first version of the function. The name was shortened when it was added to WeiDU. OP: you might want to switch to using WeiDU's version. In addition to being supported, there has already been bugs fixed. It also comes with documentation. Vertex values are calculated by bitshifting the y-coordinate of the point into the high word (y << 16) and adding that to the x-coordinate.
  9. Oh, you mean like that. For Zeitgeist I solve this by running the WeiDU process with its working directory set to the game directory and a local process environment that has the tools directory on its PATH. That way the location of the tools is transparent to mods. I have not yet gotten around to making the corresponding change to the relevant WeiDU functions; to allow them to use system executables and optionally free the modder from needing to include the executables in the mod itself. If it's agreeable to you, I imagine you could do the same. The guarantee would then be that if a mod manager is running the show, the relevant tools exist on the PATH and can be called without specifying their location. Excluding all top-level features of the base games is a good idea, yes. Mods should not overwrite anything (but possibly themselves, or an unfortunately named other mod, I suppose) when extracted. Yes, once the format is well-defined.
  10. Zeitgeist keeps WeiDU in the same directory as itself, which could be anywhere the user has appropriate permissions. On account of the version-pinning thing, I am considering more complicated systems, since we'd no longer be talking about 1 WeiDU executable; rather, it would be 1 for each version in play. I propose the location of WeiDU be left as an implementation detail of the front-end, but I would suggest it's in some location that is user-wide, rather than game-wide. If there is benefit in consolidating in the future, it would be safe to do so then. There's no problem. You mentioned cross-platform upthread and I got curios. If I get to decide, I say .iemod. I have no real objections to those restrictions on filenames or package contents, but I see no reason to prohibit override/, tmp/ and temp/. As long as it is not $GAME_DIR/override, it seems kind of arbitrary. I suggest dot-files (and directories) should also be filtered out, or at least the ones used by git. Off-hand I can't think of a good reason for wanting to include dot-files, and if there are any present in the mod tree, chances are they are not intended for distribution in this context. That is not quite an accurate assessment. Backward compatibility will still very much be a thing. Version-pinning would be optional, so all unpinned mods would need WeiDU to remain backward-compatible. It would allow those modders so inclined to get off the ride, as it were, and remain on some specific version indefinitely. Very hypothetically, it would also allow breaking changes to be made, since you could branch off the last non-breaking version and put it on life-support; breaking changes would be opt in. However, it's both exhausting and infuriating to be working against something that makes frequent breaking changes, so I wouldn't expect a great many of those, in any event.
  11. 2. Is this not just you basically saying it's so. I might as well say it's an IE mod, hence .iemod. It also has the advantage of being less letter salad. You seem to suggest the distinction has something to do with "source" files, but there's meaningfully no such thing. The "source" files are the mod. 5. Regarding the proposed extension for WeiDU-Linux: absolutely not. WeiDU has been weidu since the beginning (or at least, since it was lowercased by default) and changing it would break all existing scripts and tooling that relied on it. GNU/Linux conventions are overwhelmingly that executables have no extension. You don't get to impose a new convention because you think it would be more convenient. 6. Including copies of WeiDU in every mod was ridiculous in the 1990s, it remains ridiculous today and it would be pants-on-head silly if "mod managers" were to get involved. The "mod manager" can simply include or download the appropriate version of WeiDU and essentially have it all handled behind the scene. Zeitgeist already does much of this. As a side note: ALIEN, have you investigated the possibilities for cross-platform support for your tool? I'm not at all knowledgeable about C#, mostly because while the language is cross-platform, the libraries and frameworks you'd use to create a Windows program were not. The corresponding stuff that were available for GNU/Linux is obsolete on Windows and on macOS you'd use something different that only worked on macOS. But maybe that's changed by now. Sweet dog is the quote button an exercise in frustration now!
  12. Wisp

    New to weidu

    How far along in your learning are you? I wrote a quick introduction for getting started with WeiDU: the files and folders you'll need, the basic structure of a TP2 file, posted here. If you have yet to get this far, I'd say it's still a worthwhile read. As for using functions, for a patch function, you would open a buffer, typically with COPY_EXISTING and invoke the function. Function documentation can be found in the WeiDU readme (functions are under the macro listing). The IESDP is also a good resource for documentation of the file structures. This code changes the Wand of Fire into having 1 recharging charge: COPY_EXISTING wand05.itm override LPF ALTER_ITEM_HEADER INT_VAR header_type = 3 charges = 1 drained = 3 END BUT_ONLY As the name implies, the function ALTER_ITEM_HEADER changes values in an item header, which is where charge behaviour is located. Other functions can be used to do other things. The function selects all headers of type 3 and changes the charge field to have the value 1 and the field for charge-depletion behaviour to have the value 3, which is daily recharge (see the IESDP). BUT_ONLY applies to the COPY_EXISTING action and means that the file will only be copied if the applied patches change the contents of the file. It's good practice to have it on all your COPY_EXISTINGs. Updating charges in areas, creatures and stores is similar, but off-hand I can't recall if there are ready-made functions for all of it. It also involves finding the areas, etc, that hold references to the item. Updating the item description is most easily done by writing a new one and using the SAY patch to write it to the item and add it to the game. This is left as an exercise for the reader. I hope that helps and feel free to ask questions.
  13. Wisp

    Version 7 released

    That depends on what you mean by proficiency. Item Randomiser still relies on the BG1-style proficiencies and does not add any BG2-style proficiencies. As far as I could tell, there was no need, as the BG1 ones worked just fine. But I understand that some mods have started patching away BG1 proficiencies and I don't think I've yet updated Randomiser to take that into account.
  14. Wisp

    Question for pure re-installation

    When you start the BG2 portion of your game, it is effectively the same as starting a new game, as far as IR is concerned. You should not encounter any issues at all, not even on account of your slightly different mod setup. You are correct that spawning creatures would not work. The best way to test would be to use to console to take you to one or more areas where you'd find random items. Happy gaming.
  15. Wisp

    Version 7 released

    Do you recall if Hindo's Doom was one of the items you picked up from Abazigal? If so, it wasn't being equipped for some reason, but at least he got a weapon into his inventory.