User Config Refactor: Planning

Thinking Ahead

After yesterday's session I had an idea of what I needed to work on today, but not much more than that. So, I had to dissect the actual issues, figure out what needs to be refactored, and plan the best path to do that. To do that, I needed to dig into the code that is already established. So I fed my scripts into Gemini to help me identify the best approach, which kinda made my head spin a little. It did help me get an idea of the best practices for what I wanted to accomplish.

The idea is to move all the functionality surrounding the ConfigFile, reading and writing, out of my other scripts and centralize it in one place, my savegame manager. This means adding whole new functions to get and set my config as well as actually save the data to disk. So, that's where I started, a detailed discussion about what needed to happen in the savegame manager to prepare for the updates to the other scripts. 

The first couple of changes were quick and easy to determine. I needed to centralize my ConfigFile object via a class variable, then create a new function to load the data which is called from ready in my savegame manager. Of course, this then lead me to start thinking about how and when to save the settings. My initial thought was to just force a save every time a setting was changed, but the AI pointed out this may lead to excessive disk I/O by trying to save every frame inadvertently. 

It was at that point that an idea occurred to me, a simple boolean variable to denote that settings have been updated but not saved. Then hook into the game manager's state change signal. That way, when it fires, if the boolean is true, I can just force the save then. Of course, I'll still need to force a save when the player's game is saved too (a small portion of the player's game data is held in the user config surrounding the actual game save data). 

So, after further discussion with Gemini, I began implementing the new functionality. I added my new class variable along with a variable to denote unsaved settings. I added the new functions, one to load the settings, two more to get and set individual settings, and another one to save them to disk. Once that was done, I had to add a call to the load function in ready. 

Next Time

That was about all the bandwidth I had for today though. Nothing I did should impact the existing functionality at this time (not that it matters much) so it felt like a good stopping point. Tomorrow I'll be back for more. At the very least I should get the rest of the changes done to my savegame manager, but hopefully I'll get the rest of the refactor done. Once everything in the savegame manager is completed, the rest of the changes shouldn't be too difficult since it's mostly small modifications to some statements with complete erasure of others. Even though I'm only partially through the refactor I have a good understanding of what needs to be done next, so it shouldn't be a big deal to accomplish.