Properties file for static configuration instead of virtual methods?

[Beider]

I went through and compiled a list of all virtual methods that are used for settings because I plan to add them to the readme when I add the MDGameSynchronizer stuff.

MDGameInstance
    GetGameSessionType() -> Return the type for MDGameSession
    GetGameSynchronizerType() -> Return the type for MDGameSynchronizer
    GetPlayerInfoType() -> Return the type for MDPlayerInfo
*   IsConsoleAvailable() -> Returns if console is available (Default: Only in debug mode)
*   UseUPNP() -> Returns if UPNP should be used (Default: True)
*   RequireAutoRegister() -> Returns if MDAutoRegister is required (Default: False)
*   GetConsoleKey() -> Returns the console key (Default: QuoteLeft)
*   UseGameSynchronizer() -> Decides if the network synchronizer is used or not (Default: True)
*   GetLogDirectory() -> Get the log output directory (Default: user://logs/)

MDGameSession
!   UseSceneBuffer() -> If true we will keep a reference to all loaded scenes around so we don't need to load the resource from disc every time

MDGameSynchronizer
*    IsPauseOnJoin() -> Pauses the game for synching on player join (Default: True)
*    GetUnpauseCountdownDurationMSec() -> Unpause countdown duration (Default: 2 seconds)
*    GetPingInterval() -> How often do we ping each client (Default: Every second)
*    GetPingsToKeepForAverage() -> Pings to keep for getting average (Default: 10)
*    IsActivePingEnabled() -> If set to true we will ping every player continuously. (Default: true)
*    GetInitialMeasurementCount() -> This decides how many times we go back and forth to establish the OS.GetTicksMsec offset for each client (Default: 20)    

I looked at the different virtuals in there and a lot of them really should not change durting runtime (Marked with *). As such I wondered if it would be an idea to move such settings into a properties file instead. I think this would make it easier to do configurations and it would reduce amount of code as the amount of properties grow.

Optionally we could also load it from a properties file and give access to changing properties by name during runtime. That way you could toggle things from code, maybe something like

this.ModifyMDFrameworkProperty("UseUPNP", false);

An additional benefit here is that you can create different property files for your different builds. We could do a virtual GetPropertiesFilePath that would by default provide a different file for debug/release builds.

Scene Buffer The first thing I noticed is that the MDGameSession.UseSceneBuffer() should probably move over to MDGameInstance to ensure you only need to override one class for configuration.

Secondly I am not sure if the solution for this one would be to provide the path to the scene in the virtual method. Then you can decide if scene buffer should be used on a scene by scene basis. The only thing I see as a problem here is that doing string compares during runtime is not exactly fast.

[DoubleDeez]

Yeah I was thinking we could use a config file instead of all the virtual methods, but the nice thing about the methods is they allow logic so I was torn on it. Maybe we can think of a way to allow both?

First if the method is overridden it should use the override, otherwise if the value exists in a config file it should use that, otherwise it should use whatever default is in the framework code.

I think moving UseSceneBuffer() to the GameInstance is a good idea. Also adding the path as an argument is good too, it would just be ignore by default.

https://docs.godotengine.org/en/3.2/classes/class_configfile.html

[Beider]

The solution to this issue will be as follows:

• Implement a static class MDConfiguration that reads a config file.
• This MDConfiguration should contain all the default settings currently in the virtual methods, if the setting is not found in the config file it should use that.
• Replace the content of the current virtual methods with a call to MDConfiguration to get the value.

[Beider]

Please fix #57 in the scope of this issue as well as they are related.