argent77

GibberlingsThree WeiDU Install Tool Weidu Install Tool (WIT) is a graphical front end for WeiDU to install modifications for Infinity Engine games, such as Baldur's Gate, Icewind Dale or Planescape Torment. It offers all the functionality of the WeiDU command line interpreter as well as many usability improvements and convenience features to help with the mod installation task. The tool is available for Windows, GNU/Linux and macOS. This is the first stable version. It comes with Russian translation and several bugfixes as well as all the features from the release candidates. More information can by found in this topic: Version 1.0.0 of the WeiDU Install Tool available. Download: GitHub Discussion: G3 Readme

WeiDU Install Tool Version 1.0.0 Download Readme Project Forum WeiDU Install Tool (WIT) is a graphical front end for WeiDU to install modifications for Infinity Engine games, such as Baldur's Gate, Icewind Dale or Planescape Torment. It is available for Windows, GNU/Linux and macOS. This is the first stable version after a series of release candidates. Changelog: First stable release Added Russian translation (by abalabokhin) Fixed typos and cosmetic issues

WeiDU Install Tool A graphical front end for WeiDU Mods. Download Readme Project Forum Overview WeiDU Install Tool (WIT) is a graphical front end for WeiDU to install modifications for Infinity Engine games, such as Baldur's Gate, Icewind Dale or Planescape Torment. It is available for Windows, GNU/Linux and macOS. The tool offers all the functionality of the WeiDU command line tool as well as many usability improvements and convenience features to help with the mod installation task. It is meant as a replacement or alternative to the setup executables that are included in most mod archives, but can also be used for more general WeiDU operations. It is not intended to be a full-fledged mod manager such as Project Infinity. Features Tp2 Mod File Association: The installer versions of the WeiDU Install Tool automatically associate* tp2 mod files with the application which allows you to quickly and conveniently install mods from the file manager without having to deal with setup executables. Alternatively mods can be opened directly in the application. * Not available on macOS. Drag and Drop support: This feature allows you to drop tp2 files or the mod folders themselves onto an open WeiDU Install Tool instance to initiate the mod installation process if no other mod is currently being installed. It is available for installer and portable versions. Customizations: The application provides a number of customization options, which includes: Displaying UI text and messages in the user's native language if available Toggling between light and dark mode UI on-the-fly Setting output text size and character encoding Showing visual hints about the installation state Warnings about potential mod conflicts Customizing the mod installation process More features are planned for later. Installation The application is available as installers for Windows, Linux and macOS which set up start menu and desktop icons as well as file associations* with tp2 mod files. Alternatively, it is available as portable zip or tarball archives. A Flatpack version for Linux is planned for later. * Not available on macOS. Supported platforms Windows: 64-bit Windows 7 and later Linux: x86-64 architecture a graphical window manager or desktop environment (Gnome, KDE, Cinnamon Desktop, ...) macOS: x86-64 architecture official support since macOS 11, but will most likely also run on older versions Credits Weidu Install Tool © 2023 by Argent77. Translations: English: Argent77 German: Argent77 (Proofreading: Shai Hulud) French: JohnBob Brazilian Portuguese: Felipe Russian: abalabokhin License WeiDU Install Tool is licensed under the Apache License, Version 2.0.

Yes, that looks good to me. You can use NI to check whether the variable has been added to the ARE files. CLUAConsole works a bit differently. You have to use the current area resref as scope name to return the value.

Yes, but on area-scope. That way each area provides their own variable that can be checked, which is basically the same as checking the area type. The scope placeholder "MYAREA" can be used to avoid typing the specific area as scope ("AR1000", ...). For example, this check IF AreaType(POFAREA) THEN RESPONSE #100 // ... END could be replaced by IF Global("POFAREA","MYAREA",1) THEN RESPONSE #100 // ... END if the area-local variable "POFAREA" is defined and set to 1 in all relevant areas by the methods outlined in my previous comment. The same is true for dialog conditions.

If area types are only used for scripting then using area-scope variables would provide the same effect and could even be used for more fine-grained checks. These variables could be added statically to the areas themselves like this: COPY_EXISTING "ar9999.are" "override" LPF fj_are_structure INT_VAR fj_variable_value = 1 STR_VAR fj_structure_type = "variable" fj_name = "my_areatype_variable" END and used in scripts or dialogs via Global("my_areatype_variable","MYAREA",1). Alternatively they can be set up in area scripts, which introduces a slight initialization delay though. Unfortunately I can't think of any viable alternative for spell effect filtering via spellprot.2da, unless you count using helper creatures which is ugly and error-prone. Introducing some general-purpose area types sounds like a good idea to me. The EXTRAPLANAR type in conjunction with area-scope variables would allow my to replace my own area type in Test Your Mettle! without sacrificing functionality. I haven't looked into the other listed mods. But it's likely that they're using area types only for scripted checks as well, which could be replaced with variables just as easily. I wouldn't add more than three or four entries, however, so that there is still room for a couple of more specific area types (like BG1AREA for EET). That would actually be a good candidate for the EE Fixpack.

