Add command line args for playing #2

Coso commented 2025年11月29日 09:38:35 +01:00

This would avoid having to manually click "Play" when opening the launcher from Lutris and Steam

E.s. bolt-launcher --play osrs --client rl --character Nix

Or maybe add defaults in the settings and just set --play osrs

This would avoid having to manually click "Play" when opening the launcher from Lutris and Steam E.s. `bolt-launcher --play osrs --client rl --character Nix` Or maybe add defaults in the settings and just set `--play osrs`

Adamcake commented 2025年11月29日 16:06:38 +01:00

This has been a long-requested feature, but it'd be tricky to get right.

I'd still need to open the UI but without showing it to the user, since all the logic for refreshing oauth2 tokens and downloading game updates is in the frontend which is javascript. So there'd need to be a way of preventing Show() from being called, and subsequently we'd need to absolutely guarantee that the UI will self-close within a reasonable amount of time instead of staying hidden forever.

I'd also need to add a way for the frontend to print messages to stderr in the event that the command is incorrect, or download failed, login expired, etc... as otherwise the game just wouldn't open, and the user wouldn't know why.

If bolt is already running, running it again usually sends a message to the original process to re-open the UI, or focus it if it's already open. This introduces a lot of new cases which would need to be handled and tested:

• what happens if bolt is already running, the UI is/isn't currently open, and you run a --play command, and the command is/isn't successful?
• what happens if bolt is currently in the middle of running a --play command, so the UI is open but invisible, and another bolt command gets executed during that process? And each of those two commands is/isn't successful?
• etc?

tldr, I do intend to do this but it's a lot bigger of a request than you'd initially think.

This has been a long-requested feature, but it'd be tricky to get right. I'd still need to open the UI but without showing it to the user, since all the logic for refreshing oauth2 tokens and downloading game updates is in the frontend which is javascript. So there'd need to be a way of preventing `Show()` from being called, and subsequently we'd need to absolutely guarantee that the UI will self-close within a reasonable amount of time instead of staying hidden forever. I'd also need to add a way for the frontend to print messages to stderr in the event that the command is incorrect, or download failed, login expired, etc... as otherwise the game just wouldn't open, and the user wouldn't know why. If bolt is already running, running it again usually sends a message to the original process to re-open the UI, or focus it if it's already open. This introduces a lot of new cases which would need to be handled and tested: - what happens if bolt is already running, the UI is/isn't currently open, and you run a `--play` command, and the command is/isn't successful? - what happens if bolt is currently in the middle of running a `--play` command, so the UI is open but invisible, and another bolt command gets executed during that process? And each of those two commands is/isn't successful? - etc? tldr, I do intend to do this but it's a lot bigger of a request than you'd initially think.

SMG commented 2026年02月15日 08:28:14 +01:00

it's a lot bigger of a request than you'd initially think - it is.

If you haven't already started work on this, I have fully coded the issue Coso has raised with a few different implementations for as much support as possible.

> it's a lot bigger of a request than you'd initially think - it is. If you haven't already started work on this, I have fully coded the issue Coso has raised with a few different implementations for as much support as possible.