AL|EN

@lynx 1.That's why it's opt-in, I'm sure that when SR/IT maintainers will like to have such feature for those mods, a simple rearrange of the repo should not be a problem. 2. and 3. Yep, I can add this later, I'm asking because I've already receive such feature request from one player at beamdog thread. 4. Indeed for diffs it shouldn't be any problem. Binary deltas aren't something which I could achieve without will and direct cooperation with site admins.

Automated way ensure that the mod has always lastest translation from IWD files, let's say from Polish translators which did great job for IWDEE. If the cost of including IWDEE spells updates is "missing formatting" then I take it with my eyes closed. There is nothing worse than having a spell description which tells me that the spell is doing something while it's not.

Hi, One of the most missed features for all past years was the ability to click one button in order to update my all local mods. Lucky, with the Github API, Project infinity can offer a possibility to update mods, which is very easy to add via one single line inside mod metadata file. Because it's github-based, it offers stability and consistency. And for the first time, there is a possibility for so called "delta updates"! As a sidenote: Github.com now offers private repositories for free! Right now, this system is opt-in and it's based on the mod metadata "Download" keyword: Download=https://github.com/Gibberlings3/SwordCoastStratagems Wanted features: easy to integrate simple and understandable rules for modders about when mod will be updated and how Assumptions: Mod use Github hosting (or the site which provide API) Mod has metadata file and filled 'Download=' keyword the update process don't touch mods inside game directory, only the mods from the directory where user has placed all mods General Flow: Phase 1: Read Mod Metadata "Download" keyword > Check if update exist > Present 'Update Available' for specific mod > leave local mod in touch until player hit "Update Mod" button Phase 2: the "Update Mod" button was clicked > Download update > extract and overwrite all mod folders and files / preform delta update, also overwrite all mod folders and files How it would work: Checking if there is a updated version of the mod is done automatically (but not the update itself) Notification about the update will be presented to the player ('Update Available' next to the mod name, "Update mod" button enabled") The update itself can be only accepted/started by player himself (in order to not break existing mod/components setup) Leave user-created files inside mod data folder intact for eg: mymod\mymod-config-user.ini Which update channels would be offered for players: if mod has releases, offer to update only if there is a new release if mod has only prereleases, offer the update for prereleases if mod has both releases and prereleases, offer the update for releases only, do not offer the update for prereleases unless there is a global option "Allow for prereleases" enabled if mod doesn't have any releases or prereleses, the assumption is made (mentioned at 'Download=' keyword documentation ) that the modder use master branch. For many modders, simply committing to master branch seems to be enough and I don't want' to force them to make releases. Modders can simply create Release in order to switch update chanel. When player decides to update the mod, there are two ways of updating locally extracted mod files: downloading release/prerelease, extract and overwrite all mod folders and files preform delta update, also overwrite all mod folders and files My main concerns are: Should I offer "Prereleses" for normal users, who aren't interested testing BETA versions and reporting bugs? (opt-in option?) Should I offer "download last commit" aka "experimental" for mods which do have releases/prereleases? (undocumented option?) Should I offer "download last commit" from specified branch like "devel" (undocumented option?) @argent77 AFAIK, you alone use different branches. What to do with files which were available in older version (let's say MYMod\Items\SWORD.itm) but the new one doesn't have them anymore? Removing old mod version directory entirely could potentially remove also user-generated config (only two mods have them but it's still important). It might be related to "Immutability: Nothing in your mod folder should change at all when the mod is installed." Does user-generated configs should also be outside of the mod folder, in order to achieve mod immutability? If such problem occur, any kind of solution for is doable at this stage. That's everything for now, any feedback will be appreciated. @K4thos Enabling this for EET will allow for EET delta update without re-downloading 250+ MB, what do you think?

@lynxIt's the source for autoupdate, documentation (I prefer markdown files edited via VSCode). I'm still looking for a best place for my app or eventually I will create a site for it.

@DavidW Just to be clear: I'm not dealing with install time, im dealing with the 'scan extracted mods folder' time. But anyway, I got my answer: follow weidu "with or without setup-". Let's see how it will work. I've summarized everything some time ago at the wiki page but I'm still at the alpha stage. Also, It's the first time when I see [Metadata] as file header. Current'y, it's [Mod] as a leftover from BWS which allows to simply copy <modname>.ini from BWS into the mod and that's it. It doesn't really matter anyway. BTW: I rejected 'metadata.ini' filename proposal because it would be impossible to provide metadata for tp2-only like 'setup-ModA.tp2' mods which are located at the main game directory.

So that was you concern all the time? Don't worry, it's working fine with or without 'setup-' prefix. Both true. My concern is: when Im thinking about "the same as tp2 filename", should I always account "with or without setup-" even for things which aren't weidu and there is no reason for such extra cases? I'm always in favor of more standardization but it won't be a big deal to handle.

BWS will use EET use releases from now.

Weidu treat tp2 basename of setup-mymod and mymod as the same. But my mod installer app is not weidu so when I match mymod + .ini, it doesn't match for setup-mymod tp2 basename. I can add "detect mymod.ini and setup-mymod.ini but it makes the algorithm ineffective because it has to process 2x more detection checks at one step. Next, I would have to preform 2x more detection for mod config files etc. If you expect that it would match, I can make such compromise but I really concern about performance when application is trying to scan 100+ mods.

Hi, @CamDawg @DavidW are you considering "Metadata filename: match tp2 name: MyMod.tp2 => MyMod.ini" in terms of 'weidu' or in terms of OS Filesystem? I wish everyone just abandon this 'setup-' prefix for tp2 so my life would be so easy...

No, it really isn't (Even if you wan't to have separate download statistic for Win, Mac, Linux, you can point to the same mod package). It's a leftover from the times when people were concern about archive sizes and download times. Lucky, the standard IEMod Package format is coming ...

When I'm trying to download attachment from this post: https://www.gibberlings3.net/forums/topic/29951-v31-hilarious-game-breaking-bug-at-the-end-of-bg2/ it show me this: https://prnt.sc/m3nsk3 notice that site says that I'm no longer logged user but when I hit browser "Back" button, I'm logged user.

I don't know which way would be quicker (Do you have a deadline for finishing 'playing with weidu mods'?) but SUBCOMPONENTS-way will open more possibility for the future: - using LABELS for internal mod dependence/internal conflicts right now, you can select ANY single component alone like this and fire installation which will produce error (assuming you are using GUI install tool, doesn't matter which one). Using SUBCOMPONENTS+LABELS with allow you to prevent such situation if you care enough. - i think that you mod needs to limit/change the components according to the previously selected components/combination of the components. It might be difficult to achieve using ini-way.

AFAIK, no. I will probably hide forced components from TreeView since there is no point of selecting them or not.

I leave you with this as an exercise for you

I beat that you are using GoG/Polish "Saga Baldur's Gate" editions which ships with different BGMain.exe size, right? Try to use http://www.shsforums.net/files/file/1086-saga-baldurs-gate-conversion/