Search the Community

What does this tool do? A tool that automatically generates Infinity Engine mod packages when you publish a release. What are Infinity Engine mod packages? They are standardized, universal and cross-platform Infinity Engine Mod Packages .zip package It contains the latest WeiDU executable for Windows and macOS (for Linux is impossible) and .command file for macOS. .iemod package The IEMOD format is intended to be a platform-independent distribution format for modifications for games using the Infinity Engine. The packages are used mainly by mod managers. Among other things, they offer a "double-click at file>extract>install" feature. General info the zip package always contains the latest official WeiDU version from https://github.com/WeiDUorg/weidu/releases, at the time when it has been created because of how WeiDU Auto-Update feature is designed, at this time there is no point to include specific WeiDU version because it will be overwritten anyway during mod installation the version of the package is read directly from the WeiDU tp2 VERSION keyword the package name is taken from mod metadata ini file "Name=" key, excluding non-supported characters for GitHub package files can be combined with the ModRelease tool the tool is server-less micro-service - it will operate as long GitHub Actions will exist in any form Example: ( repository ) How to do the one-time installation inside your mod repository? - by adding to the repository Check repository 'Actions' permissions: go to Settings > Actions and check rights: Download Infinity Auto Packager repository, extract InfinityAutoPackager-master.zip file Copy '.github' folder into you top-level folder of the mod repository Commit and push changes to the remote repository How to use it? Publish release After a few moments, the .iemod and .zip packages will be automatically created and added to the published release. How long it takes depends on how big the mod is. If you have additional questions, feel free to ask

This post is an attempt to have always up to date list of Project Infinity features that can be used by modders. Mod metadata - to display basic mod information and enable other features Global WeiDU Log - additional installation debug info Dynamic Install Order - to ensure that players will always use the correct install order Delta Updates for mods hosted at GitHub - to ensure that players will always use the latest mod version replace ACTION_READLN with SUBCOMPONENT/FORCED_SUBCOMPONENT - to not force players to babysit installation for many hours Globally unique LABEL's - to enable saving mod selections for players UTF8 HANDLE_CHARSETS - to ensure that translated component names can use national letters Infinity Engine Mod Package - to enable extracting and easy importing the mod package Direct downloading mods from the mod manager and skip mod extraction entirely - please make a request here This topic should be updated every time when Project Infinity will receive new features that can be added to the mods. Best way to receive updates is to use "Following" forum feature.

Hi, I've added beta feature to PI: WeiDU-PI-Global.log will record the status of all mod installations that was preformed for particular game folder. So far, those are features: log contains every attempt of mod installation, successful, failed, warring's time and date is recorded exitcode from weidu process is recorded Next additions might be component language, the list of files after the installation etc Example: 2022.07.11-00꞉56꞉28;Started;GlobalAndLocalRulesSub:3000 2022.07.11-00꞉56꞉31;Success;GlobalAndLocalRulesSub:3000;ExitCode:0 2022.07.11-00꞉56꞉31;Started;BG1Aerie:0 2022.07.11-00꞉56꞉31;Failed;BG1Aerie:0;ExitCode:2 It might be useful when someone has been installing/uninstalling mods over and over again. If this is something that you find useful, or if you have an idea what info cold be useful please let me know.

I'm having trouble with my megainstall for non-EE BGT. Level 1 NPC mod won't start and WeiDu displays unknown argument. and XPMOD gives warnings or errors about some files being too small. I'm attaching the list of mods I'm using on project Infinity. Is there any way to rearrange the mods, so I can avoid these errors? gemfreeinstallorder.txt

Let's discuss install order online list which is maintained by the modders or current mod maintainers. There are currently 3 people who are trying to create publicly available optimal install order for many mods: Leonardo Watson - it's only for classic BGT but it can be partially used for BG2EE Roxanne - separate lists for BG1EE, BG2EE, EET, IWD1EE, PSTEE Subtledoctor - combined list for BG1EE, BG2EE, EET, IWD1EE The overall goal of such 'online list' is to be included by any mod manager into some automated install routine, as a default one. The main benefit is that modder/maintainer can include all of his mods and fulfill all needs of his mods like kit/class dependence, NPC cross-mod banters etc. General remarks: due to the dynamic nature, defining install order list by using mod local files would be ineffective for it's goal and a nightmare to manage history of changes is important so we know who change what GitHub is used by similar initiatives, with good results contributing into a GitHub-based solution can be done without storing mods there Goals: main game quests aren't broken NPC mods installed correctly for their cross-banters/interactions Kit mods adding kits before other NPC mods can relay on them Tweaks mods actually works for all previously added mod content UI tweak mods can correctly patch other UI-overwrite mods Non-goals: a perfect install order for unlimited amount of mods Format: the mod ID is tp2 filename without extension and 'setup-' prefix uses designated numbers of the components * (star) means all components of the particular mod, except any explicitly defined component from the same mod ID Example: # WARRING: This list is only an example for ongoing discussion, don't use it to define you install order! # Overwrite DragonspearUI++ * # Main jimfix 0 1 100 stratagems 1000 5900 6000 6010 6030 6040 spell_rev * iwdification * stratagems 1500 1510 wildmage * iwdification 60 hammers * UnofficialItemPack * item_rev * Divine_Remix * song_and_silence * RR 0 1 2 3 4 5 6 7 8 Faiths_and_Powers * TomeAndBlood * A7-GolemConstruction * A7-ChaosSorcerer * might_and_guile * IHateUndead * willowisp * cdtweaks * Divine_Remix 1000 AnimalCompanions * shadowadept * sword_and_fist * refinements * scales_of_balance * stratagems * jimfix 2 3 4 5 400 RR * atweaks * scales_of_balance 180 klatu * jimfix * # it will install remaing 201 202 203 204 205 300 components EEUITweaks * # Portiats ppe * thepicturestandard * Workflow: list is read from top to the bottom modders/maintainers are added to the repository as collaborators modders/maintainers can make changes to the repository modders/maintainers are adding/changing only their own mods minimum amount of collaboration and caution is required Features: easy and straightforward solution for players (read) and mod managers (download and apply) easy way to contribute via web interface: you simply choose file, click edit and that's it it has history of changes, everyone will know who change what placing NPC mods in order to fulfill all cross-mod banters/etc is very easy for certain games like IWD1EE, PSTEE, it will be very small Disadvantages: having to manage separate lists for different games for certain games like BG2EE or EET, it will be still a big one placing UI/Portrait/Sounds mods is not straightforward because there are no 'sections/groups' at such list I've added sections as comments I don't want to assume that such list could be easy maintained by modder/maintainer so I would like to hear from you about: 1. As a modder/maintainer, how do feel about contributing into such list? 2. Which things makes you don't want to contribute to such list? Please share you feedback, I agree that there are many difficult aspect of the install order but "done is better than perfect".

