suy

Larloch's Minor Drain, if I read the documentation correctly, is supposed to be changed to do 1d4 at level 1, and scale with levels. The issue is that it still keeps the parameter1 to 4, so it instead does (at level 1) damage between 5 and 8. I cleared the value to 0 with NI, and it goes back to 1d4 as intended. I found this on the larloch.tpa (EDIT: this is in SCS v35.10, BTW): spl.edit[%WIZARD_LARLOCH_MINOR_DRAIN%A %INNATE_LARLOCHS_MINOR_DRAIN%A|allow_missing:i=1 edit_strrefs_in_place:i=1] [ m.ab.clone{s_level=3+2*entry_index|number:i=4} m.ab_fx.alter{s_dicenumber=p_level/2 + 1 s_dicesize=4 s_drain_hp_to_caster=1|match="s_opcode=12"} ] I suppose it lacks a s_parameter1=0 on the "alter" line. PS: Look mom, I'm learning SFOv2, I think.

Thank you, David. I thought it would be better to report it the other way around, since lefreut was explicitly making commits for ToF compatibility. The weidu.log was on the URL of the link in my post (to Github's Gist, a paste bin), though I added the UI.menu, and since it sorts alphabetically, and the UI.menu is huge, you need to scroll down a lot to find the weidu.log. Anyway, here is pasted for convenience, as it's not that long (and the game was BG1EE, and Lefreut's version of the UI is for BG1EE as well): // Log of Currently Installed WeiDU Mods // The top of the file is the 'oldest' mod // ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name [ : Version] ~LEUI-BG1EE/LEUI-BG1EE.TP2~ #0 #0 // lefreut's Enhanced UI (BG1EE skin) - Core component: 4.7 ~HIDDENGAMEPLAYOPTIONS/HIDDENGAMEPLAYOPTIONS.TP2~ #0 #0 // Install all Hidden Gameplay Options at once: 4.6 ~CDTWEAKS/SETUP-CDTWEAKS.TP2~ #0 #182 // Unique Containers [Miloch] -> Unique icons and names: v16 ~CDTWEAKS/SETUP-CDTWEAKS.TP2~ #0 #3290 // Personalize Automatic Save Names -> Use scheme: 000000000-Protagonist-Save-Name: v16 ~CDTWEAKS/SETUP-CDTWEAKS.TP2~ #0 #3300 // Death Cam: v16 ~CDTWEAKS/SETUP-CDTWEAKS.TP2~ #0 #3355 // Create Interval Saves [argent77] -> Every 30 minutes (cycle through four saves): v16 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #1500 // Include arcane spells from Icewind Dale: Enhanced Edition: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #1510 // Include divine spells from Icewind Dale: Enhanced Edition: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #1520 // Include bard songs from Icewind Dale: Enhanced Edition: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #2000 // Install all spell tweaks (if you don't select this, you will be given a chance to choose by category): Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #2500 // Add 9 new arcane spells: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #2510 // Add 6 new divine spells (some borrowed from Divine Remix): Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #2520 // Revised Elementals: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #20000 // Introduce new races and subraces: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40100 // Revised class alignment rules: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40200 // Icewind Dale-style paladins: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40300 // Revised Smite Evil: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40470 // Rebalanced thief and bounty hunter traps at low levels: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40500 // Revised favored enemy for rangers: new enemy groups, and rangers reselect their favored enemy at 4th level and every third level thereafter: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40650 // Revised speciality priests of Lathander/Helm/Talos/Tempus/Tyr: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40700 // Allow monks to use staffs: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40800 // Require speciality mages to memorize at least one spell per level from their speciality school: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40850 // Speciality mages automatically get one speciality spell at each level (where possible): Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40900 // Allow multiclassed and dual-classed mages to become specialists and wild mages: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40925 // Bloodlines for sorcerers: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #40950 // Dragon Disciples can be disciples of any chromatic dragon (Red/Blue/Green/Black/White): Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #41000 // Rebalanced and revised kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50000 // New wizard specializations: elemental specialists: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50100 // New wizard specialization: Force Mage: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50200 // New wizard kits: Militant Wizards: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50300 // New sorcerer kit: Bloodrager: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50400 // New choices of god / goddess for speciality priests: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #50500 // New class: Favored Soul: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55000 // Allow druids to multiclass as mages, rangers, and thieves: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55100 // Multiclass/dual-class fighter/cleric kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55200 // Multiclass/dual-class fighter/druid kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55300 // Multiclass/dual-class fighter/mage kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55400 // Multiclass/dual-class fighter/thief kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55500 // Multiclass/dual-class cleric/mage kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55600 // Multiclass/dual-class cleric/ranger and druid/ranger kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55700 // Multiclass/dual-class cleric/thief and druid/thief kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55800 // Multiclass/dual-class mage/thief kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #55900 // Multiclass fighter/mage/cleric kits: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #60100 // Characters choose minor new abilities every three levels: Beta 7 ~DW_TALENTS/DW_TALENTS.TP2~ #0 #60300 // Improved NPC customisation and management: Beta 7

I'm doing an installation where I just wanted to play the Black Pits with new stuff from Talents of Faerun... but I love your UI so much that I can't resist trying both, specially seeing that you are adding compatibility here and there. It's very much appreciated! I've found another incompatibility with Talents of Faerun, though. With the "Characters choose minor new abilities every three levels", the abilities screen gets "dead locked" on level up. I tried to press any of the buttons, but it only highlights the ability, and it never increases, so you can't go back or forward. This is the weidu.log with the choice of components, and I've pasted also the full UI.menu in case it's useful. https://gist.github.com/suy/e4771a6629325774a75f7b37b93db8e4 Note that, while I installed v4.7 of LeUI, and that's what shows on the log, I noticed your commit and release for 4.8 layer yesterday, so I've also applied the patch manually with the `patch` tool. The patch applied cleanly, and the UI.menu of the link should have the changes properly applied, but both with 4.7 and 4.8 I seem to have the issue. Let me know if I can dig into this and help out somehow. Thank you again!

I have a small bug report that I don't seem to find reported yet. When Druid/Thief is chosen, seems that the game actually picks up a Cleric/Thief. Alignment, proficiencies, and spells, seem to be this combination instead of the Druid ones. The UI also displays Cleric/Thief. I think I've seen this with another "new" Druid/X combination, but now I can't find which (there are so many options and I'm still digging ). Thanks!

In that case, you can still check with `git clean`, using the `-x` flag. E.g. `git clean -xdn` won't delete anything, but will list the files that would have to be removed.

I think Amelyssan is pretty good. Sarevok seems OK. Maybe not 100% similar to what the original, but good enough to be a pass for me. So, from my POV, don't get discouraged. I would like to see more myself! I also would love to have the time to tinker with Stable Diffusion.

It's been an awesome ride. Don't feel bad for the time you won't be able to put in the future, but feel great for all that you've accomplished. Seriously, thanks!

Please, pretty please, whatever you choose, don't go with allowing multiline entries. This is not the default behavior, and as I've shown, I've tried different INI parser libraries out there and no one supports it. It means throwing away perfectly good code that already exists in battle tested libraries, and that follows the loosely specified conventions. Going that route is a huge incentive to not support those files at all for me. PS: the criticism of TOML is unfair. No one should care that TOML supports times and dates, because every field of a mod metadata would only contain strings. So the mod metadata of any given mod that I've ever seen is just the same as no, but with quoted values. PI should have no issue in adding a new library and linking statically, which I assume is what you are doing already for having the application in a single file. But anyway, let's ignore TOML or other formats entirely, and instead focus on fixing the INI definition, please.

Totally understandable! Just to be clear: you would not NEED to change to the new format if both are kept for some time (or forever, with the old being deprecated), similarly to how there are both DESIGNATED and LABEL for mod components. Additionally, this could be done automatically, and even via pull requests so you would only have to press the merge button if you'd liked to. But again, yes, I understand that it's effort. I just wanted to bring up the possibility of it being worth it. Just that.

Agreed, but if I'm suggesting the new format is because: The new format is 95% the old one. It just requires putting the values in quotes. The new format allows putting multiple lines if the mod author likes so (either type the \n, or put the text in multiple lines with triple quotes instead). The new format has plenty of existing libraries to use. Several to choose from for Java, C# or C++ (for WIT, PI and Zeitgeist respectively). No need for a handwritten parser (though I imagine there should be plenty for INI as well in Java). Less risk of getting bugreports due to incompatibility between apps for this or that quirk. Online validators exist. I don't think the format itself is a problem. Transitioning to it is surely an inconvenience... That's why I also support keeping the old one. I just don't see such a clear path on how to clarify the format to ensure no future issues arise. If we go with the old one (which would also make sense, I just want it to be a well informed decision), I can try making a validator for the files, so modders can try it if they want some validation. It still has the risk that somebody else's validator behaves a tiny bit differently. Thanks.

Sure, I meant just the idea of how the lines and the keys are specified. This is why I worried about the format being potentially problematic... If it's only for PI, then, it either works there, or not, and it doesn't matter. If it is supposed to be for different tools as well, I wish it is something that can work in all of them without having to guess if it's an issue in one tool, the other, or the mod. There are more tools now. 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. Before knowing that you would publish your project, I was working on my own a bit on Zeitgeist. If tool authors are going to ask modders the favor of writing this metadata, better that we do it well. I'm maybe being overcautious, though. It is not a huge incompatibility issue now. I just want to think forward.

FWIW, seems PI shows just the first line, and I think just the first line is the correct result. The other parsers that I've tried do that as well. I would just clarify so in the wiki page. The desktop file specification can be used for inspiration. It is said that it is delimited by new line characters. I think this makes sense. The format is just not suitable for more.

First of all, congratulations for the release, of course! I want to start a new thread to not clutter the first one with a very specific issue. I've noticed form the screenshot that you seem to provide support for mod metadata. While I agree on the value on having a mod metadata file that doesn't require launching WeiDU to obtain it, I find that the choice of INI files is potentially problematic. I imagine the fact that is simple, and that some mods are already parsing it inside WeiDU might be a reason to pick it. But the loosely specified format can yield different results with different parsers, and I wanted to have your input on the topic. For example, Jastey's SoD Tweakpack (sorry Jastey, just an example, not to complain on you, on the contrary!) yields me this output when parsing the metadata with a Lua library (and I get the same on C++ with Qt): 21:37 alex@leela /tmp$ lua Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio > inifile = require 'inifile' > ini = inifile.parse("/home/alex/projects/infinityengine/3rdparty/mods/Jasteys_SoD_Tweakpack/c#sodtweaks/c#sodtweaks.ini") > print(ini['Metadata']['Description']) This tweak pack is mainly meant for the SoD part of BG:EE (except for the last component which introduces Imoen's SoD portrait into BGII). Seems fine, right? But Then I get this with Ruby: irb(main):003:0> ini = IniFile.load('/home/alex/projects/infinityengine/3rdparty/mods/Jasteys_SoD_Tweakpack/c#sodtweaks/c#sodtweaks.ini') /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:578:in `error': Could not parse line: "It deals with some tweaks that I found useful for my own game." (IniFile::Error) from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:532:in `block in parse' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:515:in `each_line' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:515:in `parse' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:400:in `parse' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:128:in `block in read' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:128:in `open' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:128:in `read' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:80:in `initialize' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:31:in `new' from /home/alex/local/gems/gems/inifile-3.0.0/lib/inifile.rb:31:in `load' from (irb):3:in `<main>' from /usr/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11:in `<top (required)>' from /usr/bin/irb:23:in `load' from /usr/bin/irb:23:in `<main>' Woops, what hapenned? The issue is that the line is truncated, and the above that seemingly worked, actually lost a bit of text: # Short description of the mod, main goals, features etc Description = This tweak pack is mainly meant for the SoD part of BG:EE (except for the last component which introduces Imoen's SoD portrait into BGII). It deals with some tweaks that I found useful for my own game. So, different implementations can have this quirks... I don't know how feasible this can be for your implementation or AL|EN's, but ideally, I would propose gradually switching to TOML. This is very, very similar to INIs, so it's easy, but it is well specified, and it supports for example splitting a long string across multiple lines, or having arrays for the installation order. For most mods it would be a matter of copying the INI with the different suffix, adding quotes on the values, and call it a day. The alternative is of course to narrow the definition of the INI for mod metadata to something much more tight so this doesn't happen. Now that there are at least two implementations (and I've always considered doing one myself, or contributing to Zeitgest, and a few people are doing modding tools like modda or mod_installer), so I think it's no longer a theoretical concern.

