Closed Beider closed 4 years ago
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
The solution to this issue will be as follows:
Please fix #57 in the scope of this issue as well as they are related.
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.
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.