Test Your Mettle! uses RUBIKON (or A7_RUBIKON in future releases whenever I can find the time to wrap up the update). Removing it would complicate a lot of scripting quite a bit and requires the introduction of helper creatures to emulate certain spell effects with splprot filters. It would get ugly very quickly.

The Windows installer for WIT is automatically created by the JDK. Unfortunately my options to customize it are very limited. Except for this (unnecessary) dialog the installer should work as expected.

A new release candidate is available: WeiDU Install Tool v0.10.3 This will probably be the last release candidate before a stable release unless more critical issues are reported. @suy This release should have fixed the reported mod components parsing error. Changelog: Added option to create debug files of mod installations in a user-defined folder instead of the game directory. Added option to auto-apply performance or diagnostic parameters to mod installations: Performance: --quick-log Performance: --safe-exit Diagnostic: --print-backtrace Diagnostic: --debug-ocaml Diagnostic: --debug-boiic Diagnostic: --debug-change Apply user-defined set of parameters Fixed issues with mixed-case paths on Linux which resulted in failures to retrieve mod components info. Improved parsing of Project Infinity metadata: Added support for C-style comments (//) and Windows-style comments (;)

This mod has to be installed after "d0questpack:10:Revised Hell Trials" to work properly. More mod order hints can be found in the readme.

The installer version installs a self-contained package with a minimal Java Runtime. That's why Java doesn't have to be installed globally on the system. WIT takes advantage of the latest Java features where creating self-contained packages is a (relatively) simple matter. There has been a lot of development going on lately in the Java world after a long time of stagnation. It's more complicated for NI though, since it is based on a much older Java version and uses an ancient build system. Even creating the installer version requires the use of two different Java Runtime versions presently. But if there is a real need of a portable self-contained package then I can look into it.

@suy Those are certainly good points but keep in mind that modders are (usually) no software developers. Choosing any kind of advanced file format will only increase the likelyhood of malformed data or dissuade modders from adding metadata at all. Actually, I would rather prefer a made up data format with even simpler specs than the ini format, like this example (using the template data from the PI wiki) : This is just meant as food for thought. Personally I'm perfectly fine with the ini format. But if there would be a switch then I'd propose to choose something as simple as that.

1) You could open WIT directly from the start menu or desktop icon and cancel the "open tp2" file dialog. That will only show the WeiDU help in the output text area. The WeiDU binary is needed in any case, however. 2) The user folder is a good location because the app can be reasonably sure that it's available and accessible by the user. WIT is a multi platform tool, so I had to choose a starting location that is available on any platform. Once a mod is executed that folder will be stored as the "last mod path" in the configuration and used as starting location by the next call of WIT. Don't forget that you can also drop mod files or folders from the file manager onto the app to start mod installations.

Multiline support is currently only enabled for "Description" strings, but that restriction can be lifted if needed.

A new release candidate is available: WeiDU Install Tool v0.10.2 Download link in first post has been updated. Changelog: Added Brazilian Portuguese translation (by Felipe). Added warning dialog if a mod is installed from a path outside of the game directory. Reduced likelihood of connection failure for the WeiDU binary download operation. Improved Ini parser to properly handle malformed Project Infinity metadata: Correctly handle multiline mod descriptions Fix erroneously detected comment prefixes inside BEFORE/AFTER definitions

Thanks!

Good to know, thanks. Looks like I guessed it right so far.

There also seems to be a way to define component-specific mod order within tp2 scripts by using METADATA tags. An example would be Iwdification. I don't know if this method is already supported by PI since the above example was the only one I could find. In any case I couldn't find any mentions about it in the PI docs, so I had to guess the format for the most parts.

Without PI's source code available I can only speculate, but I guess that PI performs line-wise parsing of INI content where skipping invalid lines is a trivial matter. WIT uses the more conventional token-based approach which is more flexible but also requires more effort to handle malformed data. It's a good start but the requirement of case-sensitive key names could be problematic. I don't think any of the established INI format specs would cover the PI metadata format precisely.

Thank you!

Relying on that would work fine in an ideal world. But there will certainly be more mods with multiline descriptions (since this is the natural thing to do if you don't know the exact ini format specs). I'll try to make the parser more lenient in that regard to show metadata even with malformed description entries.

That's actually the metadata file format that was originally invented for Project Infinity, so I didn't have to reinvent the wheel. There are certainly better formats available, but the INI format is simple enough to be understood by the average modder who doesn't know about yaml, json, and co. TOML looks promising but it is ultimately @AL|EN's decision whether to make the switch for PI.

That's surprising since I was using a popular package creation tool for it which should have been whitelisted by antivirus tools already. I'll see what I can do. I haven't opened a separate Discussions section on GitHub yet because there are already topics on Beamdog Forums and a forum section here on G3. The "Issues" section on GitHub is available, however.

On Linux I have only tested on casefolded ext4 partitions. I'll try to reproduce this issue. It was an intentional decision to not make it a full-fledged mod manager. We already have Project Infinity for that. I will add more features later, however, which also include more options for unattended installations.

Thanks!