tl;dr: Add "LabelType = GloballyUnique" line into mod metadata file. Then for each mod component add WeiDU LABEL keyword by combining modder prefix or author name, mod display name (read warring!) and the component name. Then never even change it. You will help other modders, people who create so called 'mod compilations' and players who do use mod managers. Introduction: Project Infinity feature status: implemented You might wonder, what is LABEL? Why I should add LABEL's to my mods? LABEL is a better DESIGNATED. It allows assigning a unique textual identifier for a given mod component. And use this identifier to handle internal dependencies between the components of the same mod and external dependencies of the mods from different authors. By using globally unique LABEL's locally, you are saving yourself the trouble of fixing dependences after DESIGNATED changes. By using external mods LABEL's for defining dependencies, you avoid 'locking' DESIGNATED numbers changes of those mods so the author can freely change them when he needs to. Finally, those are extra advantages that mod ecosystem will get when LABEL's will be treated as globally unique instead of being bound to tp2 name: label can help you to properly handle mod component dependencies of the other mods, other modders could use labels from you mods the same way so-called mod compilations will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods installation order guides will not become obsolete after changing DESIGNATED numbers or even donating components to other mods mod conflicts list will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods players can safely keep the list of selected mod components and use it without this kind of nightmare The goal is to create LABEL that is globally unique across ALL existing and future mods. It's easy and straight forward when you keep simple general rule: Modder'sPrefixOrAuthorName-ModDisplayName-ComponentName WARNING: It seems natural to use the so-called tp2 basename as part of the LABEL. Of course, you can do it, but you should be aware that the whole LABEL is locked and remains the same forever even if the component (its code) would be moved to another tp2 file/different mod, no matter if it's your mod or someone else. You should absolutely leave it unchanged. This is a very important distinction that is not obvious at first glance. If a mod MyTweaks.tp2 contains a component with the label 'xx-MyTweaks-RemoveDragons' and later is donated to cdtweaks.tp2 mod/file, the LABEL STAYS THE SAME with modder prefix and tp2 name! How to enable: Step 1: Add the Add "LabelType = GloballyUnique" line into mod metadata file. Step 2: For each component of your mods, create labels according to below requirements and best practices. Label requirements: no spaces no special characters no Unicode characters minimum 4 characters cannot be the digits-only, using digits-only (LABEL '100', '1000' etc) for LABELS in fact removes it's advantages cannot be combination of 'ID:DESIGNATED' as actual LABEL (LABEL 'MyMod:0' etc) cannot be ONLY tp2 basename, the main component of you mod could be easy constructed by adding '-Main' suffix Label best practices: kebab-case, snake_case, PascalCase it's best to start with modder prefix: xx-MyMod-Main from the most significant to the least significant: "xx-MyMod-Portrait-Brath" / xx-MyMod-Portrait-Wallo" instead of "xx-MyMod-Wallo-Portrait" / "xx-MyMod-Brath-Portrait" avoid using the component category in the label name Component category (equivalent to WeiDU GROUP feature) is a virtual concept and depends on individual preferences. After transferring components to a different mod or category, the label will have a mismatched and confusing name so it may mistakenly prompt people to change this part of the LABEL, but it should never be done. Example: BEGIN "MyMod" LABEL "MyMod-Main" Wrong label names: "a" - not enough characters "Spells" - too general name "Main" - too general name, add mod display name "MyMod" when tp2 is MyMod.tp2/Setup-MyMod.tp2, please add '-Main' suffix Proper label names: Labels of the main component of Ascension mod by DavidW: ////////////////////////////////////////////////////////////////////// // Ascension main component: rewritten Chapter 10 // ////////////////////////////////////////////////////////////////////// BEGIN @104001 DESIGNATED 0 GROUP @101000 LABEL Ascension-RewrittenFinalChapterOfToB Labels of the main component of Transitions by Lauriel: //////////////////////////////////////////////////////////////////////////////////// // MAIN COMPONENT FOR ALL GAMES: ALLOW CONTINUED PLAY AFTER DEFEAT OF BOSS ENEMY // // OPEN THE PALACE AND MODIFY DUKE BELT TO ALLOW FOR BG1 CONTINUATION // // OPEN SULDANESSELLAR AND MODIFY QUEEN ESSEMINE TO ALLOW FOR BG2 CONTINUATION // // HANDLES PC'S ROOM IN THE PALACE AND IMOEN'S TRAINING IN MAGIC IN EET // //////////////////////////////////////////////////////////////////////////////////// BEGIN @2 // MOD 0 LABEL "#L-TRANSITIONS-MAIN"