I made a new copy of BG2EE, copied iwdification, then opened the TP2 with WIT. It could not parse the components. The log outputs this: 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.process.ProcessUtils.getProcessOutput() DEBUG: Working dir: /home/alex/local/GOG/2.6/bg2ee/game 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.process.ProcessUtils.getProcessOutput() DEBUG: Command: [/home/alex/local/bin/weidu, --nogame, --list-components-json, /home/alex/local/GOG/2.6/bg2ee/game/iwdification/setup-iwdification.tp2, 0] 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.process.ProcessUtils.getProcessOutput() DEBUG: Timeout: 30 ms 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.weidu.Weidu.getModComponentInfo() DEBUG: Parsing mod component JSON data (buffer=175 bytes) 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.weidu.Weidu.getModComponentInfo() DEBUG: Successfully decoding mod component info (charset=UTF-8) 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.mod.ModInfo.getComponentInfo() DEBUG: Could not retrieve component info: java.lang.Exception: Could not retrieve mod component information at io.infinitytools.wit@0.10.1/io.infinitytools.wit.mod.ModInfo.ensureComponentExists(ModInfo.java:352) at io.infinitytools.wit@0.10.1/io.infinitytools.wit.mod.ModInfo.getComponentInfo(ModInfo.java:215) at io.infinitytools.wit@0.10.1/io.infinitytools.wit.gui.MainWindow.checkModOrder(MainWindow.java:1949) at io.infinitytools.wit@0.10.1/io.infinitytools.wit.gui.MainWindow.execute(MainWindow.java:2015) at io.infinitytools.wit@0.10.1/io.infinitytools.wit.gui.MainWindow.setupUI(MainWindow.java:1408) at io.infinitytools.wit@0.10.1/io.infinitytools.wit.gui.MainWindow.start(MainWindow.java:521) at javafx.graphics@21/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:839) at javafx.graphics@21/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:483) at javafx.graphics@21/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:456) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics@21/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:455) at javafx.graphics@21/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at javafx.graphics@21/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at javafx.graphics@21/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$10(GtkApplication.java:263) at java.base/java.lang.Thread.run(Thread.java:1583) 2023-10-20 21:51:37 [JavaFX Application Thread] io.infinitytools.wit.gui.MainWindow.getWeiduCommand() DEBUG: Guided mode, WeiDU command: [/home/alex/local/bin/weidu, iwdification/setup-iwdification.tp2, --no-exit-pause, --game, /home/alex/local/GOG/2.6/bg2ee/game, --log, /home/alex/local/GOG/2.6/bg2ee/game/setup-iwdification.debug] 2023-10-20 21:51:37 [] io.infinitytools.wit.gui.MainWindow.onProcessStateChanged() DEBUG: Process StateChanged event: Started Tested on Linux, on a ciopfs file system. Let me know if I need to provide extra info. Congrats for the release! PS: Seems that, at least right now, is single mod focused. Is that an ultimate goal, or more mods at once is planned? I was just today testing Zeitgeist, and while it would require a good facelift to be comfortably usable, it seems to be able to detect N mods, pick up components from them, then install them, or detect what is installed and roll it back. I don't know if it requires tweaks to work on Mac or Windows, though, I only tested on Linux.

