AL|EN

I've spent a lot of time When I tried to decide which format I should choose for mod metadata. Way way too much but I guess I can say that I did my homework on that matter. During my research of various configuration file formats such as ini, csv, xml, toml, yaml, HCL, HOCON, json, jsonc, hjson, json5, json6, strictYaml etc the conclusion was: no one wants to deal with file formats created by geeks for geeks just to be able to put mod display name, description and other not-so-important things. No one wants to deal with datatypes even if those are similar to IE datatypes. So it's either ini or custom format. The XML is crap, JSON requires escape sequences, and Yaml requires understanding that spaces matter. I've chosen ini since there are at least some specifications. Supporting extra file format is not as easy as it seems: Suy want's TOML, Magus want's yaml, someone else wants JSON and I want psd1. JSON and psd1 are built-in inside PowerShell/PI. But for TOML and yaml formats, I would need to write my own parser since it's not possible for PI to use already created parsers because PI is a single-file exe and its update system relies on that. Besides, yaml is unsafe and TOML has already been criticized as 'ini with types' thing. So for now, until critical requirements won't be met, let's stay with ini.

Congratulations on the release

Congratulations on the release! What do you think about the inclusion of this into weidu itself, for eg: HANDLE_CHARSETS_EX?

My question was about the MWL-specific workflow that you have used for so long: having a list of mods in a tiny window> launching the weidu console > interacting with it> repeating until the last mod. Some things aren't easy to let go. The alternative workflow proposal indicates that you already have a better idea in your mind. This is great except for the part where you rely on a 'static component list' - even if it's doable, don't go that road. Let me play with applesctipt + bash, but I fear that it might be too much of a challenge.

Tell me, does this feature is worth replacing your app with something new, along with the new data format for mod_list.txt?

One of the possible solutions to the "install SCS IWD Spells early" challenge would be to use SCS IWD spells component labels, '--ask-only' + some additional logic. This would require some coding work and other stuff but it's definitely possible.

@subtledoctor While using "Junctions" can be very helpful and time-savvy, Incrementis is right. It's possible that the library update made for one mod in order to fix one thing or add a new feature will break another mod because of this 'one little thing'. You can bet that there will be at least one bug that will happen because of it. Having to know a little bit about the nature of your mods, I'm sure that this will be helpful. Today, I lean towards that mod components should be monoliths unaffected without dependences. Even if it means that the mod doesn't use the newest, sexiest and up-to-date functions, unless there are bugs fixed, without changing behavior. Mainly because Weidu/IE doesn't have any means for testing mod changes in a running game except actually running the game and verifying everything manually. Having automated tests of the actual outcome of the function/libs would also be helpful. But it's not where we are with Weidu and I doubt that we will ever be.

@Intro Check if you have "iconv.exe" inside "ascension\lang\iconv| directory.

I understand the reason why you like it that way. It's common to generate some useful output. All I'm saying is that if you want those HTML files to be present inside your mod directory for Windows users who do use the PI mod update feature, you need to have them inside the repo. Now it makes sense. But iemod packages are not simple zip file as those can have variants and disallowed content. The one of key points of having iemod package is that it won't have weidu binaries. Instead, a mod manager will provide it. For Windows, there is PI, for Mac there is MacWeiduLauncher, the solution for Linux is right around the corner. I agree that it's possible to have a different name for weidu executable along with an additional shell script that will launch it. I will rewrite this statement. So far you are yet another person who claims that "Linux users don't care". For now, no Linux stuff inside the IAP zip unless there is a strong desire to do so.

@suy Those files are not simply generated, they are as you said, an internal part of the mod in order to provide easy-to-read HTML files. You update them along with AsciiDoc, the only difference is that for HTML, it's done via automation. Not having those files in the repository means that you can't immediately verify the conversion via diff, in order to make sure that the files added into the package are what you expected to be. Is this a best practice? The 'best practice' can be evaluated only with the goals. The goal of IAP with the combination of placing mods into the GitHub repository is to offer modders rock-solid, bulletproof delta updates for their mods. Having those goals means that some compromises had to be made. You might have different goals so the 'best practices' may differ. When it comes to IAP versioning, the 'master' branch model has proven to be working. And it's the best one when you take into consideration extra GitHub Actions stuff. The alternative you are proposing will require constant nagging regarding IAP updates, which I have no desire to do. Regarding Linux stuff, I feel that I'm hitting a wall here. Even if I don't use Linux myself, during discussions regarding iemod format, I invest some amount of time to handle this problem. I will be very happy if you provide a package where Windows, Mac, Linux executables are present and users can launch mod installation via double-click. So far you have posted a link to the experimental project which I had no clue about, that requires changing the whole build system of Weidu, and probably changing the codebase to be able to compile the weidu using the modern OCaml version and testing everything. If you think is "easy" feel free to do it, just don't tell me that I'm biased.