Hi, I'm ready to have discussion about biggest issue when it comes to deal with mod installation without pausing for user input: READLN. I can offer modders existing solution which can overcome such problem and new solution which will fits modders needs. But no matter how good a solution might be, it requires effort over modders side or accepting contributions for their mods (but only once!) Lucky, some modders already declared the will to remove ACTION_READLN like AstroBryGuy for bg1npc (many thanks!). My wish would be that other modders will follow but they must know about the ACTION_READLN issue. Example: Worldmap, currently as TOP1 at SHS downloads, summary of bad READLN things: impossible to present ACTION_READLN choices (input and description) for GUI installation will be paused and wait for manual user input impossible to save such mod configuration so every installation, user need to repeat providing manual input, can't use weidu commandline player choices are also not included inside weidu installation log so debbug information is lost impossible to use weidu LABEL and other functions Example of player complains: "I cannot select Worldmap mod choices and the installation is paused!" What is the problem? The player can't choose those two choices which mod provides. I'm bringing this topic again because after the release of my install tool, you can be pretty sure that complaints like this will occur. And when they do: Q1. What's modder answer regarding feedback, to the the one who send such complains? Q2. What should be MY answer if any player will come to me and report such complaints as a BUG of the install tool? How to solve above problems? There are 3 solutions currently available. Please keep in mind that none of the proposed solution are "BWS-Exclusive" etc: 1. Instead of using READLN, use SUBCOMPONENT or FORCED_SUBCOMPONENT functionality in WeiDU This is the best solution for such problem but it doesn't cover every cases. It require rewrite mod component logic. 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. 2. READLN sometimes is used to read for eg: "Familiar Name" so SUBCOMPONENT can't be used For such cases, using config-default.ini + config.ini approach should solve the problem. Good adoption of Solution 2 can provide both ways of providing value: from user input or from actual configuration made by player itself. You can even display additional info during console installation: "The config.ini file not detected, read config-default.ini to change default configuration" - player will be aware how to use ini files even if he won't use any install tool at all. Any more thoughts? Selected Modders who have used ACTION_READLN: @Tash @wisp @Pecca @argent77 @jastey @berelinde @Ulb @LavaDelVortel Any chance to remove READLN from you mods, using proposed solutions? @wisp, can you mark READLN as "DEPRECATED" and display warring?

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?

