AL|EN

From my own findings, I would say 1/10. Those who have translated readme, it's almost always not for latest version.

Let me offer third possibility: - Modder can add the opposite install order rule and instruct players that the 'old mod x' is outdated and they should remove 'my mod' from the BEFORE keyword' This is edge case which can be mitigated locally.

@qwerty1234567 aka Magus The emergency central override list is good idea and it might work when it would be needed. Like when one mod need to have updated install order but the author is MIA. But much more strain-forward solution would be to simply edit local mod ini file. I've consider yaml/json but later find out that PowerShell has only JSON support build-in. Nerveless, it's not implemented. I need to handle some other things before I could get back to this.

Thrust me, I'm a fan of modern file format. I've consider using JSON/yaml, even offered support for it for metadata. There was no single question regarding those. This is reality which I have to accept. Scopes could be defined in two ways: global via mod's .ini local via mod METADATA Using centralized list you can use global in the same way as if it would be putted inside mod's ini. But for local ones, you need to combine exact component with exact conflict scope for eg: ID:Designated:ConflictScope EET_Tweaks:2002:ExperiencePoints\CAP Now, everything breaks when the mod will change it's DESIGNATED and we are back to the BWS nightmare.

@qwerty1234567 aka Magus When you put it that way, I agree about weak points. The lack of updates being the most serious one. While it is possible to create Conflict definition with applied logical dependency to cover edge cases, the names of the mods for 'excludes' and 'includes' cannot be know in advance. Regarding 'online list for collaboration', I'm sure that you understand why the last thing that I think of. There was attempt to do it for install order and it didn't fly. There were valid arguments why modders won't participate in such collaboration so I would not hope for change regarding 'conflicts'. Plus, the conflict definitions would have to be done via old, flawed BWS-DESIGNATED-way where one mod update would cause domino of errors and incorrect conflicts. I don't want to repeat this.

Revisiting this, one thing which comes to my mind are two additional keywords: Contributor - a list of people who contributed content for the mod like banters, new components etc Maintainer - a person who did only technical updates, fixes without adding or altering content If somebody thinks that his mod needs such a level of detailed information, feel free to request it.

@DavidW Sorry for the late reply, end-of-the-year stuff. Ofc I was thinking about your 'restored Lanthorn' micro-mod and it was immediately corrected. The system which I proposed is not based on files at all. It doesn't matter how many files are modified by component, what matters is the logical interpretation of those changes. So the mods aren't flagged as 'conflicted' if they touch the same files, only when they fail into those three categories. The examples of 'conflict scopes' are representing 8 years real-life data of the 'places' where mods clashing with each other. None of them are about 'mod A modify file-x'. As for the syntax, from what other modders mention, there needs to be a way to exclude certain mods. This would be the next item on the plate. Regarding mods readme: I agree that reading mod readmes are important for knowing exactly what the component suppose to do and crafting your fine-tuned installation. The thing is, no one can remember installation requirements and possible conflicts for 100+ mods. The mod readmes are often read once and that's it. Some readme files were read years ago. When you relying only on readmes in terms of install order or conflicts, it's possible that the future improvements/changes could be missed. What if the installation order has been changed from version to version because a mod got updated and install order requirements no longer apply? What if the mod itself has changed extensively to the point where it should have another name so most of the stuff which people remember from reading readme years ago does not apply anymore? Sure, you can modify readme, but do you think that people will read it over and over again? Year after year? Why not be able to update install order or conflicts anytime you want and be sure that players will never miss any of the benefits of mod updates? Regarding dull chore: It's all about the amount of work vs benefits. The proposed design has some advantages (and disadvantages ) over what's currently available for modders. Similar to the 'Dynamic Install Order' feature, it requires some extra work. All I could do is to make sure it's minimal. Thanks for the feedback, I appreciate it.

@Luke git sync fork with upstream: https://stackoverflow.com/questions/20984802/how-can-i-keep-my-fork-in-sync-without-adding-a-separate-remote/21131381#21131381 - this post show you how to do it 'directly on the Github.com website'. After last step (Rebase and Merge), when they aren't any conflicts, you simply pull the updates which are now also inside your online fork into you local repository.

Hey, can you name them and send me the installation logs?

@Luke Nope, there isn't. Mainly because the commit messages are not suppose to have and git is not designed for such feature. Use changelog.md file for basic header/bold/numbered lists formatting or html if you want fancy colors.