NOTE: I'm posting this because I spent some time researching and drafting this post, but as I conclude in the end, it is not possible to do what I wanted. Posting anyway in case it's useful for someone else who searches in the future. --- Hey, what a coincidence... I've been doing a Bard kit for some time, and some hours ago I was thinking of changing item restrictions entirely in the design. I hope you don't mind that I followup on the thread, as it's fairly related. I got inspired to do this kit when reading jmerry's wee cant spell post (and a hodge podge of other stuff), and wanted a bard which loses spell casting (instead of armor), but it's specially good in combat. I capped the native spell casting with a bunch of #42 effects, and balanced it around the fact that wands and scrolls be usable, as I did not want to do mass changes to items. But you got me thinking... I've gone so far with the default usability flags because this allowed all the Bard items like the Bard Hat, musical instruments, potions, etc. But I certainly miss Warrior-usable potions, like Heroism, Strength, etc. AFAIK, it is not possible to use effects to open an item to a certain class/kit, so the approach tends to be the opposite, and do like the Shaman: shares the usability flag with Druid, but Druid-forbidden items have the 319 effect on them. This other post seems to confirm (also by jmerry, also a coincidence ), and I did some tests to understand what's going and, indeed, I can only restrict items further, even with 319 and Power=1. So, for my Bard kit idea, I thought doing this: Pick the usability field of Fighter/Thief instead of Bard. Restrict helmets, heavy armor or whatever I find not suitable to the theme of this class that come from the Fighter side. Doable with the 180/181 effect on the CLAB. Maybe restrict some items coming from the Thief side, but probably not even bother. The Ring of Danger Sense seems equippable by everyone... it just doesn't make sense to wear it if you can't detect traps. I could do the same with the Ring of Lock Picks, etc. This would be done on the item with a 319. If I want to enable back Bard items (not even sure it's worth it for this concept), it would require unsetting the "unusable by F/T" on them, then adding a 319 on F/T to disable it back. Now, I just assumed that (1) was possible because of the ideas given here about kits from other classes made me think one could specify this in the kitlist.2da, but it seems I totally misunderstood what is possible. After checking the kitlist.2da more in depth, it seems that no, it's just the 4 bytes of the usability for kit, but not the ones for the classes. I'll have to keep doing things as before.

