Memoria icon indicating copy to clipboard operation
Memoria copied to clipboard

New configuration format

Open Albeoris opened this issue 4 years ago • 8 comments

Hello there! I plan to develop a new configuration format with automatic documentation.

I also want to allow mods to change individual parameters without changing the user configuration.

I see it like this:

  • Config\Memoria.txt
  • Config\Moguri.txt
  • Config\My.txt

Or this:

  • Config\Audio.txt
  • Config\Battle.txt
  • Config\Export.txt
  • Config\Graphics.txt
  • Config\Graphics.Moguri.txt

What are thinking about?

Albeoris avatar May 25 '20 09:05 Albeoris

Here is an example of how it should look inside. Config.txt

Albeoris avatar May 25 '20 09:05 Albeoris

Hello Albeoris, I also want to develop the configuration format but I was thinking of something else:

  • Keep a Memoria.ini (or .txt as you wish) with different sections instead of having one file per section.
  • Have a field "Mods" that list the mods the user wants to enable. It would be a list of directory names, eg. "Mods=Moguri, AlternateFantasy" would mean that the game will use the files inside the folder "Moguri" in priority, then in the folder "AlternateFantasy" for files that do not exist in "Moguri", then in the normal folders for the non-modded files.
  • Allow assets to be placed out of any archive for improving greatly compatibility problems. For instance, you could have a file "Moguri/[resources/]embeddedasset/manifest/sounds/soundeffectmetadata.txt" and "AlternateFantasy/[resources/]embeddedasset/text/uk/battle/0.mes" (with the intermediate folder "resources" that could be optional): the game would use both files without the problem of having to merge the two resources.assets archive.
  • Another configuration file, "Moguri/Memoria.ini" or "Moguri/ConfigAddOn.ini" can be added in mod folders: these configuration files would work the same as "Memoria.ini" but overwrite the configuration settings and don't contain all the fields. For instance, you could have "BackgroundResolution=32, GarnetHair=0, ..." in the normal "Memoria.ini" and "BackgroundResolution=64" in the "Moguri/Memoria.ini" that would overwrite the "32" default resolution. With that, uninstalling a mod can be done by simply removing it from the list "Mods" of the configuration.

I want to work on that this week. I'll add a couple of bug fixes anyway; if that's ok for you, I can work on that configuration system as well.

Tirlititi avatar May 25 '20 12:05 Tirlititi

Any option to make the old btl_calc.cs work within Memoria? The new system is somewhat harder to mod compared to the old one and makes building gameplay mod more difficult since the two are radically different.

Caledor avatar May 25 '20 13:05 Caledor

@Tirlititi, good idea, but mods should be independent. For example, you just put the mod in the Mods folder and it starts to apply.

To disable, you change the configuration in the mod folder.

This will allow users to easily add and remove mods, while they will not intersect in any way.

with different sections instead of having one file per section. Why? So that all parameters are visible if you do not know what you are looking for?

Albeoris avatar May 25 '20 20:05 Albeoris

Any option to make the old btl_calc.cs work within Memoria? The new system is somewhat harder to mod compared to the old one and makes building gameplay mod more difficult since the two are radically different.

Absolutely not. Instead, it’s better to focus on simplifying the modification process.

Explain what exactly causes difficulties in your case?

Albeoris avatar May 25 '20 20:05 Albeoris

I want to work on that this week. I'll add a couple of bug fixes anyway; if that's ok for you, I can work on that configuration system as well.

Oh, I have the same plans! Let me screw the new format, and I’ll leave you the rest.

A little about the new format

A very simple code:

     [ConfigurationSection("Configuration of audio settings.")]
     public sealed class AudioConfiguration
     {
         [ConfigurationValue("0 ~ 100", "Default: 100; Sound effect volume")]
         public static Int32 SoundVolume { get; set; } = 100;
 
         [ConfigurationValue("0 ~ 100", "Default: 100; Music volume")]
         public static Int32 MusicVolume { get; set; } = 100;
     }

And a detailed description in the file:

// ----------------------------------------------------------
// Audio - Configuration of audio settings.
// ----------------------------------------------------------

// 0 ~ 100 - Default: 100; Sound effect volume
Audio.SoundVolume = 100

// 0 ~ 100 - Default: 100; Music volume
Audio.MusicVolume = 100

<other sections>

At startup, we read the user’s settings and then write the file back. Thus, the new parameters added in the new release automatically appear in the file.

Albeoris avatar May 25 '20 21:05 Albeoris

Absolutely not. Instead, it’s better to focus on simplifying the modification process.

Explain what exactly causes difficulties in your case?

In general it's much harder to follow since btl_calc has everything in one place, while in Memoria i have edit both the scripts and then track the methods within the assembly. But other than that, doesn't the separation between caster and target somehow restrict modding? For example, i replaced "mag elem null" with a support skill that further increases the weakness multiplier.

In vanilla it's the simplest thing ever, all i had to do was move down a few lines the if ((v.caster.sa[1] & 1U) != 0U), within the weakness damage increase.

Is it even possible in memoria? Weaknesses are checked within the Target domain, can i even check data about the caster from there?

Blind guess is that i'm probably forced to hardcode it within the external scripts (thus double weakness check).

TLDR: Memoria makes it much simpler if you just wanna edit the external scripts. Harder if you wanna change even one thing from within the assembly as well.

Caledor avatar May 25 '20 22:05 Caledor

Is it even possible in memoria? Weaknesses are checked within the Target domain, can i even check data about the caster from there?

Sure:

if (_v.Caster.HasSupportAbility(SupportAbility2.MagElemNull))
            {
                if (_v.Command.HasElement(_v.Target.WeakElement))
                {
                    _v.Context.Attack *= 2;
                }
            }

But for what you want, Harmony is best suited. This will make your mods compatible with other:

    [HarmonyPatch(typeof(BattleCalculator))]
    [HarmonyPatch(nameof(BattleCalculatort.CanAttackElementalCommand))]
    internal sealed class BattleCalculator_CanAttackElementalCommand
    {       
        public static Boolean Prefix(BattleCalculator __instance, ref Boolean __result)
        {
            if (__instance.Caster.HasSupportAbility(SupportAbility2.MagElemNull))
            {
                if (__instance.Target.IsWeakElement(__instance.Command.Element))
                {
                    __instance.Context.Attack *= 2;
                    __result = true;
                    return false; // Skip original
                }
            }

            return true; // Call original
        }
    }

                Harmony harmony = new Harmony("https://caledor.mods/BetterMagElemNull");
                harmony.PatchAll(Assembly.GetExecutingAssembly());

Now you can insert this into the loading of any script, but I can screw more transparent support for Harmony.

If you still have questions, create a separate issue. I will try to answer them.

The main mission of Memoria is to make the mods of different people compatible among themselves, eliminating intersections between them.

Albeoris avatar May 26 '20 08:05 Albeoris