Expanded Mod Configurations

[KiameV]

Just some ideas as I've been exploring the mod making side:

Define Events in Mod-loader

Prevents the circular dependency where the game loads mod-loader & mods and mods loads mod-loader & game

Mod Settings page

To prevent the core game's options page from growing too large, maybe a separate options menu for just Mods

Per-Mod Page

If some mods have many settings, maybe have a list of all enabled mods, and when clicked, a new page will be displayed with the selected mod's options

Pass by reference

Currently each event appears to be a shallow copy of the data of the event being fired. This is the safest approach for game stability but can also add walls to modders. There is likely a balance with this thought, but can we consider passing more things by reference to give a greater freedom to modders so they can modify the game more.

Expanded Configuration Entries (code)**

If a mod has many configurations, maybe a new ConfigEntry could be developed that would return the set of entries.
For instance a mod wants to give the player the ability to modify any enemy's stats while in game. It would be infeasible at this point as it'd require a class for each stat for each enemy.

Maybe a top-level ModOptions abstract class. That class will return a set of Inputs to display on the page. Being able to set Labels would be useful too. I see there's a Control interface for this.

The ModOptions could be generic, the generic could then take the object and, using something like jackson mapper, de/serialize in the background when loading/saving to save each developer the hassle of doing that - i think this is possible but I have not used it enough to say for certain.

In the monster stat mod example:

[ select monster ]
hp: [  ]
mp: [  ] 
...

Code wise, it's much simplified from needing a class for each stat for each monster:

class Options : ModOptions<TreeMap<String, Monster>> {
    @Override
    public List<Widgets> Display() {
        final var widgets = new List<Widgets>();
        widgets.add(new DropDown(...))
        if (selected != null) {
            widgets.add(new NumericInput("hp", ...)
            ...
        }
    }
}

1. TreeMap is explicitly stated to keep it as an alphabetically sorted map. I think that would be required in this case but not sure. This could be an argument to keep the de/serialization either per-mod or overridable
2. The Display function would not need to be called on each frame. An optional argument to any new input could be an onChange callback. That would then let the impl notify when Display needs to be refreshed.

I took some time to further explore this idea in this PR: Legend-of-Dragoon-Modding/Mod-Loader#3