My wife came in at this point and asked me what I was doing, so I mentioned that I was working on autosave. She said:
"Oh good, but make it so that it doesn't overwrite the main save file, I hate it when games do that!"
Guess how my save function works! It can't save using any filename other than the universe's name, which happens to be the main save file.
The bulk of that work, then, was fixing that problem. The issue is that if I just tack '-autosave' on to the end of a universe's name and save it, that name persists. So the player, upon loading their autosave and autosaving /that/, gets a name like 'scenario-autosave-autosave.ksg' That would not do.
The save code now looks for two identifiers ('autosave' and 'quicksave'), strips them out, and then adds them back on if you are, in fact, quicksaving or autosaving. I also added in code to put the player's name into the filename as well, so more than one person can play per user account and not have their saves clobber each other. Now if only I could name the player.
I had some extra time, so I got #177 done. That was literally a two-line change, to make some of the editing field bigger. I had time left over.
So, why not, I figured I'd tackle another "easy" task: #160, backporting all the nifty changes to multi-line inputs to the old one-line input.
The plan was, make the one line input a subclass of the multiline, and disallow the creation of new lines. This was easy, but the line was still multi-enabled; it'd wrap if you put too much text in it.
Disabling wrapping was difficult - the MultiLineInput itself delegates the work to the MultiLineLabel. I ended up having to have my subclass override its parent's rendering code entirely (as that's where the wrapping happened), and then set a number of variables that the parent class expected that the rendering would set. It was a pain.
Oh well. At least no global variables have bitten me in the ass.
No comments:
Post a Comment