Waterbox cores can't create files anyways, and trying to send in ? might make MAME try to make the directory anyways (which crashes due to the syscall for that being unimplemented), while "" will not do that
Cleanup this code so it plays nicer with BizHawk's "run everything on the main thread" (+ WinForms not playing nice with async methods)
Resend any game session start / achievement unlocks / leaderboard triggers if they failed. Wait for all achievement unlocks and leaderboard triggers to finish on Dispose() (mostly for catching them when user closes BizHawk)
Update rcheevos to 10.7.0
This becomes mostly apparent in the PlayMovie dialog where one zstd instance is created for every single movie, churning significant amounts of memory even though zstd isn't even used
* Nes.Core now updates the DataBus in WriteMemory()
This will fix open bus execution following write instructions.
* Properly formatted changes in previous commit
I have addressed the requested changes.
This call in `ToolManager.Restart` was to set `[{Optional.Required}Service]`
props to `null`, but the tool form would get `Close`d immediately afterwards, so
it never gets the chance to hit the `null` path if one exists. However, some
tools are written as though they keep the stale value, for example attempting to
call a cleanup function on it in their `Closed` event handler. These will now
work as intended.
`[OptionalService]`s that can't be satisfied are set to `null` by
`ServiceInjector.UpdateServices`, so clearing those isn't necessary, and
`ClearServices` has no other usages.
* Use source generator for VersionInfo
* Remove leftover hacks
* Use same fallbacks as NixHawk when Git not available
---------
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
mame won't care too much about how good the dump is, but it will warn you in orange that emulation is imperfect, and in red if it's broken. we happen to use rom status icon to inform the user about multidisk bundle, so using it for mame info feels natural, because it directly affects what users can safely submit to tasvideos. we warn them about bad dumps because it's banned for pub, so it's similar here.
This had two issues. One, relative pathing with dlls is a no-go. Our hackery with changing cwd seems to confuse lua, and while it can find the dll, it fails to load as Windows (at least) does not consider cwd for loading up dlls it appears. Secondly, people using luasockets never actually loaded up the luasockets dll, rather we were bundling it ourselves. From history it seems this was due to our lua being compiled with CLR/.NET and that didn't play nice with exceptions? Doesn't seem to be an issue anymore, but we should probably still bundle luasockets for the time being given it used in many different projects which use the same script with multiple different emulators (thus our own sockets are simply not usable).
This reverts commit 007442773a.
fixes#3268 but unfixes #3053, which should instead be fixed by something that doesn't lead to breaking other things and the author of the "fix" giving up on the project
CasualPokePlayer