@suy regarding the 'compile' step: The solution to this problem is moving the custom step into a new workflow and running it on every commit along with committing changes, this might be helpful. I'm sure that you can handle this on your own. regarding using tags: It's against the design of this tool, especially when you need to recreate the old packages because of bugs/changes. If you really want to 'bound' IAP to a specific version, you can use commit IDs to do this. regarding the inclusion weidu Linux executable inside the mod package: I'm not quite sure what AppImage has to do with this so let me reword the 'impossible' statement: "Currently, It's not possible to include both Mac and Linux weidu executables, inside a single zip mod package, because both those files are provided without file extension" There ofc ways to handle this problem but it requires either modification of how mod launches weidu or modifying weidu code itself. regarding the "Forgotten Armament" package difference: The zip package is not created via IAP, it's done by G3 ModPackaging and added to release after creation. The iemod package doesn't have "*.html" files because those are added via G3 ModPackaging md2html custom action. Thanks for bringing up this problem, I will report it to the mod author and hopefully, the solution will be found.

I have investigated the 'custom step' case and my suspicions were confirmed. If the state of the mod inside the repository doesn't represent a full working mod, and there is a custom action that modifies the package content, it breaks the PI "mod update" feature because it resets the local mod directory to the repository's contents from the last release tag. While there is some guidance about this, it should also be reflected here. To summarize, if you want your mods to have rock-solid updates, don't alter the package creation in any way.

@lynx But that's my concern, If the lowercasing doesn't fix everything and using a case-insensitive file system/partition/directory does, that should be the preferred way. And if so, the BGForge should account for it.

After nearly 3 years since the creation of the first version, it's time for a major update. Thanks to recent GitHub improvements, version 2.0.0 switches to a global model: after updating the InfinityAutoPackager.yaml file in the repository, there shouldn't be a need to update it again to use new features and fixes. Multi-threading has also been incorporated to allow packages to be created simultaneously. This enhancement is only noticeable in the case of very large repositories, such as RoT. Additionally, it provides a workaround for the occasional issue where creating a new release doesn't trigger package creation. This problem has been confirmed by GitHub's team but no ETA has been provided. 2.0.0: - Switched to a global model - Added multi-threading - Workaround for skipped runs How to update: - the installation/update process remains unchanged, simply replace the content of the "InfinityAutoPackager.yaml" file inside your repository with the new version Thanks to @jastey for reporting skipped runs and @Graion Dilach for testing.

@suy It's the "Translation hints" feature from the BGForge. IIUC, even if the mods have lowercase their files, the WeiDU itself lacks the ability to follow the case of actual filenames when it modifies "chitin.key" or similar resources. @Graion Dilach If that's true, it's even worse: lowercasing the mod filenames doesn't help at all, as suy reported. It also breaks certain features from working. Not good. @kjeron I think that we can put such engine behavior into the 'names of the spells had to be maximum of 7 letters' category, thanks for reporting.

I've recently read some discussion regarding the above problem: [Project] A new language for writing mods — Beamdog Forums Calling @argent77 @lynx @Graion Dilach @suy Can the problem be mitigated using WeiDU '--case-exact' option?

First, the download process was interrupted so the zip archive is not complete. Second, the '-master' in filename indicates that you have in fact downloading 'master' branch. Redownload it again using this link: https://github.com/SpellholdStudios/BGGOEET/archive/refs/heads/v3-beta.zip or use git clone + git checkout 'v3-beta' cmd.

Hi, I recently discovered that one of the modding tools is not able to work properly on Windows because its internals are case-sensitive. The advice from the author was 'You must lowercase the mod files anyway'. I have no problem doing so even for a large amount of mods but I don't believe it's true. As such, I'm looking for the definitive confirmation of this statement: If somebody can confirm the above statement, or a similar one, maybe there is a chance that this tool will receive Windows support out-of-the-box.

@RaaDeeK Installing 'ALL THE MODS' will get you nowhere, there will be small bugs, medium bugs, and possibly bugs that prevent you from advancing further which require fixing game resources on the fly. This is the nature of the game and the engine that was used to create it. You have been warned. And if you haven't finished any of the game, it's better to do it at least once without mods.

If by 'ancient' you mean Windows 7, try to check if you have installed prerequisites. Regardless, please add "file" and "process" exceptions to your AV/Windows Defender.

Ascension 2.0.26 Fixed installation of Portuguese language @Ecthelion Should be fixed now.

The new version of the Ascension mod was released. It has a new Portuguese translation by Ecthelion and an updated German translation. Download the mod View the readme Learn more about the mod Forums Ascension 2.0.25 Added Portuguese translation by Ecthelion Updated German translation

Ascension 2.0.25 Added Portuguese translation by Ecthelion Updated German translation

@Ecthelion Can you please use this link: https://github.com/InfinityMods/Ascension/archive/refs/heads/master.zip and check if everything is fine?

@Ecthelion Very good, as for setup.tra: it has to use Portugal cp1252 characters, not Unicode ones so I adjust it accordingly.