BizHawkClient: Add BizHawkClient

[Zunawe]

What is this fixing or adding?

Adds a generic client that can communicate with BizHawk. Similar to SNIClient, but for arbitrary systems and doesn't have an intermediary application like SNI. An example implementation of a client for Pokemon Emerald can be found here. It has a block of code at the top related to importing the client as an apworld, but that's not necessary during development. See the Discord thread for more info.

From what I can tell, this is at least as stable as (and often more stable than) any existing BizHawk client/connector when it comes to setup. Switching ROMs, pausing emulation, starting the script before loading a ROM, and closing and reopening the script or client can cause problems in existing scripts, but recover here.

Merging this doesn't require any specific clients to migrate, but obviously there may be some initial confusion among players about which games can and can't use this.

How was this tested?

Integrating Pokemon Emerald and running a couple beta tests. Emerald doesn't need every function, and is the only integrated client on the test branch, so some behaviors were only tested in development.

No currently merged games have been migrated and tested, but I paid attention to their existing Lua scripts to try to cover necessary functionality.

[beauxq]

I would prefer to see a python bizhawk communication library that is separate from any of the AP client application stuff.
It would have nothing from CommonClient, nothing from kivy, etc. - just the communication with bizhawk and nothing else.
I imagine code like this:

system = await bizhawk.get_system()
await bizhawk.set_message_interval(2)
result = await bizhawk.read(read_list)

So this could be used with any python client, and a BizHawkClient could be made separately to use this.

It seems like being forced into BizHawkClient would make it more difficult/messy to support non-bizhawk systems,
whereas a bizhawk communication library could more easily be mixed with non-bizhawk systems.

[Alchav]

Pokémon Red and Blue can be run on two different systems: GB and SGB. I need to be able to register my game with either of those two systems being reported

[Zunawe]

Hmm. Edge cases all the way down. I can make it a Union[str, List[str]] and just add duplicate references I suppose. And you can detect the system through the async BizHawk functions if you need to. I'll take a closer look tomorrow.

[Alchav]

This is something that will affect all Gameboy games, and is likely a situation unique to Gameboy games, so perhaps just looking for GB system client handlers when SGB is reported would be a good solution?

[Zunawe]

I'm thinking about, like, GBA in NDS, or someone going crazy and implementing a client that works for one game ported to two systems like Twilight Princess (but something on BizHawk supported systems).

Changed in d706c3f. You can now specify either a str or a tuple[str, ...]. So in this case ("GB", "SGB"). I'd rather have it explicit for all multi-system games instead of implicitly allowing certain systems to mix just in case there's ever a difference.

[Alchav]

In my attempt to get started on adding Pokémon Red and Blue to this, I ran into this when calling read in validate_rom to check the rom name:

  File "C:\src\Archipelago\worlds\_bizhawk\__init__.py", line 278, in read
    return await guarded_read(ctx, read_list, [])
  File "C:\src\Archipelago\worlds\_bizhawk\__init__.py", line 243, in guarded_read
    res = await send_requests(ctx, [{
  File "C:\src\Archipelago\worlds\_bizhawk\__init__.py", line 108, in send_requests
    if ctx.streams is None:
AttributeError: 'BizHawkClientContext' object has no attribute 'streams'

[Zunawe]

This was a recent change related to beauxq's comment that had discussion in Discord.

read doesn't take an instance of BizHawkClientContext, it takes an instance of BizHawkContext. So you should be doing bizhawk.read(ctx.bizhawk_ctx, [])

---

To more fully explain the changes made, since there's no record of the discussion here except the commits,

The functions related to talking directly to the connector script were split into worlds/_bizhawk/__init__.py. Those are the functions like bizhawk_read, which became read, bizhawk_set_message_interval became set_message_interval, etc... The client superclass and metaclass are in worlds/_bizhawk/client.py. And the context and code required to run the client are in worlds/_bizhawk/context.py.

So it should now be possible to import just the functions to talk to BizHawk. I'll update the link in the original message for the example client just after I post this.

[Zunawe]

Considering even I managed to forget to use ctx.bizhawk_ctx instead of just ctx, I'd be open to suggestions for clearer names.