@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!

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.

The tool is currently available for testing. More information can be found in this topic: Call for beta testing, translations and proofreading!

Download: GitHub

Discussion: G3

Readme

WeiDU Install Tool

Project: https://github.com/InfinityTools/WeiduInstallTool

Readme: https://github.com/InfinityTools/WeiduInstallTool/wiki

Download: https://github.com/InfinityTools/WeiduInstallTool/releases

Overview

WeiDU Install Tool (WIT) is a graphical front end for the WeiDU command line tool to install modifications for Infinity Engine games, such as Baldur's Gate, Icewind Dale or Planescape Torment.

The tool offers all 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 it can also be used for more general WeiDU operations. It is not intended to be a full-fledged mod manager like Project Infinity.

The tool is currently available as a pre-release version for Windows (installer), Linux (RPM and DEB packages) and macOS (PKG archive).

Application features:

• Tp2 Mod File association (except for macOS): Double-clicking on tp2 files in the file manager starts the mod installation.
• Drag & drop support: drag mod files or folders onto the application to start mod installations.
• Application text and messages are available in the user's native language (if available, see below).
• Toggle between light and dark user interface.
• Display additional information about mod components and general mod information.
• Quick input buttons allow you to install mods without having to use the keyboard. (Keyboard input is still available, though )
• and many more...

Testers wanted!

The mod has already been lightly tested and considered stable for many use cases. However, players have different ways how to install mods or may have different expectations what a mod installation tool should provide. I'm looking forward to any kind of feedback, suggestions, bug reports or feature requests.

Translators wanted!

The application is able to display UI text and messages in the language set up by the user's operating system.

Currently available languages are:

• English
• French (by JohnBob)
• German
• Brazilian Portuguese (by Felipe)

More languages are always welcome, however. Translation is handled similarly to how mods provide multiple languages. Please let me know if you're interested in this topic or via private message.

Proofreaders wanted!

I am also looking for proofreaders for the English lines of text (translation file).

The sources for EE Keeper are still available at SourceForge if someone wants to take a look. There is also a bug tracker with a whole bunch of issues that have accumulated in the meantime.

41 minutes ago, subtledoctor said:

I wonder if NI could get some kind of shortcut to editing characters in savegames?

That request has come up several times in the past.

Shortcut always run the risk of introducing subtle bugs (except maybe for the most basic modifications.) Moreover, the way how resources are handled in NI makes it very cumbersome to implement new interfaces for editing data. Most of it would have be implemented from scratch. Not something I'd be really looking forward to.

[bg2ee] Potion of Perception: Discrepancy between item description and actual effect

The Potion of Perception (POTN39.ITM) should provide a bonus to the follow skills according to the item description:

• Find Traps: +20%
• Pick Pockets: +20%
• Open Locks: +20%
• Move Silently: +20%
• Hide In Shadows: +20%

The item itself, however, lacks the skill bonus for "Hide In Shadows".

This bug appears to be a carry-over from oBG2 where the same bug exists. And that bug was probably caused by an incorrect conversion from oBG1 when "Stealth" was split into "Move Silently" and "Hide in Shadows" in BG2.

I'm unsure how this issue should be fixed. BGEE lacks the "Move Silently" bonus in both item description and item effect. IWDEE provides a bonus to both skills in both item description and effects list.

Which leaves the following options how to fix it:

1. Fix item description only: Remove "Hide in Shadows" bonus from item description.
2. Apply the BGEE version: Remove "Move Silently" bonus from item description. Replace "Move Silently" bonus (op59) by "Hide in Shadows" bonus (op275) in the item effects list.
3. Apply the IWDEE version: Add "Hide in Shadows" bonus (op275) to the item effects list.
4. Or perform a more accurate conversion from oBG1 by preserving the net effect of "Stealth": Provide both "Move Silently" and "Hide in Shadows" bonuses to BGEE, SoD and BG2EE versions of the item, which requires fixing item descriptions and effects lists.

46 minutes ago, GloriousCheese said:

In that case, I should be trying 9 or 13, because of it not being alpha-blended, right?

Yes, but only if 15 or 11 doesn't fix everything. Converting all game textures can take a long time.

1 hour ago, suy said:

Yesterday, I spent a considerable amount of time fixing my system because I enabled the casefold on my ext4 partition (and because lack of space, it is unfortunately the only one, without /home or /boot separated), and the system did not boot. After trial and error and unsuccessful grub reinstalls, I've reached to the conclusion that Grub doesn't recognize the ext4 partition with that setting enabled, unfortunately.

It looks like grub does not support the casefold flag on the boot partition (and probably never will considering that it's a rather exotic flag.)

Btw, I have also made an attempt to install mods on an EE game on a case-sensitive partition, but didn't succeed. To even proceed to the mod language selection I had to lowercase any single game language folder names first.

But then I couldn't proceed much further because of mixed case biff files (both file names and chitin.key references). When invoking WeiDU with the "--case-exact" option WeiDU expects all biff files in upper-case. Without that option it expects all biff files in lower-case. In any case, it's just not a feasible for the average player who just wants to install the occasional mod on their Linux version of the game.

6 hours ago, GloriousCheese said:

Only iOS is specified. I've tried number 4 & 8. Both showed textures as black. While number 16 still has the flickering. Left number 12 to try.

PVRTC is the texture format of choice for iOS. ETC1/ETC2 are supported by Android devices.

You should try options 15 or 11. The tileset in question isn't alpha-blended.

But I'm not sure whether the "override only" options are sufficient. EET automatically places imported BGEE content into biff archives, which are not considered by the aforementioned options.

Any pause can trigger the bug. I haven't tested it, but auto-pause option "Weapon unusable" could trigger at the same time when this spell effect is executed.

16 minutes ago, Galactygon said:

Good change. Due to the auto-pause bug, a more robust way is to fully embed it inside a 326 (p2=145, p1=2) rather than placing a 318 protection in front of the cast spell effect. The SPLPROT.2da entry is already there in all IE games.

Good point. Will be fixed.

53 minutes ago, Jarno Mikkola said:

Have you looked at what DavidW has done in the Troll component of the SCS ?

I have now. There are certainly different ways how to implement the regeneration behavior of trolls.

13 minutes ago, Morgoth said:

Am I wrong, or you didn't use the method highlighted here? 

Yes, it basically addresses the issue mentioned in the linked post.