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.

33 minutes ago, JohnBob said:

I see the variable added in .are files but if I check for CLUAConsole:GetGlobal("POFAREA","MYAREA")

All I got is Global: POFAREA MYAREA so not sure everything go the way it should...

CLUAConsole works a bit differently. You have to use the current area resref as scope name to return the value.

1 minute ago, JohnBob said:

If I understand correctly you talk about add a variable like !Global("MyMod_Quest_Is_On","GLOBAL",1) that could be used like you do in Totlm ?

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.

35 minutes ago, Acifer said:

If there is another good way to patch the numerous scripts, I would of course be happy to use this alternative.

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.

37 minutes ago, Acifer said:

My suggestions:
1. areatype WILDERNESS (or WASTELAND): an area outdoor type, like areatype FOREST, but for areas so far away that no NPCs are spawned for quests (e.g. for Jaheira's quest).
2. an areatype EXTRAPLANAR for outside locations in the Multiverse
3. And, if I may have a wish: areatype UNDERDARK (underground, but no dungeon)

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.

53 minutes ago, JohnBob said:

I was wondering about the number of mods using this function !

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.

1 hour ago, AL|EN said:

When I'm installing the new version, this should not be necessary.

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.

4 minutes ago, phlaphee said:

DjinniCompanion:0:Full Version (includes quests, banters and more)

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.

1 hour ago, Jarno Mikkola said:

Wha... have you tried the other version of the Near Infinity, that doesn't use Java ?

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.

2 hours ago, AL|EN said:

Thank you for providing a portable version of the application, that doesn't require java to be installed. If only the same could be true for NI...

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) :

[Name]
Mod Example - Optional Features

[Author]
AL|EN

[Description]
This mod is a guide on how to use optional 'Project Infinity' features.
Multiple lines are allowed.

[Readme]
https://example.com/ModName-Readme.html
https://example.com/ModName-Readme-%LANGUAGE%.html

[Forum]
https://www.example.com/forums/categories/forum-thread

[Download]
https://github.com/AccountOrOrgName/ModExample-OptionalFeatures

[LabelType]
GloballyUnique

[Before]
ModX
EET_end

[After]
EET
ModY
ModZ

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.

8 minutes ago, Felipe said:

Suggestions for improvement:

1 - Is there a way to see the GUI without opening any files? I'd like to see how my translation looks in the tool's GUI.

2 - Why when the tool is searching for a file it starts the search on C:\Users folder? No one stores mods there, it would much and i mean MUCH better if it started a C:\.

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.

29 minutes ago, AL|EN said:

Since WIT already can handle multi-line key values for ini because there is a high probability that this will happen again, I will try to do the same for PI also since this limitation has no valid justification. There might be some edge cases discovered later but for now, let's support 99% valid usage.

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.

10 hours ago, suy said:

Besides WIT, there are some command line ones, which is unlikely that will read the description, but might want to read the Before and After keys.

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.

29 minutes ago, suy said:

The desktop file specification can be used for inspiration.

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.

4 hours ago, morpheus562 said:

I have gone ahead and linked to this in my install order repository. Congratulations on the release!

Thank you!

9 hours ago, lynx said:

The few mods using multiline descriptions just need to be fixed to use a single line description (ok, maybe escaping would work, but it's ugly).

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.

4 minutes ago, Incrementis said:

Maybe it would be helpful to mention this and explain how to deal with it so that the casual user isn't too afraid of getting all the warnings I got.

1. My browser blocked the file WeiduInstallTool-0.10.1-portable-windows.zip because it categorized it as an unusual file
2.  My antivirus scanned and deleted jrunscript.exe

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.

8 minutes ago, Incrementis said:

I don't know how helpful this following suggestion is, but the first place I wanted to report this was the GitHub discussion section (uploading screenshots is easier there in terms of size and not as limited as it is here). Unfortunately it's not enabled, but it only affects me so maybe it's not important.

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.

3 minutes ago, suy said:

Tested on Linux, on a ciopfs file system. Let me know if I need to provide extra info.

On Linux I have only tested on casefolded ext4 partitions. I'll try to reproduce this issue.

4 minutes ago, suy said:

PS: Seems that, at least right now, is single mod focused. Is that an ultimate goal, or more mods at once is planned?

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!