IvanK, download updated WeiDU for Big Sur, extract it and locate 'weidu' executable inside 'WeiDU-Mac' folder locate Mac_Weidu_Launcher_v7.app, use 'Show package content' right, navigate to Mac_Weidu_Launcher_v7.app/Contents/Resources replace 'weidu' executable with the updated one. Hope that this helps. If it does, @subtledoctor you can update weidu directly inside app.

@Grammarsalad Depends on what you want to achieve, you could go for: - set conflict scopes for all game spells which you mod alter so other mods could do the same. This would cover only spells which are modification/replacement for core game spells or new spells which you know that are also covered by other mods (I assume much less amount) - set major conflict scope: SPELLS for both mods so you don't have to create new CS for each new spell. It would also trigger a conflict warring for any other mod which will modify majority of core game spells - collaborate with OlvynChuru and define one, single personal conflict scope, let's say "B_SPELLS-OlvynSpells" for both mods so you don't have to create new CS for each new spell Since the conflicts scopes are defined inside you mod, and the mods have auto-update, it is very easy to update conflict scopes in order to account for recent changes.

@qwerty1234567 1) The case A is different from B because you can install B just fine without error during installation and there are no game bugs, while A would produce error which prevents installation or even if it is successful, it causes game bugs. 2) I don't see why having long list of scopes is harmful of makes this solution worse. Mods doesn't need to use all of them to covet the 'popular game scopes which are covered by many mods". Can you elaborate? An example for the 'WildMage' Misc spell changes component: https://github.com/BGforgeNet/bg2-wildmage#misc-spell-changes This component changes two spells: Magic Missiles and Dimension Door. So the conflict scope would be: METADATA "SPELLS\MagicMissiles ; SPELLS\Dimension Door" so all mods which modify those spells, like for eg "Spell Revisions" could account and warn players about possible outcome change.

@megapilhasWheels of Prophecy is not yet adapted to EE and new Ascension. You might try to uninstall it (make backup) and see if it fix problem.

I remember that you have requested similar feature 'to show warning that component X is not recommended with Y' long time ago. The conflict scopes are not limited to 'category', you could for eg use game resource name. Or totally arbitrary name if only it was agreed between conflicting parties. Regarding SoB#122, I was reading readme and apparently didn't understand it correctly, corrected.

Calling: @CamDawg and @subtledoctor for the case of 'Weapon Proficiency' mods @K4thos and CamDawg for the case of "Change Experience Points Cap" mods @Kish and @DavidW for the case of "Lanthorn Lenses quest" mods @lefreut for the "UI' mods

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.

@lefreut Many thanks for supporting Project Infinity install order rules. Looking forward new releases

Currently, WeiDU 247 cannot be run under macOS Big Sur, it's because of upx https://github.com/upx/upx/issues/424 I've compiled WeiDU 247 without upx for macOS: https://github.com/WeiDUorg/weidu/releases EDIT: It's now available at the WeiDU Releases page

@Luke Yes, you should use this options. It's rather basic stuff.

The work continue in order to enable install order rules directly from components using METADATA keyword. Basic example of how to use WeiDU new 'METADATA' keyword in order to provide data for PI's Dynamic Install Order feature: Example of 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" the format stays the same as for global rules with the addition of usual weidu keyword syntax one statement for one METADATA, you can't put BEFORE/AFTER into single METADATA occurrence local rules from components will override (instead of combining) global rules from ini @jastey Can you take look at the example above and test it using PI 0.8.6 ?

@Luke Sure, bug fixes are important. For macOS you have brew, how I know this without having one and you don't

@Luke - yes - just forget about it, or use something else than VSCode only for git-related tasks (I recommend SmartGit but GitHub Desktop should be enough for simple workflow) - you don't have to update git at all, there are no major features which are worth user attention, Windows version should have checkbox for 'auto-updater' which will notify you and install new version automatically. For manual install: If you have Windows 10 then install 'winget' and then use winget install 'Git' --silent If you have Windows 7, install https://chocolatey.org/install#individual and follow instruction regarding how to install packages Hope that this helps.

@Luke 1. Open VSCode Settings and enable 'Extensions > Git > Allow Force Push' 2. Use git log --oneline to get 'shortID' of the git commit hash: 3. Type git reset --hard 'shortID' Please remember that this will set the local files to the exact content of the commit! 4. Click Push (Force) from the "Pull, Push" submenu This will completely overwrite remote repository to the state of local copy - there is no truing back after this point! No backup! I recommend you to install GitLens extension - it might look like overkill but you can ignore almost all of the advanced stuff and focus on this nice view:

@Luke Which GUI git client do you use? Does you repository has active forks which you receive contributions?