[MOD] Meaner Monsters

A curated forum for compatible and maintained mods. Users are unable to create new topics in this forum but can reply to existing topics. Please message a moderator to have your mod moved into this forum area.
Post Reply
User avatar
Ralzar
Posts: 2211
Joined: Mon Oct 07, 2019 4:11 pm
Location: Norway

Re: [MOD] Meaner Monsters

Post by Ralzar »

Your use of the override function doesn't look quite right, but it's hard to read on a forum.

You should take a look at my LevelUp Adjuster since it does only one thing: use override functions.

viewtopic.php?f=27&t=3337

I just added a link to my Github in the bottom of the OP of that thread.

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: [MOD] Meaner Monsters

Post by Magicono43 »

Ralzar wrote: Tue Mar 03, 2020 7:26 am Your use of the override function doesn't look quite right, but it's hard to read on a forum.

You should take a look at my LevelUp Adjuster since it does only one thing: use override functions.

viewtopic.php?f=27&t=3337

I just added a link to my Github in the bottom of the OP of that thread.
Alright, now that I saw your in-practice examples from your LevelUp script, I think I have a better idea on how to actually use the RegisterOverride method, still don't really know "why" it works as it does, but at least I know what made you put the parameters the way you did. Sucks that the first one i'm trying to work on has multiple different input variables involved instead of just one or two, just makes it that much more confusing. Hopefully i'll have something to post that somewhat functions in a bit.

User avatar
Ralzar
Posts: 2211
Joined: Mon Oct 07, 2019 4:11 pm
Location: Norway

Re: [MOD] Meaner Monsters

Post by Ralzar »

Yeah, the combat methods in FomulaHelper is prehaps the hardest place to use overrides at the moment, as I discovered myself when attempting to set it up.

Not because it's very hard to do, but because you wind up pulling out so much of the mechanics and then making it impossible for anyone else to override the underlaying methods. Which leads to the mod being incompatible with other mods.

Hazelnut is looking at it. So perhaps in a later version of the live build, the combat stuff will be coded differently and be more open to modding.

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: [MOD] Meaner Monsters

Post by Magicono43 »

Ralzar wrote: Wed Mar 04, 2020 9:51 am Yeah, the combat methods in FomulaHelper is prehaps the hardest place to use overrides at the moment, as I discovered myself when attempting to set it up.

Not because it's very hard to do, but because you wind up pulling out so much of the mechanics and then making it impossible for anyone else to override the underlaying methods. Which leads to the mod being incompatible with other mods.

Hazelnut is looking at it. So perhaps in a later version of the live build, the combat stuff will be coded differently and be more open to modding.
Doesn't the registeroverride method already handle that problem to some extent though? The last if-statement has something to do with load-priority, so I would assume that normally incompatible mods could just override each other depending on which one is put at a lower load order than the other.

Code: Select all

