This is a bug fix release only.

* NVRAM was not actually saving data to the NVRAM file.

Sorry about that. I had changed NVRAM to do a delayed write (rather than write to file after every byte written) and forgot to add back the final save-to-file logic. So, NVRAM previously was simply not saving to disk!

By the way, I didn’t find the problem myself, I personally stick to save states and don’t really use the 3DO internal save data. This bug was reported by a chap called BryWI. I greatly appreciate the bug report! I think this goes to demonstrate how valuable feedback is in the alpha stage. So, if you are seeing issues, please let me know. Even the constant stream of “Crash and Burn doesn’t work” comments are at least informative!

I find myself unsure how well mixing save states and NVRAM use is going to function. The save states do not currently save the NVRAM data. Examples:

If you save state in a game that’s already loaded information from NVRAM, and then later you drop in a new copy of NVRAM that is different and hit “load state”, I’m concerned that the game might bomb out when it finds that the data isn’t what it just loaded. Games were most likely written to assume they’re the only ones that will be editing their NVRAM contents while the game is running.
If you save state while it’s loading or saving to NVRAM, that of course is just asking for trouble.
I am considering saving NVRAM data on a per-game basis and possibly even per-save-state, which I think would be pretty easy to understand and resolve a lot of potential issues. This would make Game Guru absolutely useless, though. So, I don’t think the books are closed on ideal NVRAM behavior yet. I would be interested to hear how well it currently works.