I've finally take some time to talk about this topic. When I take look at the amount of the BWS 'custom extraction rules' and 'custom code' which was written only because modder made simple packaging mistake and then went MIA, i decided that there won't be any kind of 'extraction' feature for PI unless there will be a well-defined standard for all IE mods. Having a well-defined, universal and cross-platform Infinity Engine Mod Package and the cross-platform tool for creation of such package would be wonderful. Definitely there are advantages for players and for mod managers. This general idea was originally posted by wisp at PPG boards. Key points: - the era of caring about package size on disk or download times are long gone - there is no point for offering two separate zip packages for macOS and Linux if the only differences are weidu and few OS-specific tools resulting ~1MB of file difference - macOS/Linux users offter are asked to download weidu, extract it, copy & rename and set executable bit. Example: http://www.shsforums.net/files/file/949-atweaks-platform-independent/ - just look at the 'Installation instructions' - it's horrible idea to require preforming all of those actions by macOS/Linux users. Those things must go away, thus the simple requirements for new package: it needs to have everything which is needed for mod installation. Advantages: standardization, no more rar, tar etc, all community created tools can support it without worrying about edge-cases players will no longer need to install 3-rd party tools in order to extract mod, mod manager will do it such mod packages can be double-clicked inside OS and associated program will be open and offer extraction (and possible installation) it will allow to introduce 'infinity mod package protocol link' similar like Steam steam:// or Nexus Mod Manager nmm:// protocol links The Infinity Engine Mod Package:// protocol link: Those are special links on the web page, they look like this: steam://run:<AppId> - if the user click at this link, his local Steam application will be executed and the game will launch or the user will be asked if the game should be downloaded. nmm://ModID - if the user click at this link, his local NMM application will be executed and the mod will be automatically downloaded and added to mod list. If you never have used them, please try via Steam or NMM/Vortex - it is a pleasure to see how everything works with one click. I want this to happen. So Infinity Engine Mod Package:// protocol could be defined like this: iemod://github.com/Gibberlings3/Tweaks-Anthology player click at such link associated application will open mod will be downloaded and extracted (no overwrite) additional option would be to offer installation after extraction but i'm not sure about this and how it will play Support for such 'protocol' can't be established if there is no package definition because associated app must know ahead what's at the other side. If someone will point to the non-standard package either download/extraction will fail or extraction into game directory won't be correct so the installation cannot be started properly. 1. File format: ZIP Quoting wisp: I agree that zip is very good choice, every OS has build-in support for it. 2. File extension: .iemod - Infinity Engine Mod Package Different extension allows for custom file association for double-click action and extra actions for eg: Right-Click Menu: Install to> Game Folder. Besides, it's not only zip file, it's a zip contains IE mod with specific content/rules. Zipping mod files won't prevent package mistakes, modders need to use special mod packager utility. The .iemod file extension is not the good choice, it's "Infinity Engine Mod Package", not "Infinity Engine Mod" source file. So how about .iemp as file extension? If the 4-letter extension looks odd, how about .iep (but it's already used by other programs) or .iex (no application use such extension) ? 3. Filename: Simple format: ModName-version.iemp, nothing fancy about it, mod name can be taken from metadata Name. Question: should spaces be allowed? Filename doesn't mater at all under the condition that it doesn't contains forbidden special characters/folders: Absolute minimum set of forbidden special characters: < > : " / \ | ? * '\0' (NUL) Absolute minimum of forbidden special filenames: CLOCK$, CONIN$, CONOUT$, CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 cross-platform package simply cannot contain such special characters and cannot use such special filenames because those are reserved. 4. The content of the package: Across all those years, people put crazy things inside their mod packages: executable's inside zip, double compressed files like zip inside rar, override & backup folders, Windows 'thumbs.db' cache files and macOS '.DS_Store' folders etc. So let's exclude some files and folders: $RECYCLE.BIN/ __macosx backup/ temp/ tmp/ .* !/.gitattributes !/.gitconfig !/.github !/.gitignore *.bak *.bat *.iemod *.lnk *.rar *.tar* *.tmp *.zip Thumbs.db all of those files/folders can be easy excluded at the creation time and should not be part of the final package. 5. WeiDU executable: I would much prefer a solution where modder explicitly defines the weidu version which he used in order to create and install the mod. But until we get to this point, there is a simple solution: - weidu windows: .exe - weidu macOS: no extension - weidu Linux: .bin (please don't tell me that 'Linux don't have executable file extension', it doesn't matter) this way modder can include all necessary files in order for mod to be installed. I will post universal '.command' file later. 6. Mod structure: We need to eliminate possibility of double and tipple extra top-level directories, for mods: player should be able to extract such package into game directory and everything should work correctly. The way how to do it is to check the level of the tp2/tp3 mod definition file and fail if it's more that one-level. 7. Tools: I've created packaging utility which is very similar to 'G3 ModPackage' tool but it's cross-platform and can produce .iemod packages and optionally pure .zip files, it's using ModID-version.iemod filename schema. It doesn't have validation yet but it's easy to implement. I will post it latter when I will do final touch. That's all for now, please share you feedback.

Hi, let me start from make clear statement that NOTHING IS REQUIRED. Did I say that nothing is required? Yes, that's true, nothing is required. You don't have to do anything. My proposition/design also aims for be "less selfish as possible" aka "don't require anything and if, require minimal amount". I hope that's clear now. The main idea behind this is to give back the control of mod metadata in the hands of modders. Which person know the current and most up to date mod name, description or the working link to the place where players could receive support? That's right, the modder itself or current maintainer. The first idea was to have a website where modders could provide mod metadata. Creation of such website is very simple and can be done in one day. But then there is a problem when some other people will provide 'malformed' info about other people mods. Trolling is an art. It's impossible to counter without some sophistic login/verification method. And ofc "yet another website" will be instantly boycotted, even if it would be offer a Genie in a bottle. So without website, similar to "mod configuration file", a mod could provide few important metadata like: full name of the mod itself, without version number general mod description improved alternative for README keyword - you can also put direct links to online readme's link to mod dedicated forum or forum thread link to mod persona homepage if exist direct download link to the latest version of the mod This is my take on this matter: 0. File encoding: It can be ANSI if it won't contain Unicode strings. UTF8 (no BOM), if you want to use local language characters. 1. File format of such file must be 'industry standard', one for all mods. And please forget about xml I can't write a custom parser for each mod only because it's author like to put spaces before and after '=' character. Or use TAB to separate key and values. Or include weidu commands which only WeiDU can parse with it's GLR parser. It would be too much work. So let's choose one, modern 'industry standard' file format. My vote goes for INI as a first choice. 2. File extension of 'mod metadata file': Almost irrelevant, follow the file format definition associated extension. Those files shouldn't be modified by players anyway. 3. Filename of such 'mod metadata file'. There is one, very simple solution: <modTp2name>.ini. This is what is currently implemented. - it doesn't require file header / ini sections added [Mod] require [Metadata] section header to avoid false detection - it prevents people from making multiple, outdated version of this file 4. File content: nothing is required, you can even put one, single line Key=value pair with only mod full name. The INI will have preference over data from tp2. INI: # Never copy this from other mod, always use https://github.com/ALIENQuake/ProjectInfinity/wiki/Adding-metadata-for-mod # Filename must be the same as tp2 basename, placed at the same folder where # .tp2 file is located, use "UTF8 without BOM" encoding, everything is optional # ini section header is required to avoid false detection [Metadata] # Full name of the mod, without the version number, without the list of supported games Name = Mod Example - Optional Features # Author name or nick, don't use an email address Author = AL|EN # Short description of the mod, main goals, features etc Description = This mod is a guide on how to use optional 'Project Infinity' features. # Web address of mod readme file (filename is case-sensitive!) You can link to txt, md, html, pdf etc. Readme = https://example.com/ModName-Readme.html, https://example.com/ModName-Readme-%LANGUAGE%.html # Web address of mod dedicated forum or forum thread Forum = https://www.example.com/forums/categories/forum thread # Web address of mod personal Homepage, no need to duplicate with a mod dedicated forum # Homepage = https://www.example.com # if you use Github.com, simply use https://github.com/AccountOrOrgName/RepositoryName # read more about Delta Updates https://github.com/ALIENQuake/ProjectInfinity/wiki/Delta-Updates-for-mods-hosted-at-Github Download = https://github.com/AccountOrOrgName/ModExample-OptionalFeatures Remarks: If there will be a demand, PI could use JSON with comments file or JSON5/HJSON, it has very strict rules, only for modders who wan't to benefit from the advantages of the JSON file format itself. Order of the preference: JSON > JSON5/HJSON > INI . It means that if you provide only INI, everything works. Later, if someone wan't to switch to more advanced metadata format, mod metadata will be read from them. I think that INI would be enough but I don't want to limit modders. 5. Visual representation: - mod metadata will be displayed inside "Mod info textbox" - in addition, mod name will be displayed at treeview/mod list - mod download link would be used to download new mod version (if it is supported) If you have suggestions or questions, feel free to ask.

