WIP: Support connecting to LiveSplitOne

[AlexKnauth]

A Work-In-Progress implementation to connect to LiveSplitOne instead of LiveSplit, using a different server protocol.

As I'm working on this from both ends, it's possible some change on LiveSplit One's end triggers a need to change SplitGuides' end too, so this will remain a WIP / Draft PR until that stabilizes.

[DavidCEllis]

Is the Livesplit One websocket server different to the one they've added to regular livesplit?

I'd prefer if it was possible to avoid having this be a setting and just try both and see which connection succeeds, with one connection being preferred over the other. I haven't looked into how complex that would be though.

---

I'd rather not support Mac. Unless you know of a userbase that uses Livesplit One on MacOS and wants to use SplitGuides¹. I don't want to support it just because Livesplit One technically runs on Mac too.

Locally I can run both Windows and Linux, so I can investigate if something has gone wrong on either of those platforms. I don't currently own an ARM Mac - when something platform-specific doesn't work it's much more difficult for me to figure out what's going on.

Footnotes

1. I don't even know the userbase for SplitGuides other than a few souls runners. ↩

[AlexKnauth]

Is the Livesplit One websocket server different to the one they've added to regular livesplit?

Yes, it is different:

• The regular LiveSplit commands look like getsplitindex, and responses look like -1 or 5.
• But the LiveSplitOne commands look like { "command": "getCurrentState" }, and responses look like { "success": { "state": "NotRunning" } } or { "success": { "state": "Running", "index": 5 } }.

Unless you know of a userbase that uses Livesplit One on MacOS and wants to use SplitGuides.

The userbase I have in mind are mostly Hollow Knight runners, who currently use LiveSplit One for auto-splitting and loadless time on Mac and Linux. I don't know how many of them want to use SplitGuides though, and there are more HK runners on the Linux side than Mac.

The "Mac support" in this PR consists of just the small couple changes in the first commit, which I needed to get it to run on my Mac machine again, since I don't have a dedicated Linux machine. I can remove them from this PR at the end-stage if you want, and leave them only in a fork for my own use, but for now they're necessary for me to continue working on it.

[DavidCEllis]

Oh they added a new websocket server to regular livesplit, but kept the same old command logic? Ok... I guess.

---

I will accept don't deliberately fail on Mac over specifically supporting it. The previous lock behaviour was intentionally blocking MacOS resolution as it added a vast number of additional dependencies to the locking logic when I was trying to understand the full resolution.

I also don't think ~/.splitguides is the correct config location on MacOS¹.

See: #36

If that's fine, rebase on that and make this PR just about Livesplit One support.

Footnotes

1. Technically it's incorrect on linux, but existing installs would necessitate extra migration logic I don't want to add right now. ↩

[DavidCEllis]

Ok, the main change I'd like is to not have this be a setting at all. I think it's better for users if it can just figure out what they're using automatically.

I think this can be delegated to LivesplitLink. Give it the hostname and port and have it try both and pick one if there's a success.