Replacement for text commands

[Teifion]

One of the really big advantages of text commands has been how extensible they have been. SPADs and Teiserver have both been able to add new commands without requiring changes from Chobby et al.

I'd like to keep that flexibility but not use the chat for it. At it's simplest it might be a case we just have a mirror of the chat messages but for commands. That said, we could go as far as having extra functionality like command lookups, schemas etc on those that supply them and the server purely forward the info.

Thoughts?

@Jazcash

[Jazcash]

This kind of links in with beyond-all-reason/bar-lobby#188. Probably better to use this discussion to talk about it.

I completely agree we should avoid using ! or $ text chat style commands for interfacing with server/hosts.

I'm currently of the thought that anything the client can do should be a JSON network request, and it should be the lobby's job to provide a / command style interface for all or specific commands if that's a feature we want to provide.

If we decide go that route, we can add additional help information to commands in the schema generator such as title, description or examples that we could use to create an interface like Discord has for commands.

To continue with that linked discussion: I personally think we should implement a Discord-like command interface into the chat, with the understanding that the majority (if not all) functionality should be eventually implemented in the GUI in some way. This would allow us to progress in a more iterative manner, and would allow server devs to implement new commands and for them to be easily usable in the lobby without first needing full GUI implementation - and making everything possible via chat commands is also handy for devs and power users.

[Teifion]

I'm currently of the thought that anything the client can do should be a JSON network request, and it should be the lobby's job to provide a / command style interface for all or specific commands if that's a feature we want to provide.

Agreed. All commands should be a similar network structure but the interface is completely up to the application. Lobby host and Server can broadcast their commands and then the app works out how to show them.

If we decide go that route, we can add additional help information to commands in the schema generator such as title, description or examples that we could use to create an interface like Discord has for commands.

This is exactly what I had in mind when I said about schemas but I didn't want to limit your ideas if you had others.

To continue with that linked discussion: I personally think we should implement a Discord-like command interface into the chat, with the understanding that the majority (if not all) functionality should be eventually implemented in the GUI in some way.

I think having a combination of / with a popup command interface and GUI is the best solution, as you said it's very extensible but it's also useful for power users and more admin-type stuff.

[Teifion]

So broadly speaking I'm thinking we'd want:

• Send data message
• Receive data message
• Request data message schemas

[Jazcash]

I don't think any additional work is required to support this discord-style command functionality. The JSONSchema already defines commands, their arguments and their schema and the lobby will have access to this.

[Teifion]

So lets say there's a lobby host which defines new command, how does the application know that?

[Jazcash]

Well if we're talking autohosts then I'm gonna assume we don't mean SPADS, because SPADS doesn't support Tachyon and doesn't plan to support Tachyon afaik. For a new Tachyon-based autohost client, I would expect that to define its own command schema for how clients can interact with it, ideally in JSONSchema also. I think those commands should bypass the master server entirely and isn't something this protocol should be concerned with.

Otherwise if you think the master server should broker the command interface between clients <-> autohost, then maybe we should define those here as part of Tachyon?

[Teifion]

Yes, they should bypass the server in terms of functionality but they still need to go via the server in terms of communication (similar to SPADS commands). Additionally we may have multiple versions of autohost as we try out features etc so allowing providers of commands to have a way for applications to query them would be a good idea.

I think we should define a set of commands (like above) that facilitate that communication and allow for rules/definitions to be defined but for the server to only enforce the protocol itself, not the commands.