I think this has been touched on before but didn’t seem to go anywhere, but is there any mileage in having a button combo to delete all the save files on the SD card?, thus restoring the saber to ‘factory’ defaults?
It occurred to me today that a useful button combo for this that doesn’t conflict with any other functions might be to hold the MAIN button while you boot the saber. This would prompt it to delete all the save files (global.ini, global.tmp, curstate.ini, curstate.tmp etc.), restoring the saber to the standard ‘factory’ defaults. The saber could then play a wav saying something like, “Factory settings restored. Please reboot your saber.” You would then re-insert the kill key or whatever, pull it again to boot a second time but without holding the button (i.e. boot normally), at which point it would write new save files based on the config defaults.
I think this would be useful, especially for presets using the infinite colour wheel , as it can be hard to go back to default colours or undo a change you don’t like with that setup.
You could have it available as a define along the lines of: #define RESTORE_DEFAULTS
So I guess the question is how hard would it be to implement?
I looked at it during Edit Mode development, the memory it would take up wasn’t worth it when a user could just delete the files from their SD for the same result.
Just delete the .ini and .tmp files from the root of the SD and the original config is used.
Ah OK. I didn’t realise there would be memory implications.
It would have been nice, but as you say it’s not a biggie, and certainly not worth sacrificing resources for.
I might be able to make a “reset to factory default” button in the proffieos workbench. Memory use would be fairly modest because some of the work would be in the javascript code.
It didn’t occur to me that it might suck up resources - I thought it would be four lines in a prop file telling the system to delete all temporary files on the SD card when a given button/boot action is applied, and that would be it. But if it was an optional define, at least people would have the choice of whether or not they wanted to take the memory hit.
What about just touching a bogus timestamp to the file so that next boot it wouldn’t be considered for use, and then just overwritten with the next save?
That would speed things up quite a bit, but it wouldn’t save flash memory, as we would need to add code to that. I think I already have an “rm” command that deletes a file, so I was thinking that the workbench could just use that. Although I might need a “reboot” command too.
