Macro-Ticket: Bugs to fix only at major release

[zeromus]

Due to backwards compatibility problems

• "Nintento" Config file has Nintendo spelled incorrectly in the Nintendo 64 Controller section #970 fixed in eb1d879 + cc4b12b
• Lua library function names / normalizing
• Change hooks to combined namespace e.g. "sysbus" read/write/execute to "sysbus.read"/"sysbus.write" etc.

[YoshiRulz]

I'm ashamed I forgot this until now, but we should be providing at least a checksum for each release, preferably signed. Despite OpenSSF Best Practices approving GitHub Releases for the MITM prevention criterion in the gold tier, it's far from a gold-standard solution.

---

On IRC I suggested to write the (most recent) release to config so later versions can warn the user about importing. edit: done in 8bb9cee + 56b9ec2

---

Rename settings called "Autoload" to either "Autoload with EmuHawk" (for tool windows) or "Autoload rom"/"Autoload watches"/"Autoload tasproj"/whatever (for everything else). edit: done in 7062ba5

---

from #1740: "[...] tell you which version [of EmuHawk] was used when you try to load the save state [made with an older version]" edit: calling this done with ee241dc

---

From #1719 (comment):

If there's a way to filter out PRs from the AppVeyor page, the readme needs to point there instead so that nobody downloads what is essentially an out-of-date build while thinking it's the latest.

edit: at some point AppVeyor was changed to only build master

edit edit: also it's barely useful anymore

---

Changing the Lua API at all—removing broken functions, fixing names, or especially changing behaviour without a rename—is a bad idea. We should do everything we can to freeze it until we've decided its fate, and then change it, all at once. Incremental changes without any backwards compatibility system irritates script authors at best, and forces them to use old BizHawk releases at worst.

edit: benched the .NET API overhaul for now

I believe that my .NET API overhaul which I'm planning for 2.6 (provisional version number) will be a good opportunity to overhaul Lua. Once I'm finished with that, we'll have five options for an overhaul:

1. reimplement the 2.4 Lua API with the 2.6 .NET API
2. change the Lua API to mirror the 2.6 .NET API (script authors would have a lot of work, but mirroring the .NET API means my backwards compatibility system would work for Lua scripts too)
3. change the Lua API to something completely different (again, script authors would have a lot of work; going with this over option 2 needs a good alternative to be proposed)
4. do both options 1 and 2; have a compatibility mode that replicates the functionality of the 2.4 Lua API as closely as possible
5. "Lua sux Python rulez"—replace the Lua Console with a Python/Ruby/whatever Console, then pick one of the first four options
6. drop Lua with no replacement and force everyone from casuals to Isotarge to use the .NET API

If we keep Lua around (options 1 through 3), we'll need to rewrite a large portion of our Lua code. With that in mind, we should consider starting from scratch with MoonSharp.

[YoshiRulz]

Is

Change hooks to combined namespace e.g. "sysbus" read/write/execute to "sysbus.read"/"sysbus.write" etc.

distinct from #759? This looks like you wanted a sysbus library like mainmemory. edit: Or is this moving the events to a new sysbus library?

edit: Nothing left here but "rename Lua functions", closing.