Jump to content

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


Recommended Posts

On 12/7/2020 at 10:32 AM, AL|EN said:


Depends on what you want to achieve, ... 

Ok, that sounds promising. I do already have an ini, so I have something to work with. Okay, concrete example. I have a spell 9th level Weird as does OS. The way we're doing it, it is easily possible both versions could be installed and available to the player (there are only so many 9th level spots available for various reasons, and so ADD_SPELL isn't an option.) 

My spells are set so that they only install based on ini settings. So, what change would I make to warn about the type c incompatibility:


Edit: and yeah, I realize (now) that at the very least, I can put a (commented out) warning in the ini

Edited by Grammarsalad
Link to comment

On the general proposal: for the most part I don't think this is realistic as stated, basically for the reasons qwerty1234567 gives. One of the key features of IE modding is that multiple mods can compatibly edit the same game files, and the better-written mods go to great lengths to try to do so. For instance, SCS modifies something like 1,000 .spl files (including pretty much every player-usable spell), 4800 .cre files, 100 .dlg files, and 160 .are files (and much more besides). But most of those modifications are minor things that should play nice with other modifications. Flagging any other mod that alters any of those files as potentially conflicting with SCS would be massive overkill and generate mostly false positives. Designing a syntax that allows more fine-grained flagging of modifications sounds an incredibly difficult task (something between 'would be a good PhD topic in CS' and 'is AI-complete'), and in any case would create a prohibitive amount of work for modders.

(There is a closely-related technical issue: compatibility doesn't just depend on *what* is modified but *how* it's modified. (Ascension 1.4 and Ascension 2.0 modify very nearly the same resources relative to an unmodded install, but 1.4 does it by blanket overwrites and 2.0 is much more subtle.) And writing compatibility-friendly modification code is often hard, even with modern tools, so that different mods manage it to different degrees - and many modders are borrowing not-fully-understood code from other sources and aren't fully reliable about how compatibility-friendly their own code is.)

There might be a happy medium - something fine-grained enough to be of some use but not so much so as to be unmanageable. But it's not obvious to me that it is, and in any case I think the devil would be in the details - someone would have to design it, in detail, and mark up a bunch of the big popular mods to see how well it worked in practice. (I appreciate SCS is an extreme outlier in the scope and systematicity of its editing, although Tweaks Anthology isn't so far behind.)

On the specific point of the Lanthorn quest clash (I assume you mean the clash between Kish's Lanthorn component and my 'restored Lanthorn' micro-mod? - if there's a clash with Wheels of Prophecy, I'm not aware of it): Even a casual read of the two readmes should make it obvious that they clash, so I'm not sure what's to be gained by an automated system in this case. I'm strongly of the opinion that it is a very bad idea to install IE mods (or any software, really) without at least a casual look at their readmes, so I'm not keen to do anything that encourages people to do so.

There's perhaps a broader point here: many mods tend to be under-documented or plain undocumented. That's understandable - modding is a hobby; writing documentation is dull; updating SCS's documentation is usually my least favorite step in a mod update. But it's a problem precisely because it makes installation and compatibility hard to judge, at least for the (I assume) majority of end-users who don't spend ages perusing the forums for the latest instructions. I'm not sure I wouldn't rather encourage people to document their mods and keep that documentation up-to-date, rather than introduce what's probably going to seem like another dull chore. (Of course I could be persuaded otherwise by a sufficiently well-designed flag system.)

Link to comment


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.

Link to comment

There's 3 options:

  1. A pre-defined set of scopes.
  2. 1 + custom scopes.
  3. A set of rules for scope naming.

I believe the only one that will possibly be useful is 1). The other two will likely lead to a number of scopes greater than the number of actual conflicts, and increase maintenance burden rather than reducing it.


On the other hand, I'd like to retract my previous point to some degree. It not necessary to markup the whole mod in one go. In fact, probably not possible except for the simplest mods. Conflicts can be added as they are discovered. However, that requires collaboration from both authors.

And that brings us to the next issue, where the system fails hard: it takes two to tango. Until both mods are updated, the manager doesn't know about the conflict, and is displaying wrong data to the users. And one of the mods may never be updated. What are you going to do? Exclude the mod from the manager altogether? That's a bit heavy handed. Allow one-sided conflict rules based on LABELs or DESIGNATED or whatever? But what if such a rule was added, and then the author went AWOL, but the conflict was resolved by the other mod's update?

You can easily reverse this, too: A/B/C all conflict and marked as such, B and C resolve their conflict, A is stale, now you're displaying a non-existent conflict.

Some more puzzles:

  1. Take the 3-mod edge case and make it 4. Now instead of 3 relationships you got 6.
  2. Mod A is compatible with both B and C. But it's not compatible with their combination.


To summarize:

  1. I agree that the scope system could be useful some cases.
  2. However, there's no way it'll cover every possible confict without becoming unmanageable.
  3. For a complex enough mod, it's cost prohibitive to mark it up in its entirety from the beginning. So the updates will be incremental.
  4. Still, warning about some conflicts is better than nothing.
  5. But over the years, discrepancies will pile up. Unfortunately, the only possible solution I see for the stale code is a centralized database.

And I know, of course, that centralized dbs didn't do great so far. However, consider this:

  • Scope system: it takes two certain people to mark a conflict: authors of mods A and B.
  • Centralized system: it takes literally anyone to submit a pull, and anyone else with access to the list (which should include the said authors) to accept it.

The second has a better chance of happening, simply because there's many more people who can make it happen.


Well, I don't know the answer to all this madness. But it seems to me that a combination of scoping with a central db for finer control could possibly work.

Link to comment

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


Link to comment

I responded there. And irrespective of that, please consider using yml instead of ini, however this and that works out.


3 hours ago, AL|EN said:

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.

Not at all. A centralized list doesn't mean scopes can't be used. If anything, it's even easier to introduce them.

Edited by qwerty1234567
Link to comment

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:



Now, everything breaks when the mod will change it's DESIGNATED and we are back to the BWS nightmare.

Edited by AL|EN
Link to comment

You're right, individual components conflicts with their numbers will certainly fail to be maintained in a centralized fashion.

  • It's possible to have a centralized list for global conflicts, while keeping the local ones in metadata, but that's likely to get even more confusing.
  • It could be possible to automate stuff with github actions, parsing and maybe even committing the updates into global list, but duplicating data is never a good idea and will also incure extra burden on the modders.

So, I agree that the distributed way is more likely to succeed, even with the issues I listed.


And it's not that I like the centralized way too much. Quite contrary, in fact. It's just that I didn't see an alternative way to deal with code rot.

But coming to think of it, I do have one more idea: a central override list. Which would be used as a last resort option, when there are documented problems caused by prolonged lack of updates by missing modders. A manager could compare the timestamps of the last release vs update time of the override file, and use whichever is newer. Normally, the override repo would be completely empty (and hopefully it stays so). And even if an old override file gets forgotten, it wouldn't matter. This could be the best of both worlds. Finally, there's even no need to implement this until such an issue arises. If it ever does, then you could add this functionality - I think wouldn't be too hard? (This applies to both conflicts and Dynamic Order).


2 hours ago, AL|EN said:

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.

Well, you have one now. All those who think that ini is better than yml in this use case - raise hands!

Is it still supported now? I'd convert to yml.

Edited by qwerty1234567
Link to comment

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

Link to comment
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...