Add a method of saving settings back to a file

[SrGesus]

Problem

Currently you can read settings from file but not write back to it.

Solution

Add a method to the settings class (I kind of don't like this because everything I/O related to settings is in the plugin instead of the class)

Alternatives

Perhaps a system that runs periodically? Not a big fan

Store back to file on every change? Would be doable when #456 is implemented

[RiscadoA]

Thanks for creating the issue! One other alternative would be to have some sort of SaveSettingsEvent which the settings plugin detects. This way you could keep the Settings class clean

[SrGesus]

Yes, sounds like #456 right?
Will be looking into it

[RiscadoA]

Yes, sounds like #456 right? Will be looking into it

Yeah you can couple it with that one, but I don't know if it's a good idea to always save the settings when they are changed 🤔 I guess that behavior should be configurable with its own setting 👀

[SrGesus]

Since mValues is private it is just be easier to do the serializing as a Settings class method but a question remains:

If there is a field, e.g - "assets.path" = "/assets/"

What should the settings.json look like?

{
  "assets.path": "/assets/"
}

{
  "assets": {
    "path": "/assets/"
  }
}

I'm leaning 1 because it's:

• Much more trivial to implement
• More efficient in both serialization and deserialization

[RiscadoA]

Since mValues is private it is just be easier to do the serializing as a Settings class method but a question remains:

If there is a field, e.g - "assets.path" = "/assets/"

What should the settings.json look like?

{
  "assets.path": "/assets/"
}

{
  "assets": {
    "path": "/assets/"
  }
}

I'm leaning 1 because it's:

* Much more trivial to implement

* More efficient in both serialization and deserialization

Yeah I would say go for the first one. The problem is that then whenever the user opts for the second way the engine replaces it by the first one.
Maybe we should remove the logic for handling 'scopes' entirely, and just have everything inline as you suggested. What do you think?

[SrGesus]

Maybe we should remove the logic for handling 'scopes' entirely, and just have everything inline as you suggested. What do you think?

I think we should keep it since it's valid JSON and the performance impact on deserialisation is minimal since it should not run more than a couple times (if not just once on startup) and it might be easier for a user to write.