Introduction: Mod conflicts are an important part of the modding ecosystem. The idea of achieving as much compatibility as possible is still valid and should be a top priority. But even in a perfect world, where all mods are technically compatible with each other there is still room for two mods that change certain aspects of the game differently. I like to think about 'mod conflict' not as 'mods which break installed together' but rather as 'alternative variants of the same game content' since it's more about providing an alternative idea to certain game aspects. My idea aims to inform players about those 'alternative variants' before installation is even begin to avoid confusion and endless questions 'Does mod X is compatible with mod Y and Z ???' Background: I want to exclude a situation when the technical or conceptual incompatibilities are caused or can be solved by the different install order of mods. If two mods can be installed without problems but the outcome of the NPC dialogue makes no sense because Mod A was installed after Mod B then it's install order requirement, not a 'mod conflict'. There are two types of conflicts: internal conflicts between components of a single mod (outside of the SUBCOMPONENT's) Example: components which have 'mod X:2000 can't be installed if you installed mod x:1000 external conflicts between multiple mods from various authors Example: Argent77's "Disable Enhanced Edition NPCs" can't be used together with Pecca's "EE content tweaks". Players have to choose one of them. So for this discussion, the 'conflict' will represent only the external conflicts between different mods, particularly those cases: a) technical and conceptual incompatibility: the mods not only represent a completely different take on certain aspects of the game but they also can't be installed together at all Example: UI overwrite mods LeUI:0:The main UI overhaul LeUI-BG1EE:0:The main UI overhaul LeUI-SoD:0:The main UI overhaul b) conceptual incompatibility: when one mod lowers the Kaigan dexterity to 19, the other one increases it to 22 While it's possible to install both of those mods, the desired outcome is not achieved for one of the mods. c) outcome incompatibility: you can install both mods without a problem, there are no technical incompatibilities between them. Yet installing them together will give you undesired results. Example: EET_Tweaks: Changing XP for Killing Creatures vs Tweaks Anthology: Changing XP for Killing Creatures EET_Tweaks achieve the goal by modifying experience points required for each level Tweaks Anthology achieve the goal by modifying every creature file and lower its experience Points installing both mods together will cause undesired results Note about the difference between major incompatibilities and minor problems: There is no doubt that some conflicts are major should not be disabled/ignored while other conflicts are just warring which introduce minor annoyances at worst. But when it comes to deciding which one is 'important', it always with the players to decide. So my proposition for this is: allow players to ignore all conflicts, regardless of their status at the same time, inform modder (via log file) that certain conflicts were ignored This is not set in stone, I'm open to discussion regarding this matter. The Idea: Example case 1: CDTweaks - "Change Experience Points Cap" vs EET_Tweaks - "Change Experience Points Cap" cdtweaks:2090:Remove Experience Cap cdtweaks:2091:Level 20 Experience Points Cap cdtweaks:2092:Level 30 Experience Points Cap EET_Tweaks:2002:Disabled EET_Tweaks:2001:8,000,000 EET_Tweaks:2000:2,950,000 Example case 2: LeUI vs LeUI-BG1EE vs LeUI-SoD Example case 3: Oversight - "Lanthorn Lenses" vs "Restored Rhynn Lanthorn lens quest" All those mod components are doing the same thing. From the player perspective, the ideal solution would be that the installation of more than one of those components would be blocked. So how various mods from different authors could set external conflicts? The idea is to define the so-called "Conflict Scope" for each of the mods: - mod manager will offer a pre-defined and documented list of conflict scopes with the description about which game content/mechanic/etc it covers: Case 1: ExperiencePoints\CAP - for mod components which change experience points cap Case 2: UI - for mod components which overwrite the whole game UI Case 3: Quest\LanthornLenses - for mod components covering Lanthorn Lenses quest - each of the mod will add those 'scopes' into mod metadata ini file by using specific data format: Case 1: Conflict = ExperiencePoints\CAP Case 2: Conflict = UI Case 3: Conflict = Quest\LanthornLenses - if the setting conflicts globally via ini will not be sufficient, it will be possible to setup the same 'scopes' directly inside components using WeiDU "METADATA" keyword format: Case 1: BEGIN "Remove Experience Cap" METADATA "Conflict = ExperiencePoints\CAP" . . . Case 2: BEGIN "The main UI overhaul" METADATA "Conflict = UI" . . . Case 3: BEGIN @4 DESIGNATED 10 SUBCOMPONENT @1 METADATA "Conflict = Quest\LanthornLenses" // Restored Rhynn Lanthorn lens quest - classic version . . . - when two or more mods touches the same 'scope', the mod manager will detect this as 'conflict' and allow the player to choose Visual representation: - players will have to decide and select only one component or ignore conflict - the installation will be possible until all conflicts for all scopes will be solved or ignored - scopes can be very limited in terms of which things they cover: NPC\Jaheira\Portrait - for mod components which change Jaheira portrait ExperiencePoints\KILLINGCREATURES - for mod components which change experience points for killing creatures ExperiencePoints\REQUIREMENTS - for mod components which change experience points requirements ExperiencePoints\PICKINGLOCKS - for mod components which change experience points for picking locks ExperiencePoints\DISARMINGTRAPS - for mod components which change experience points for disarming traps ExperiencePoints\LEARNINGSPELLS - for mod components which change experience points for learning spels ExperiencePoints\COMPLETINGQUESTS - for mod components which change experience points for completing quests - scopes can also be defined for all other game aspects: NPC\..., Stores, SPELS, ROMANCES, RACES, RacialStats, CLASSES (for eg: assignment of HLA skills ), MULTICLASS, DUALCLASS, HLA (modify certain HLA's skills) FAMILIARS, FATESPIRIT, UI , QUESTS, SpellProgression, WeaponStyleSpecialization, HitDice, WeaponProficiency, WEAPONRESTRICTIONS, APR, THAC0, SavingThrows, SavePenalties, WatchersKeep, STRONGHOLDS, ROMANCES, PLANARSPHERE, PortraitIcons, CONTAINERS, NonJoinableNPCs etc - the statistical data of which part of the game is very likely to be covered by two or more mods come from BWS 800+ lines of conflicts which represent over 8 years of how mods interacted with each other. This is a very valid source of 'scopes' which covers almost every aspect of the game where there was some sort of clash between various mods. - It also covers future released mods: modders no longer need to care about all possible future mods which will modify the same things. If a new modder wants to create yet another XP mod, he will just set conflict scope instead of searching for all possible mods which cover the same topic 5 years before. - lastly, the solution doesn't relay on mods tp2 names, DESIGNATED numbers, or even LABEL's Technical details: - everything is evaluated before installation even starts so the player won't ever face 'Mod X can't be installed while Mod Y is present' after hours-long installation - works globally, it will check mods already installed, currently being installed and it also 'will be fired' when someone will install mods later - all conflicts are loaded and evaluated dynamically, according to whenever the mods with conflicts are selected or not Edge cases: One is when there might be three mods that cover the same NPC romance. Mod A is compatible with Mod B and vice-versa. But Mod C is not compatible with either of them. If Mod A,B and C have set 'Conflict=NPC\Garrick\Romance' they appear as conflicted. But Mod A and Mod B appear conflicted also to each other which is not true. The easiest solution would be to inform players that they can ignore the conflict for Mod A and Mod B. Much more complex alternative would be some kind of exclusions. That's the idea, please share thoughts and feedback.