Not exactly. There is no way around making new commits to register changes in the repository. The key thing about the repository is that it registers an exact state. If you have a set of files in one location, and that location is shared to two repositories, you'll nave to make two commits.

Thank you for clarifying. Then, what did you mean you said: That's what got me really confused. I thought you reacted because I forgot originals and/or GemRB players.

Sorry. What I meant was that for people playing the originals on Linux with GemRB, the engine might have enough fixes to not suffer from case sensitivity issues. My train of thought was: For the EEs, everything seems to point that you need case insensitive file system, for what I've said in the previous comment. For the originals, those are Windows only, so you install Windows' WeiDU, so you don't worry about case insensitive issues. Then you said that it's not a must have, and I thought I forgot about GemRB, and you were criticizing that I forgot it.

With that, do you mean that you have achieved to install mods on a EE game without a case insensitive file system or not? I'm confused. I would be super happy to get rid of it, but I don't know how, and I assume is not possible. And the fact that people in this post are mostly discussing case insensitive file systems seemed to indicate it to me. But I would be very happy to find out that this is not the case (no pun intended). This is what I get on a pristine EE game when trying to install a simple mod: 08:02 alex@leela ~/local/GOG/2.6/bg1ee/pristine$ weinstall all-the-things-revised/ weidu --log "setup-all-the-things-revised.debug" "all-the-things-revised/setup-all-the-things-revised.tp2" [weidu] WeiDU version 24900 ERROR: Unable to find DIALOG.TLK in: ./^dialog/.tlk$ Please run this program in your Infinity Engine game directory. FATAL ERROR: Failure("Unable to find DIALOG.TLK") After making a en_us to en_US symbolic link (tolower refuses to run on detecting a EE), WeiDU sees the TLK, but then the very first mod component fails to install: Compiling 1 script ... ERROR: BIFF [./DATA/DEFAULT.BIF] cannot be loaded: Unix.Unix_error(Unix.ENOENT, "stat", "./data/default.bif") ERROR locating resource for 'get_ids_map' Resource [TRIGGER.IDS] not found in KEY file: [./chitin.key] I get similar errors with other components. If you have a solution where everything works with a "symlink farm" or the like, I might give it a try. Now, I think at one point, when I had some custom files for my mod, and was upgrading from manually copying them to making it with weidu, I was able to get weidu to run and install that hyper-trivial mod, but then the game would not start. I don't remember why (I think I noticed the chitin.key being altered for some reason). Only with a case insensitive file system, I've been able to make both things work. I agree with you that it is annoying and risky to ask users to change partition settings or create images for mounting them. 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. And to add insult to the injury, some versions of tune2fs can enable casefold, but not remove it! So I had to borrow a computer to flash a newer USB image with a more recent tune2fs to be able to remove the flag. For reasons like this, I'm stuck with ciopfs. It's what I have been advicing to use in my guide. I don't like the duplicated files, and the slow FUSE performance, but I don't see any other way. Argent77's comment said so, and no one seemed to argue against. So TL;DR, I dislike it for a few reasons, but unless someone shows me how to do without the case insensitive solution (wink wink), I'm assuming is necessary. PS: By the EE bugs I suppose you refer to what is mentioned on kjeron's comment. I don't see how that changes the issue in favor or against one solution, sorry if I missed something.

