Invalid player name/game in SNIClient under specific circumstances about archipelago HOT 4 CLOSED

Thanks for finding this, wuffie!

Analysis

Did some quick poking around. SNIClient selection among multiple devices is broken.

After adding a local log statement in snes_connect() (lines starting with devices[0] or [1]):

Connecting to SNI at ws://localhost:8080 ...
devices[0] = ra://127.0.0.1:5000
devices[1] = ra://127.0.0.1:6000
Found 2 SNES devices. Connect to one with /snes <address> <device number>. For example /snes localhost:8080 1
1: ra://127.0.0.1:5000
2: ra://127.0.0.1:6000

So far so good. But then when the user selects device N (array index N-1), SNIClient calls its snes_connect() function again, this time with the user's numerical choice (1 or 2). But SNI returns the devices in a different order:

devices[0] = ra://127.0.0.1:6000
devices[1] = ra://127.0.0.1:5000

SNIClient snes_connect() proceeds with the index it was given and ends up choosing the device the user didn't want to connect to. This reversal happens very often.

Additional difficulties

SNES takes precedence over LUA emulators

If SNI is started by SNIClient, as is typical, if a connected SNES (FxPak Pro) or RetroArch (emulator) is running a multiworld ROM, that ROM will take precedence over the user connecting SNIClient to a LUA-based emulator. This happens because the LUA script doesn't work until SNI (and therefore at least 1 SNIClient) is already running. So SNIClient's auto-connect behavior will connect to the wrong device. This means these steps should somehow work intuitively (hard to tell with the above bug):

1. Run SNIClient (thus SNI starts)
2. (SNIClient automatically connects to a SNES, if this design is kept)
3. Run LUA script in emulator so SNI sees emulator
4. Must be able to intuitively connect SNIClient to LUA emulator at this point. (But how? Current SNIClient might not listen for new SNI devices at this point)

from archipelago.

SNI treats device URIs as unique, and that's the extent of it. Order of devices in the detection response is not guaranteed.

It wouldn't make much sense to try to do so anyway since the device URIs can change between detections, devices can go missing or new ones pop up. So even if it were ordered somehow, it wouldn't solve the problem where SNIClient is using once-established device indexes and assuming those stick around for a long time, which there's no guarantee they do.

from archipelago.

SNI treats device URIs as unique, and that's the extent of it. Order of devices in the detection response is not guaranteed.

It wouldn't make much sense to try to do so anyway since the device URIs can change between detections, devices can go missing or new ones pop up. So even if it were ordered somehow, it wouldn't solve the problem where SNIClient is using once-established device indexes and assuming those stick around for a long time, which there's no guarantee they do.

We only retain it between offering the user a choice and getting the choice. This was consistent on qusb2snes, but with #624 this should now be guaranteed client-side.

from archipelago.

Solved in #624.

from archipelago.