Let's try an alternative look at how modders/maintainers can take care of the install order: Dynamic Install Order It's a rule-based order of the mods which use BEFORE/AFTER 'rules' in order to determine the relationship between source mod and destination mods. Generally, it is a recreation of the install order recommendations from mods 'ReadMe' files, but in 'machine-readable' format, which mod manager can use, apply and react when rules are not fulfilled. Goals: you care only about install order/dependencies of you own mods or mods which you maintain sufficient for low to medium installation, for huge mega-installation of 100+ mods, a big install order list will be better choice Non-goals: to handle every possible type of future mods a perfect install order for unlimited amount of mods replacement for using install order list for huge amount of mods Features: rules cannot be disabled by players, you can be sure that you mods will be installed using provided install order using mod ID as tp2 filename without extension and 'setup-' prefix everything is evaluated before installation even starts so the player won't ever face 'you must install x before y' after hours-long installation allows only to set rules for your own mods relating to other mods, it doesn't allow to alter install order rules of other mods all rules are loaded dynamically, according to whenever the mod is selected for installation and the mod to which the rule applies is also selected all rules are evaluated dynamically, according to whenever the mod is selected for installation and the mod to which the rule applies is also selected the installation will be possible only when all rules for all mods will be fulfilled works globally, mean it will check mods already installed, currently being installed and it also 'will be fired' when someone will install mods later Covered use cases: The idea for this topic is regarding install order/installation dependencies only, not mod conflicts. So in order to clarify scope of this discussion let's limit it only to this cases: Assuming 'ModA' is the source of the rules aka 'if I'm editing metadata of ModA.ini, the rules are for other mods related to it' : Implemented: BEFORE = ModB Mod A should be installed before Mod B, this is only single 'rule/requirement', it doesn't mean that ModA require ModB to be installed. AFTER = ModC Project Infinity feature status: Implemented Mod A should be installed after ModC, this is only single 'rule/requirement', it doesn't mean that ModA require ModC to be installed. Example: AFTER = BobShop, Caravan, TeamBG-Armors The mod will add new items into the every game shop regardless whenever BobShop, Caravan, TeamBG-Armors mods are installed or not. Not yet implemented: please don't use those until there will be working implementation as things might be changed Example of rules definition for Deities Of Faerun mod: Project Infinity feature status: Implemented mod ID as tp2 filename without extension and 'setup-' prefix ID's are separated by commas DeitiesOfFaerun.ini [Metadata] Name = Deities Of Faerun BEFORE = IHateUndead, MyMod AFTER = AllThingsMazzy, OtherMod Example of defining install order rules directly inside mod components by using WeiDU 'METADATA' keyword in order to provide data for PI's Dynamic Install Order feature: Project Infinity feature status: Implemented mod ID as tp2 filename without extension and 'setup-' prefix ID's are separated by comas the format stays the same as for global rules with the addition of usual WeiDU keyword syntax you can't put BEFORE/AFTER into single METADATA occurrence you can have multiple METADATA keyword statement you can put global rules inside ini and a different ones directly inside components - local rules will override (instead of combining) global rules from global ini LocalRules.tp2 BEGIN "Local Rules Main" LABEL "LocalRules-Main" METADATA "AFTER = Ascension, DSotSC" METADATA "BEFORE = X, Y" BEGIN "Local Rules Extra" LABEL "LocalRules-Extra" METADATA "AFTER = C, D" METADATA "BEFORE = FaithsAndPowers, TomeAndBlood" Visual representation: Record_2020_03_04_21_38_32_448.mp4 If you have any questions, or feedback regarding details of the above system, feel free to ask.