Thank you, I already know about it, and was even commenting on its thread about the issues I see. I'm asking not on existing projects that "solve the problem", but more on what needs to be solved, and why. After having the proper grasp of it, I can go with one solution, the other, or even a custom made one, or contributing additions/fixes to a solution, etc.

I have needed to do so in every installation on the EE for sure, and I don't see when tolower is useful. But OK, followed up in the other thread (hopefully that's the one you meant).

To which bugs are referring to? I have never been able to make WeiDU run on a EE game in a file system which is not case insensitive. The problems were too many. And tolower was never useful. For the originals, I've always assumed that since the game is Windows, it was better to just run WeiDU compiled for Windows anyway. For GemRB, I don't know. I would still attempt to use the checked out git repository with a symbolic link to the game directory. That is too convenient and has so many advantages for me. But could be that this doesn't work. So, to follow up from the other thread, when is a case insensitive partition not needed, and/or when is tolower needed?

I forgot: another thing that the ModPackaging does (conditionally, can be opted out), is calling tolower. I am confused why this is done. I'm not sure this is anymore a good practice. I have been using the mods straight from their git repositories without any conversion, and those were done by windows users with their choice of upper and lowercase files. This should be fine as for Linux you need the case insensitive directory anyway... If I/we get a clear picture of what is needed and recommended, I might submit changes to the ModPackaging, or write an alternative script for Unixes.

Thank you. I knew about that tool, but my goal was more to research what other existing tools accomplish, to do it myself. In other words, what packages they create, and which might be optional? One problem that the ModPackaging tool has is that it unconditionally uses dotnet to compile Markdown with the DLL embedded there. I don't have that installed, and I don't need to compile Markdown, but AsciiDoc instead, so I need something different. The script is too inflexible for me. I did not realize of the G3 branding, but I actually will like to have it, as I want the mod to be part of G3.

But as I was saying, you only need to make the AppImage of a binary if it uses shared libraries (or other assets), and WeiDU doesn't. It has everything statically linked. If you want to provide side by side the mac and linux binaries, just give them different names. If the issue is "but then both need to be 'setup-foo' to run automatically the 'foo' mod", then run the linux version through the shell script, the same way the mac one is run through the .command file (which just seems a weird shell script to me).