public static void RegisterOverride<TDelegate>(Mod provider, string formulaName, TDelegate formula)
            where TDelegate : class
        {
            if (formulaName == null)
                throw new ArgumentNullException("formulaName");

            if (formula == null)
                throw new ArgumentNullException("formula");

            var del = formula as Delegate;
            if (del == null)
                throw new InvalidCastException("formula is not a delegate.");

            FormulaOverride formulaOverride;
            if (!overrides.TryGetValue(formulaName, out formulaOverride) || formulaOverride.Provider.LoadPriority < provider.LoadPriority)
                overrides[formulaName] = new FormulaOverride(del, provider);
Maybe i'm thinking about it incorrectly, but it seems like it already has sort of a built in "solution". Sort of like when modding Skyrim and big mods say they need to be loaded last so their overrides take priority over others that change similar things.

User avatar
Ralzar
Posts: 2211
Joined: Mon Oct 07, 2019 4:11 pm
Location: Norway

Re: [MOD] Meaner Monsters

Post by Ralzar »

To take an example:

Hazelnuts RP&R mod changes how much armor is damaged when you are hit. This is part of the combat methods. If I make a mod that override the same method, the last one loaded will be the one that is used. I could possibly decide to design my mod so RP&Rs override took precedense, but you would not be able to merge the overrides.

However, in this case, the problem is bigger. Since I can't call a number of these methods, because they are private, I have to make my own versions, which will then absolutely not care about mods that override those methods, since the original overridden versions of those methods are not called by my override version of the combat method.

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: [MOD] Meaner Monsters

Post by Magicono43 »

Hmm, so it sort of defeats the purpose of having the load priority being a thing then. At least from what little I know about object oriented programming, they could not really just change currently private methods to public, because that could potentially cause issues in other parts of the code-base due to variables having similar names or something. At least that is what I figure, so maybe the methods would have to be broken up into smaller sections so smaller aspects could be overridden, while not having to reproduce the entire method and cause the compatibility issue as you mentioned.

Then again, if that was not feasible, mod creators could just explicity state "Not compatible with mods that alter x mechanics from y classes" or something like that. Obviously not an optimal solution there though.

User avatar
DigitalMonk
Posts: 111
Joined: Sun Nov 10, 2019 8:01 pm

Re: [MOD] Meaner Monsters

Post by DigitalMonk »

Magicono43 wrote: Wed Mar 04, 2020 1:58 pm Maybe i'm thinking about it incorrectly, but it seems like it already has sort of a built in "solution". Sort of like when modding Skyrim and big mods say they need to be loaded last so their overrides take priority over others that change similar things.
Gonna take a side step to Morrowind/Oblivion/Skyrim modding here, 'coz I don't have enough experience with the internals of DFU to feel comfortable saying too much. But, if we consider these commercial TES games to be the "gold standard" for moddability, then we also have to consider their failure cases:

Part of the problem here is "overrides" vs "interacts with".
  • "overrides" : If a mod later in the load order completely overrides everything that it needs, then placing it last in the load order will make it work as it expects (though quite possibly breaking mods earlier in the load order, and almost certainly reducing the overall moddability of the system as it overrides so much).
  • "interacts with" : If a mod only overrides the specific functionality that it wants to change, then it can interact with other mods in the system, but may be much more fragile to changes whether earlier or later in the load order.
Again, examining the mod databases for the commercial TES games, we see that there are a lot of "compatibility" mods, which are required because two popular mods can't work properly together. Note: I didn't say "don't work", I said "can't work", and I mean that in the technical way. Some aspect of what those two mods are doing is in fundamental conflict, neither can address the issue without giving up on their purpose, and the only path forward is to provide one or more compatibility mods that load after them in the load order and apply some kind of tradeoff between their behaviors.

For programmers who have ever worked in a team, the term "merge conflict" and the process of "resolving" those conflicts is well known. Tools have gotten much better in the source code world, but it is never possible to completely automate. So, while we can (and want to) try for better, more moddable infrastructure, the problem will always exist to some degree.

User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: [MOD] Meaner Monsters

Post by Hazelnut »

Hazelnut wrote: Mon Mar 02, 2020 9:33 pm Ralzar, there's definitely more work to break down the combat formula to be more modular, but it can be done on a case by case basis. The focus was on reproducing classic and we need to be careful to preserve that effort while making it moddable. Overriding the big calc damage formula is really only appropriate for complete replacement mechanics which is why you found it so hard. It would be useful to me if you were to suggest logical blocks of formula for separation, however this is probably not the right place for that discussion.
Going to quote myself as I don't think I was clear enough, or at least the ongoing discussion doesn't appear to have taken on board what I have said.

To my mind the issue here is that the combat formula are not broken down into parts much yet. I did a bit, but I tend to do this kind of re-factoring as required. (agile.. yay)

The component formula are private so that a modder has the choice to tweak parts of the DF combat calculations (i.e. override these small private formula) or replace the combat calculations with something new (i.e. override the larger public formula) - I think it's probably best to not allow mixing these two approaches, as it could lead to strange interactions between mods. There needs to be more of the private component formula and I will re-factor these out given time and need.
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
BadLuckBurt
Posts: 948
Joined: Sun Nov 05, 2017 8:30 pm

Re: [MOD] Meaner Monsters

Post by BadLuckBurt »

Hazelnut wrote: Wed Mar 04, 2020 6:46 pm To my mind the issue here is that the combat formula are not broken down into parts much yet. I did a bit, but I tend to do this kind of re-factoring as required. (agile.. yay)

The component formula are private so that a modder has the choice to tweak parts of the DF combat calculations (i.e. override these small private formula) or replace the combat calculations with something new (i.e. override the larger public formula) - I think it's probably best to not allow mixing these two approaches, as it could lead to strange interactions between mods. There needs to be more of the private component formula and I will re-factor these out given time and need.
I agree. I don't quite follow the discussions saying it should be otherwise tbh. If there's any example of mods for other games where two mods are affecting the exact same mechanic or calculation, I'd love to know, especially with things like combat. Usually one just picks the mod that best suits their desired gameplay and allowing queueing multiple functions for something like damage calculation is just asking for trouble and to be frank, insane. All the mods I've installed for other games that affect the same area are usually complimentary to each other i.e. one mod does what the other mod doesn't do yet and very rarely does that involve game mechanics.
DFU on UESP: https://en.uesp.net/w/index.php?title=T ... fall_Unity
DFU Nexus Mods: https://www.nexusmods.com/daggerfallunity
My github repositories with mostly DFU related stuff: https://github.com/BadLuckBurt

.

User avatar
Ralzar
Posts: 2211
Joined: Mon Oct 07, 2019 4:11 pm
Location: Norway

Re: [MOD] Meaner Monsters

Post by Ralzar »

I'd say no one disagrees with that. I'm just presenting what the situation is with the current live build code, to explain why this can't be done in a satisfactory way right this instant.
I agree with Hazelnut that the solution is to break the formula down into parts so they can be overridden separately. The big problem at present is that you have one main method that calls a bunch of private methods while still handling a lot of mechanics. Leading to you having to chose if you want to
A:override one peripheral bit of the mechanic
or
B: override everything and the kitchen sink.
It would be much more handy with a main combat method which did little more than call different private methods that could be overridden. So it's possible to pick and choose. This would be two mods interacting. Like, for example, one mod that overrides how damage is calculated and another that applies damage to armor.


The next "level" of modability I could imagine would be if one mod could override the same method as another mod is already overriding, but actually check the override code from the first mod and use its code in conjunction with its own. But that is not particularly necessary if the core code is modable enough.

Post Reply