Hi all, I've been a lurker here for some time, and played a fair bit of BG2 since release, with a smattering of IWD and BG1. Today I finally have something to contribute. In working toward some multi-mod installs, and perhaps eventually an EET run, I started a list of mods with some info to help me work through compatibility issues. I shared this elsewhere, and @Cahir has been good enough to contribute, bringing it to a state where I suspect it may have some value to others. The goal is to create a compatibility guide and "cheat sheet" for multi-mod installs. The focus is on EE games as I mostly care about BG2EE & Cahir EET. Link: https://drive.google.com/open?id=1vislrHkbvsqlN0m5jtDxDcSzlnA5D6ABSZy5TG1O8FQ Please comment in any additional info or suggested changes, this will only improve with collaborative effort. Any and all feedback appreciated. 4udr4n

Okay, so I'm going to do a new install and I'll try to do an install order list. If possible I'd like to get some feed back before I start the installation (if anybody is able to spot glaring mistakes). Note please: I haven't figured yet out how to export an install order list properly, other than copy&pasting it. (If AL|EN doesn't want this kind of discussion in this thread, please jsut remove it or move it somewhere else) My current WIP list:

Hi, First, I would like to say that it is not a discussion about defining correct install order for mods, it's for creating a system which can define such install order and be applied to already selected mod list. Recently, I'm dealing with Install Order/Install Sorting for my tool and notice few things: Naturally, the first source of the install order is Weidu.log. But it never worked, it must be a reason why nobody created a nice community 'install order' list which use weidu.log data. I think that is very ineffective when it comes to Install Order/Install Sorting because it contains exact numbers of the components - any mod change/update will make such list obsolete. Also for the case when mod will have completely new components, old weidu.log won't have it. The second source is the BWS installorder.ini file. It is also not a good source because this file is not only the install order. At the same time is also a 'list of mods which user can install'. Players cannot simply change it because any 'online update' made by BWS maintainers will overwrite player changes. If he won't update, he will miss new mods//changed components. Such design works only if you have 24/7 maintainer of the mods/components and the exact order which they are installed. The more I think about how many things are affected by the fact that mod components are actual 'mods which can change the ID several times a day' the more dealing with it becomes scary. So I was thinking how to make something which will be effective, easy to use and will avoid unnecessary edits. This is an idea which I want to discuss with you: 1. Part of BWS installorder.ini file, definitely outdated, posted as example: https://pastebin.com/PkjTkyxB - you can see how big such list can be when you need to deal with exact component numbers. 2. Definition of the custom file format: - you can use spaces or commas to separate components, doesn't matter - mod example: ModA components numbers are 1, 2, 100 and 200 (just an example, they can be any amount of numbers) 3. Definitions: - ModB, component 1 and 2 and 100 and 200 will be placed before ModB component 11, 22 and 33 ModA 1 2 100 200 ModB 11 22 33 - all components of ModA will be placed before all components of ModB. Mod updates, changes to index/designated or even adding new components won't break sorting. ModA * ModB * ModB, component 1 will be placed before all components from ModC, ModB component 2 will be placed after all components from ModC. Mod updates will affect such entry but not every time, updates/changes to the components of ModC won't break sorting. ModB 1 ModC * ModB 2 - ModA, components 1 and 2 will be sorted. Even if the definition has '*', there are explicitly defined component at the end of the list, so those will be not sorted now - ModB, component 1 will be sorted - ModC, all mod components will be sorted - ModB, component 2 will be sorted - ModA, components 100 and 200 will be sorted because those are explicitly defined ModA * ModB 1 ModC * ModB 2 ModA 100, 200 3.Examples Example 1: the same BWS Install Order/Install Sorting List as posted above, defined using custom format: jimfix 0, 1, 100 # component 0, 1, 100 will be placed into install order list because those are explicitly defined npc_tweak * # all components will be placed into install order list because there isn't any explicitly defined component stratagems 1000 5900 6000 6010 6020 6021 6022 6023 6024 6030 6031 6032 6033 6034 6040 6041 6042 6043 6044 celestials * spell_rev * Faiths_and_Powers * TomeAndBlood * iwdification * wildmage * iwdification 60 # component 60 will be placed into install order list because it's explicitly defined hammers * UnofficialItemPack item_rev * Divine_Remix * # components 10,11,100,103,106,107,109,112,115,118,121,124,127,130,200,203,403,406,409,412,415 will be placed into install order list DR8_hotfix * song_and_silence * RR 0, 1, 2, 3, 4 ,5 ,6 ,7, 8 # components 0,1,2,3,4,5,6,7,8 will be placed into install order list because those are explicitly defined A7-GolemConstruction * A7-ChaosSorcerer * might_and_guile * IHateUndead * willowisp * cdtweaks * # all cdtweaks components will be placed into install order list because there isn't any explicitly defined component Divine_Remix 1000 # component 1000 will be placed into install order list because those are explicitly defined AnimalCompanions * shadowadept * sword_and_fist * refinements * scales_of_balance * stratagems * # all remaining SCS components will be placed into install order list jimfix 2,3,4,5, 400 RR 9, 10, 11, 12, 999 atweaks * scales_of_balance 180 # SoB 180 after SCS and aTweaks PnP fiends klatu * jimfix 201,202,203, 204, 205, 300 Notice that for eg: Divine_Remix has component 1000 nicely defined as explicit while all other components aren't defined by exact number. In case of adding new kits, such install order definitions will be unaffected and it won't require 24/7 maintainer. Example 2: more general install order for EET: [Language] bg2eetrans * bg2eePL * [Fixes] BWFixpack * [Enhanced Edition Trilogy] EET * [Quests] bgqe * [NPC] Sirene * [NPC-Related] BG1NPC * [Items] item_rev * [Spells] spell_rev * [Kits] Divine_Remix * Faiths_and_Powers * TomeAndBlood * might_and_guile * [Tweaks] cdTweaks * scales_of_balance * Refinements * [AI] stratagems * [aTweaks] aTweaks * [Worldmap] Worldmap * [Enhanced Edition Trilogy End] EET_End * [Sounds] HQ_SoundClips_BG2EE * [Portrait] PPE * thepicturestandard * [UI] recoloredbuttons * LeUI * EEUITweaks * Using such general install order as a base/foundation, player or modder can easy discover proper(but not ideal) install order for new mods. So install order list can be compressed from over 700 lines to 36 and it for most cases, it's unaffected by changes to component numbers/designated so it won't require 24/7 maintainer. Such definitions also fits very well for online Excel or Google Docs where you can put comments at the specific lines. Converting weidu.log, BWS install order or even BWP PDF to such list is very easy and offers much less work for updating it. Install Order/Install Sorting lists for smaller amount of mods can use '*' for all mods and be pretty much unaffected all the time. Player would simply choose their mods/mod components, add them to the 'mod installation list' and then load from file and apply 'install order' which will sort know mods. The mods which wasn't included inside install order list would simply be mover at the end, for review. 4. Possible improvements: ability to define component ranges: [0..100] = components from 0 to 100 will be placed into install order list, the [x..y] construct is the same as for defining array ranges ability to define component ranges with only starting point: instead of explicit component number (DESIGNATED), such list can support using LABELS (but modders are allowed to change those without complainants from others) or GUIDS (not implemented yet) and be even more protected from mod changes, but only if there is one explicitly added for sorting order, example: the AI components of SCS (5900,6000,6010,6020,6021,6022,6023,6024,6030,6031,6032,6033,6034,6040,6041,6042,6043,6044) could have additional "InstallOrder-AI" LABEL/GUID so it could be used for sorting order. But not without cooperation from the mod author itself. 5. Weak points: it's still based on DESIGNATED numbers for important parts (SoB 180 after SCS and aTweaks PnP fiends) the '*' definition covers all future new mod components which could require different install order Any feedback is welcomed.