The current code breaks down currently for some NANDs (in particular Chinese and Korean NANDs) due to making some faulty assumptions. Instead of adding more code to handle these edge cases, I'm just opting to reduce the "Clear NAND" transfer to only the minimum core apps (System Menu, System Settings, and the various non-executable data files). With 51d92d328e (and later commits) if the user really wants to use these "fun" system apps for a movie (where Clear NAND is forced) they can do so by directly loading them as ROMs.
This takes a more sledgehammer approach, as it seems even tiny minor difference in the NAND structure can cause sync issues. This is even the case if the entire directory tree and every file is identical (I guess order of files internally matters here or whatever). The entire partition will be recreated here with files manually readded as to minimize NAND differences (assuming system files are the same version anyways)
The value will now be passed to the frontend for read callbacks and both read and write callbacks' values can now be changed in the callback.
execute would probably be possible but would require some additional code changes which I'm not sure about
I was unable to make it launch with full vision on the very first frame unless it's set during init. which means there will be savestate problems if we allow switching this on the fly. setting it on init only is probably fine too.
initially I read the code wrong. `demo_compatibility` means vanilla complevel, not "demo is running". for vanilla hitting 1 would switch to first only if you have berserk, otherwise it'd stick to chainsaw (provided you have it of course). that part was working ok. but for boom compat hitting 1 swaps fist and chainsaw at all times, and that part was broken: chainsaw would not get selected even if you have it.
pass button values directly (same can be done for arti)
note on using PALETTE_SIZE as offset. normally it's `256 colors * 3 bytes per color = 768`, but in our headless mode it's 256. upstream does `SDL_SetPaletteColors(screen->format->palette, playpal_data->colours + 256 * pal, 0, 256);` when palette is updated, so clearly it means offsetting by 256 colors=bytes. but PALETTE_SIZE I used as my offset is not for stuff upstream uses it for. just something better than a magic number.
* new callback system with callback return values
If the lua callback returns a value, the core will update the addr with it. Otherwise, the old value sent by the core will be used unmodified
* update MemoryCallbackDelegate return value to uint?
* throw NotSupportedException for GBA memory callbacks
* docs: return value of MemoryCallbackDelegate and CallMemoryCallbacks
user will be changing those options from hawk side dialog so it's impossible to miss what you're changing (you can look at the dialog again if you're THAT sloppy)
but since we're now initializing with default nonsync settings and changing them on the fly, those UI messages would be appearing all the time
automap messages are left intact since they appear upon in-game button press
worst case scenario, UI messages are moved to hawk side, but then why limit them to only whatever upstream reports and not report every change? which is never done anyway, so I doubt it'd come to this
passing rngseed didn't fix sync, and passing all the settings is too much work for this release. will support it afterwards.
instead just tell the user BOOM demos are not supported
CasualPokePlayer