INCOMPATIBLE ~setup-cdtweaks~ ~105~ ~short note about the conflict~Doesn't need to do anything, just be there for the sake of notification... then at some point, Zeitgeist could maybe read this and throw a warning if a user checks the boxes for both mod components. It wouldn't be very thorough, at first... but I've already got a few notes like this in my readme, it would be simple enough to add the info to the .tp2 file. And as player reports come in, active modders could have an efficient way to add more such warnings.

Just a thought.

EDIT - note the difference between this and something like FORBID_COMPONENT... the latter only works when the incompatible mod is installed first. And it doesn't let you (easily) choose which component you prefer. A flag like this would allow Zeitgeist to pop a warning when either mod calls for it, irrespective of load order.

Ah, I hadn't seen that. But to be clear, this is something distinct. There are lots and lots of times where I know a component of my mod has compatibility issues with another mod, but I don't use FORBID_COMPONENT. It may be a soft, "things might be weird but you might find it fun anyway" incompatibility, where I want to preserve the player's choice to install both; or it could be as simple as, the other mod is not actively maintained but mine comes first in the install order, so FORBID_COMPONENT would be ineffective.

That's why I think a 'notice-only' flag, which does not actually affect installation, would be useful. And it would shift some of the burden of conflict reporting to modders, to help Zeitgeist avoid the BWS situation where a few people had the immense burden to maintain conflict-checking code.

