AL|EN

@lynx My main idea is to use git deltas. After some experimentation, unfortunately it's impossible (or rather only possible if I force update to overwrite altered local mod files which is dangerous operation) for now to support "Delta-Updates" when multiple mods were extracted into the same top-level directory. So while all mods can be scanned and installed regardless of having extra top-level directories, they cannot receive delta-updates unless they have extra top-level directory.

@jasteyYou can remove "setup-" without worrying about any kind of problems, weidu code was updated to handle this properly. I don't know, maybe other modder feedback regarding this would change you mind? But you can also skip 'setup-' for ini file and it will work. For such minor thing a compromise between "weidu way" and "PI way" is desirable.

EDIT: What just happen with the post which I've quoted? EDIT2: Right, I removed quote.

Are we? Last time I've check you were fully aware about limitations of the marker files: "The downside to marker files - and, I think, what we are considering here - is that I don't think a GUI Weidu app could read marker file dependencies and forbiddances and translate them into visual conflicts in the GUI." so what's changed since then? I do but let me first show you that it's in you hands: you are creating locally defined qdtnb_metamagic.qd marker file (DavidW will probably also take you marker files into consideration) then, you are allowing to use such file by any mod as a source for global conflict for other mods (SCS) lastly, you are you commit to add a similar check to TnB with SCS file markers, after SCS 32 release It's very good example of how establish a cooperation in regards to global mod conflicts. And it's yet another case when you could apply GUID feature. You just have to request GUID keyword to be implemented (it's almost copy paste LABEL code for GUID keyword) and: instead of marker files, define two GUID's: SPELLSYSTEM:SPELLS:SEQUENCER and SPELLSYSTEM:SPELLS:CONTINGENCY for each (future) component by definition, GUID's are allow to be used by any mod as a source for global conflict for other mods, just like marker files ask DavidW to use the same GUID for SCS related components, so you can forbid GUID before SCS release 3rd-party tools/Weidu GUI app will interpret this as "allow only one component with the same GUID's" There, a way to exclude overlapping components by two or more mods. It's the same story with YARS, proficiency system changes and XP changes. We are talking about current weidu features so what conflict are you talking about in terms of my app?

You would be surprised how strong old habits are I wonder if there is a way to support single and multiple files at the same time. Let me think about it.

FWIW: using SUBCOMPONENTS is always the best and preferred way to handle removal of ACTION_READLN because unlike to INI file with settings, it can interact with other mods/components and be a foundation for internal/external dependence and conflicts. The ini won't but it is still way, way better that ACTION_READLN. I have to agree with CamDawg here: too many options can be overwhelming.

@Luke You should start with a list of the content type of you mod: Only weidu code? Only art like graphic, sounds, item descriptions, NPC dialogues? Mixed everything? then, you should tell what is you purpose to include license, basically what you are want to allow: use the source code from you mod by other modders? include the data from you mod inside other people mods? then somebody could share recommendations. But it's really legal hell.

Understood. At the same time, I really want to have a design which require only one thing to do in order to include translated mod metadata: extraction to the mod folder and that's it. I also need to cover tp2-only mods. There is no reason to define language names: for full language name, ISO names should be used like English instead of American and Spanish instead of Castelano. Beamdog use "ISO Language Code Table" and POSIX definition so we should follow it. There is no need to define the custom name for mod metadata because it's unnecessary work for modder/maintainer/translator and it can be avoided by defining it by specification.So ifthere is not reason to define custom language names and folder for metadata, how about something like this: <tp2name-ISOLanguageName>.ini/JSONC/HJSON/JSON5/JSON <tp2name-English>.ini/JSONC/HJSON/JSON5/JSON <tp2name-French>.ini/JSONC/HJSON/JSON5/JSON And as alternative for mods with mod data folder: %MOD_FOLDER%\Metadata\<tp2name-ISOLanguageName>.ini/JSONC/HJSON/JSON5/JSON %MOD_FOLDER%\Metadata\<tp2name-German>.ini/JSONC/HJSON/JSON5/JSON %MOD_FOLDER%\Metadata\<tp2name-French>.ini/JSONC/HJSON/JSON5/JSON Also, I can add requirements of specific file header: [Metadata:French] Name = Mod French Name Description = Mod French Description if it's gona be protected from false-positive detection. Will this be ok for you? BTW: You keep using [Metadata] inside you posts so I must really be a name which hooked you up. I come to conclusion that the topic title has 'metadata', the purpose of the file is to provide metadata for mod so I'm replacing [Mod] with [Metadata] for mod metadata file specification. If the design dictates that 6 different people with different OS, encoding and codepages will maintain one file, then it's asking for trouble when you actually have to maintain it/merge data etc. Except extraction into mod folder, nothing else should be required in order to add translated metadata for any language without possibility to affect other translations.

Then please use standard weidu methods for defining such conflicts like FORBID_COMPONENT, not "file detected" things which cannot be read and interpret via 3rd party tools.

I can add support for translated metadata files. But what would be the best way (for modders and translators) to store translated metadata? 1. Via another ini sections: [Mod-French] Description = <translated> single file but not very nice way to update it by various translators 2. Via separate metadata file cdtweaks-French.ini and put there only 'Description = <translated>' keyword Using separate files will be easier to maintain/update for translators, that one big file which modder would have to merge manually.

Beware that those .exe which Bartimaeus mention are normal zip/rar/7zip archves combined with executable header in order to create self-extracting archive. Only those can be extracted by 7zip, all other windows exe are normal executable binary data which can't be accessed.

Does creating files inside mod folder is also consider as 'change' in this context? If yes, does user-generated configs should also be outside of the mod folder, in order to achieve 100% mod immutability? Not that it is any kind of the problem with them left inside mod folder, just wanted to clarify the subject.

@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. It is impossible to download mod with malformed files, you either download it correctly or don't download it all (git feature). 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 Features: easy to integrate simple and understandable rules for modders about when mod will be updated and how the update process don't touch mods inside game directory, only the mods from the directory where user has placed all mods Requirements: Mod use GitHub hosting (or the site which provide API) Mod has metadata file and filled 'Download=' keyword General Flow: Phase 1: Read Mod Metadata "Download" keyword > Check if update exist > Present 'Update Available' for specific mod > do nothing 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 and 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). If such problem occur, any kind of solution for is doable at this stage. No worries, files non-present inside new mod version are removed. 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.