Jump to content

Global Conflict Scopes - establish conflicts between multiple mods from different authors


AL|EN

Recommended Posts

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:

UEBGD0q.png

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

Edited by AL|EN
Link to post

Wouldn't it be better to try this: to do the cdTweaks mod combination and have all the possible tweaks in the same mod, and thus have no conflicts at all, while retiring the old versions... like say you don't use/offer the SCSI anymore for reasons. And all the things it would require is a code contributor credits in a readme. Ouh, and a someone that actually knows how a mod works it's magic of course. I believe a GitHub project could do a lot of this, as it offers the possibility of multiple code contributors.

Link to post

Uh, yes? I was called? 

Btw the idea of specifying a “scope” of a conflict, i.e. categorizing it, will only work for some conflicts. UI overhauls, sure. But some mod components conflict with one another not because they belong to some category, but just because there is conflicting code in those particular mod components. Defining a category for that is senseless, since it will be a set that contains only one item. Easier then to simply demarcate the item (component conflict) and omit the set (category/scope). 

Also btw, SOB#122 does not, to my knowledge, conflict with CDTweaks#2160. I think that CDTweaks component has three or so subcomponents; the first one is compatible with SOB#122; the rest of them are not. (I don’t know the CDTweaks component numbers for each subcomponent, you can look them up.)

Link to post
10 hours ago, AL|EN said:

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.

I'm still digesting @subtledoctor's comments - but as far as the edge case listed here, you know my preference.  I'd prefer the more complex alternative to be able to allow specific exclusions based on TP2/Label/Designated #.  Speaking from the perspective of attempting to make new mods play nice with older ones, one has to be aware of them in order to do so.

Question: How does one communicate the difference between a major and a minor conflict? Do we just ignore minor ones?

Link to post
13 hours ago, subtledoctor said:

Uh, yes? I was called? 

Btw the idea of specifying a “scope” of a conflict, i.e. categorizing it, will only work for some conflicts. UI overhauls, sure. But some mod components conflict with one another not because they belong to some category, but just because there is conflicting code in those particular mod components. Defining a category for that is senseless, since it will be a set that contains only one item. Easier then to simply demarcate the item (component conflict) and omit the set (category/scope). 

Also btw, SOB#122 does not, to my knowledge, conflict with CDTweaks#2160. I think that CDTweaks component has three or so subcomponents; the first one is compatible with SOB#122; the rest of them are not. (I don’t know the CDTweaks component numbers for each subcomponent, you can look them up.)

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.

Edited by AL|EN
Link to post

So far, I like the idea.  It also reminds me of a more sophisticated version of Roxanne's EET Installer Tool which shows certain mods as using the same resources and conflicting when this is only sometimes true.

How would such a conflict list be maintained?  The Big World Setup (BWS) team burnt out on keeping up with all mod conflicts and install orders.  Also, what about official game updates?  Infinity Engine 2.6 is coming (and was released in beta form) and knowing which mods to use with which official game versions helps!

What defines a minor, a medium, and a major conflict?  Also, what about mods that cause errors or undesired/unexpectedly bad behavior mid-game, not at install time?

Will there be warnings about using content from a specific author or set of authors, or just from a specific mod?  Roxanne has been an oft-referenced target of controversy on this board, and I don't want people effectively blacklisting mods due to a conflict of 'low mod quality' or 'we don't like this author.'

Will there be a way to auto-update mods to EE/EET compatibility to resolve conflicts with not being compatible with EE(T)?

Thankee!

Link to post
1 hour ago, Endarire said:

Roxanne has been an oft-referenced target of controversy on this board

Possibly because she leads people to say things like “Roxanne’s Installer Tool,” as if it is hers, when it in fact is an open-sourced tool created by others. She just has her own personal fork of that tool. (Analogous: you can freely create a fork of one of my mods, but I don’t think we would describe your fork of my mod as “your mod.”)

Anyhoo:

1 hour ago, Endarire said:

How would such a conflict list be maintained?

The old BWS-derived tools like Roxanne’s project needed a single authoritative person to maintain such list. Opening up the code and putting it on Github (which is what allowed Roxanne to fork it) was largely an effort to enable more people to share that burden. That effort failed. AL|EN is promoting a more effective way to (partially) spread the burden of maintaining a list of conflicts among many modders.

Link to post

Spells & Magic (B_Spells) will have certain conflicts of type C with certain other spell mods, especially OlvynSpells in that certain spells cover the same ground.  OlvynChuru has made some accommodations for these conflicts, but I'm not sure if they are all covered (I'm almost certain they are not).  One issue with creating a list atm is that both mods are currently still in development.  I have it in my head that when B_Spells is finalized, and when OlvynSpells is finalized, I'll go through both and send OlvynChuru a pull request (OlvynSpells should be installed after S&M).  But, will they ever really be finalized?  I don't know.  I keep thinking of new spells to create, or new spell related components to add.  There is no responsible adult in the room when I'm modding, so I just keep going and going.  Also, why look for conflicts between mods when I can create more conflicts by adding some new fun shiny.  Heh.  I guess it's this sort of thing that makes me hesitate to actually release any of my mods (except for Faiths & Powers, but SD is the responsible adult in the room).  

I'm very much for this sort of thing, but at the same time, I know myself--and, I'm at least aware of the hot-cold empathy gap.  I'll nod my head and sincerely--that is, in the moment--promise to contribute, but I'll probably just keep making a mess of things.  

Link to post

1) a) and b) cases look the same to me.

2) I don't think it'll fly. Mods are changing everything. The number of scopes will either be not enough, or explode exponentially.

 

On 12/4/2020 at 7:40 AM, subtledoctor said:

Possibly because she leads people to say things like “Roxanne’s Installer Tool,” as if it is hers, when it in fact is an open-sourced tool created by others. She just has her own personal fork of that tool. (Analogous: you can freely create a fork of one of my mods, but I don’t think we would describe your fork of my mod as “your mod.”)

On an off note, it's perfectly acceptable to fork and distribute an open source project (as in, FLOSS - I don't if BWS is). And it's actually beneficial to do so under a different name, so that it's clear to the users which one they are using and where to go for support. Which doesn't negate the requirement for giving due credit to all past and present contributors, of course.

Link to post

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

Edited by AL|EN
Link to post

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

Link to post
2 hours ago, AL|EN said:

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

1) sorry, I meant to say b) and c)

2) so let's say there's one mod that changes MM range, and another one changes their damage. They don't conflict. But they could conflict with others, so we need to extend the scope to "SPELLS\MagicMissiles\Damage; SPELLS\MagicMissiles\Range".

Cool. So what, I'm supposed to detail every change in the mod in this format? Well, I'm simply not doing that.

 

Worse still, two mods may conflict only when in presense of some 3rd mod.

Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...