(I'm very specifically trying to create a suggestion that would involve as little coding as possible to implement. A component flag with zero function? Should hopefully be easy... )

Fev remarks from my side:the missing part is a component/designated number which has conflict with another mod/mod component. Let's look at some of the examples of the BWS conflicts written in a new, simplified format:

weidu can output such information to -list-incompatibility or combine such data with --list-components-json. But ...

That's a lot of extra code. Also whenever a single component number will be changed, the whole conflict will be ruined and it would require 3 other mods to change it's code (old mods won't get updates ever). It can also lead to unwanted tension between modders - history shows that not everyone is wise and can take technical recommendations over personal feeling.

I'm not saying that such feature is useless but the amount of work, tendency to produce errors and significant foreign mod dependency makes me think about similar BWS hell. Without improved solution I wouldn't recommend implementing it.

Rather than having a monolithic list of incompatibilities in the .tp2 file, I'm envisioning a few lines in each component, with the various REQUIRE_PREDICATE, FORBID_COMPONENT, SUBCOMPONENT, GROUP, and DESIGNATED flags (etc.) It will start out with only a few such notes in each component, or even none; and modders can easily add more as reports come in. And because it's just a two-way notification, unlike FORBID_COMPONENT which is a one-way forbiddance that relies on install order, active modders can note incompatibilities with inactive mods, and it work even though the inactive mod is never updated.

I know you've worked on BWS for a long time, and done good work there; but I'm not sure the BWS method that you inherited is the best. Relying on a single person to stay on top of compatibility issues is just too much work... and here, that person would be Wisp. Unless Zeitgeist allows for some kind of 3rd-party plugin... but even then, it would still be a single person tasked with handling it. Why not spread that burden to modders themselves?

Fact is, componenent numbers should not really change once a mod is released in "v1" status. And component numbers almost never change in old, inactive mods. So while it's a potential point of failure, it would be rare, and it would be very simple to address with an update.

I like the part when you say thet mod authors "can easily add more as reports come in". But i don't like using tp2 for such information because every modder would effectively create his own, tiny "conflict database". That's why there is already one online database of the conflicts between various mods/components. The problem is: moddeds can't effectively contribute to it other way as email/forum post - that is what should change definitely but I can't take whole world on my back. There might be people who will be interesting to create online database + interface ... corvias ... I"'m sure that we need to eliminate "changed component number" problem (we need to use GUID!) in order for such online database to be useful.

And there is one more thing to consider:- let's assume we have two mods: ABC, ZXC- mod ABC has "INCOMPATIBLE_COMPONENT" "ZXC"- mod ZXC has "INCOMPATIBLE_COMPONENT" "ABC "

BWS allows for automatic conflict solving - you click one button and all required mod/components are added and all conflicted mod/components are removed. Those two conflicts for two mutually exclusive were read from mod's tp2. If you present such conflict to the users, it's no problem because they would have to choose one or another or ignore it. But when users doesn't want to deal with manual conflict solving which mod should be removed? How it should be determined? Definitely not by name, release date or which comes first. BWS solve it by having one line for conflict: ABC>ZXC - ABC will be chosen and ZXC will be removed. The idea/implementation of the "auto-solving mod conflict" is much bigger that such simple case.

Quote

Relying on a single person to stay on top of compatibility issues is just too much work... and here, that person would be Wisp

Yes, its too much work but unless I didn't understand what you mean, in case of Zeitgeist it won't be wisp either.

P.S. Nothing prevent Zeitgeist from reading BWS conflict database and apply the same rules for conflict resolution but I seriously doubt that wisp would be interested putting extra work into it and I'm not sure if it's the purpose of the Zeitgeist.

But i don't like using tp2 for such information because every modder would effectively create his own, tiny "conflict database". That's why there is already one online database of the conflicts between various mods/components. The problem is: moddeds can't effectively contribute to it other way as email/forum post - that is what should change definitely but I can't take whole world on my back.

Literally the whole point of the suggestion is to not have one online database of conflicts. Precisely because one person can't take the whole world on their back, and we want to avoid a situation where the database goes to rot and leaves players in the lurch if a single person stops maintaining the tool.

And there is one more thing to consider:- let's assume we have two mods: ABC, ZXC- mod ABC has "INCOMPATIBLE_COMPONENT" "ZXC"- mod ZXC has "INCOMPATIBLE_COMPONENT" "ABC "

BWS allows for automatic conflict solving - you click one button and all required mod/components are added and all conflicted mod/components are removed. Those two conflicts for two mutually exclusive were read from mod's tp2. If you present such conflict to the users, it's no problem because they would have to choose one or another or ignore it. But when users doesn't want to deal with manual conflict solving which mod should be removed?

I don't know but it's certainly a solvable problem. There's no reason Zeitgeist couldn't have a 3rd-party plugin to deal with conflict resolution. Or have its own list of conflicts that it analyzes before any mods run, which could tolerate conflict identification that is redundant with this proposed component flag. Heck, Zeitgeist doesn't have to do any conflict resolution. That can be left to some 3rd-party tool.

All I'm suggesting is an easy method for modders to report conflicts, within the mod, in a way that is readable by Zeitgeist or whatever other tool. What to do with that reporting - if the conflicts get handled directly, or the reports get imported into an online database, or whatever, is a separate question.

What kind of incompatibilities are we talking about here? If you receive a report and are in a position to update the mod accordingly, what obstacle is there to changing the mod to handle the incompatibility gracefully?

1) To describe what I'm suggesting, consider FORBID_COMPONENT. The new FnP item usability code cannot work with CDTweaks' 'Altered Proficiency System.' If CDTweaks were installed first, I could try to add compatibility, or I could use REQUIRE_PREDICATE NOT MOD_IS_INSTALLED, or I could use FORBID_COMPONENT. (The latter two are, unfortunately, redundant.)

Problem is, CDTweaks gets installed after FnP. Ideally there would be an option to actually forbid the CDTweaks component, but none exists. So I can only mention "don't install that!" in the readme and hope that players comply. Not ideal.

Anyway actually forbidding another mod is not very nice. But with a GUI* we have more options available. If the two components are both checked, we can issue a warning to users, simply to raise awareness of the conflict before hitting "go" and wasting several minutes or even hours.

2) As for which kinds of conflits this might apply to: the short answer is, whatever a modder wants to communicate. It's just a message after all. The above example of one mod knowing that a conflicting mod will be coming down the pipe later, when the first is helpless to do anything about it, is a good example. Of course CamDawg or somebody might update CDTweaks to resolve the conflict. And then FnP could be updated to remove the warning. A good warning would possibly communicate version numbers and other information so that the scope of the conflict is clear.

Another kind of conflict is when two mods will never be compatible, due to covering the same ground with different code. Consider IR's armor changes and FPPS. FPPS is currently basically abandoned, but it is still a good mod and still used. And it is installed extremely late. So how is an early-install mod like IR to deal with it? Right now the only tools are readme and hope.

* This kind of thing could even work without a GUI. When the later mod is about to be installed Weidu could display the warning and ask something like, "are you sure you want to install this? There is a reported conflict with an earlier mod: (blah blah blah)"

Of course CamDawg or somebody might update CDTweaks to resolve the conflict. And then FnP could be updated to remove the warning.

I'm sure I would, if someone reported it in the Tweaks forums.

Sorry - if I implied that CDTweaks was deficient in any way it was unintentional. In this case, I'm not sure CDTweaks should add compatibility code... should every mod add code for specific edge cases introduced by every other mod? I guess that's a philosophical question as much as a prescriptive one.

In this particular case, it relates to an unstable build of FnP with features that are still under development. So nothing to report yet. Once the mod is stabilized I'll post about it on the Tweaks forums.

No worries, I didn't take it as a slight. If it's not something that can be resolved code-wise, then I can at least note it in the readme or have Tweaks skip components as needed. There's a great deal of responsibility w.r.t. compatibility as one of the 'install me last' mods.