Solved Question about oxide hook conflict with return values

Hi there.
I couldn't see this earlier so I wanted to ask this question.
If you have two mods that return a value for OnXpEarn and they both cause a conflict how does oxide handle this?, Will it take the highest value, lowest value or ignore them and return normal value?

Also would there be a way to overide that behaviour?, I ask this as some mods I am developing will implement a cap system and when a player is at that cap they cants earn any XP, But as you can imagine servers with that mod and a XP adjuster mod cause a conflict.

 

Ok thanks Wulf, that would explain one of the other errors caused, thanks for that. I am currently looking into solutions.

 

Maybe when a hook has a conflict it could pass that to a function, in that function it will check for a server setting, if not will use default.
The Default would be built in, but could include a override in the config, and then a player could specify what to take eg
OnXpEarn = Lowest
OnEntityTakeDamage = Highest

And then oxide would use the value from that.

I honestly dont know if this is possible, but at least if that was done then it could allow servers to adjust how the conflict is resolved by adding that call and then a Lowest/Highest.

What are your thoughts on that?

 

The issue with this is that resolving conflicts between two plugins is usually a bit more complex than just deciding which of the two plugins should have priority.
In your specific example this approach might work, but I can think of a couple of conflicts that have occured in the past that aren't as easy to resolve.
Also, by providing priority configuration you're effectively giving the user the option to disable certain features of the plugin.
This might harm the integrity of the plugin (the plugin relies on the return value being used in a certain way).
I'd also like to add that not all conflicts are caused by return values of hooks.

A perfect example for how this doesn't work well would be the mod load order in Skyrim. You can load certain mods after other mods that would normally conflict, resulting in the mod loaded at a later point overriding the overlap between both mods. This can be seen as the equivalent of your suggested priority system.
In reality, this is barely ever useful. Usually you're breaking the balance of some mod or even its integrity, it's incredibly rare that this works well, and if two mods conflict, you usually need a compatability patch.

In Oxide, these compatability patches are essentially included in the plugins themselves by the plugin devs, which is a good thing, because it makes it a lot easier to set up for server owners.

Personally, I think the way it is right now is good enough.

 

You make a fair point sqroot,
The Skyrim way of loading this is usefull when dealing with conflicts, for example a mod that changes XP earned to 0 because they are at a cap would get priority.

I do agree that the current system of Mod Devs working together to allow compatibility is great, But does also have its own flaws, for example if a Dev doesn't want to alter there mod to allow compatibility, or maybe there sick/unavailable....

But my original question was answered by Wulf and I have good idea on what I need to do to resolve my particular incompatibility (add ability to adjust XP %).

I dont think I have really run into any other compatibilities with my mods, only now that my current Mod (PvX) is heavily reliant on the new XP mods to regulate level caps am I finding issues .
But I guess that is the fun of making mods ;-).

 

The example you named just now with XP wouldn't work well with a priority system either.
When setting a priority, you can essentially permanently decide whether you want a feature of plugin A or of plugin B.
If plugin A changes the earned XP to 0 when reaching the cap and has priority over plugin B, then the behavior of plugin B will never get triggered.
In this case, conditional compatability might make a lot more sense: Prioritize plugin B until a cap is reached, then prioritize plugin A.
Conditional compatability requires programmability, and as such, it cannot be cleanly solved with a priority system, so even in this case extra code in both plugins is necessary to properly handle the conflict.
What I'm saying is that most conflicts are like this. A simple priority is almost never good enough to really find a good compromise between both plugins.