Jump to content

AL|EN

Modders
 View Profile  See their activity

  • Posts

    1,323

  • Joined

  • Last visited

 Content Type 

Forums

Events

Downloads

Gallery

Mods

News

Store

Posts posted by AL|EN

    On mod metadata, and INI files

    in WeiDU Install Tool

    Posted

    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.

    MAC OS weidu launcher mod_order.txt

    in General Mod Discussion

    Posted

    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.

    A Basic Modder's Guide to Git and Github

    in Modding How-Tos and Tutorials

    Posted

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

    Infinity Auto Packager - automatically generate mod packages when you publish a release

    in Modding How-Tos and Tutorials

    Posted

    12 hours ago, suy said:

    No. AsciiDoc is the input, HTML the output, and the tool is the generator. I don't update the HTML along the AsciiDoc, because I preview the AsciiDoc either directly in my browser via an extension, or on Github/Gitlab/etc. Same as any other generated file. I don't diff those, as different parameters to the generation create different outputs. I just ship it to users because they have no use of the source, but of the output. Same that I don't diff the generated assembly of the code that I just compiled.

    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. 

    12 hours ago, suy said:
    • The IEMOD format has no binary embedded inside, like IMHO, it should be. It's just a ZIP file.
    • The claim that the ZIP file doesn't have a Linux binary because "for Linux is impossible" is wrong, and I just pointed out that.
    • You said that you meant something else, which is fine, but then I point out that then it makes even less sense any claim that you can't put a Linux binary (and I insist, Linux binary... Linux-only binary), because it can just have a different name than the other two. The MacOS version already has a wrapper to run it, so the Linux one could have it as well, and pass the arguments to WeiDU so it can be "double clicked to run", if anyone is interested in that. I'm not asking for you to do the work (I'm not asking anyone to do the work, because I don't think any Linux users are gonna care at all).

    To summarize: IEMOD seems fine to me, and I don't see why the need of a ZIP package with binaries inside, but if it has to have them, better do it right. I see more Linux users on Discord than Mac ones (though might be survivor bias), and with the Steamdeck this can go even higher.

    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.

     

    Infinity Auto Packager - automatically generate mod packages when you publish a release

    in Modding How-Tos and Tutorials

    Posted

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

     

     

    Infinity Auto Packager - automatically generate mod packages when you publish a release

    in Modding How-Tos and Tutorials

    Posted

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

    Infinity Auto Packager - automatically generate mod packages when you publish a release

    in Modding How-Tos and Tutorials

    Posted

    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.

     

     

    Infinity Auto Packager - automatically generate mod packages when you publish a release

    in Modding How-Tos and Tutorials

    Posted · Edited by AL|EN
    typos

    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.

    The Linux User's Guide to Installing Mods on the Enhanced Editions

    in Modding How-Tos and Tutorials

    Posted

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

    The Linux User's Guide to Installing Mods on the Enhanced Editions

    in Modding How-Tos and Tutorials

    Posted

    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:

    Quote

    Even if the mod use lovercased filenames, the engine expect specific file case for some of the areas like chinit.key, portiat filenames etc. So even when the mods are lovercased, a linux user still has to use case-insensitive filesystem. 

    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.

    Mod Compatibility List for EET

    in Enhanced Edition Trilogy

    Posted

    On 9/4/2023 at 6:46 PM, RaaDeeK said:

    Secon thing... in 2023 when i want to start EET it means i want to start 300-500 hours gameplay I need to install ALL MODS that i will ever need in the beginning of my journey. If i will change my mind and want to install any additional tweak or sth i need to restart my playthrough cuz mods will crash... seriously? In 2023? Thnk u all modders for ur great job but this is sick in my opinion. Dont know if i will start my playthru because of yesterdays bug

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

    Conflicting use of areas/game resources

    in Modding Q&A

    Posted

    On 9/7/2023 at 12:34 PM, Imiona said:

    Really? I cant get the other one to run on my (ancient) System, so i have to use that Manager :(

    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.

×
×
  • Create New...