The relations of TucoChat and TucoFlyer/Bot-Controller
This is my understanding for now.
Voting
The voting system is essential for TucoChat, while the code is actually in Bot-Controller.
The voting is made up of cycles with specifyable intervals. After every cycle ends, the flyer will move in the most popular direction in the cycle.
Vote values
Every cycle, the users are voting for directions that the bot will move in, like UP, DOWN, FORWARD, BACKWARD, LEFT and RIGHT.
The vote's syntax depends on the interface, and is not defined in the voting system. For example, in the Gitter and Twitch daemons, I use W to say FORWARD, but in the CLI's case, vote forward is the syntax for voting on FORWARD.
TucoChat interfaces
TucoChat is made up of daemons for every different platform of communication (like Twitch, Gitter, etc.), that's jobs are to send commands to Bot-Controller based on the input it gets.
There is also TucoChat-CLI, which is a CLI that directs commands from the command line to Bot-Controller.
TucoChat Daemon Commands
In the daemon, all the commands are coming from outside users, and they should not be treated as administrators (admin commands discussed later on).
Direction commands
Direction commands are votes casted for the gimbal to move in a specified direction in the current cycle.
In daemons for chat platforms (unlike letsrobot.tv), I used a WSAD mapping for the directions currently implemented. (The directions are currently missing UP and DOWN, which is necessary to implement later on.)
When a user types (ex.) W in chat, the bot calls the websocket to place a vote on FORWARD.
Special action commands
Special action commands happen instantly, but cost Tokens, and also have parameters, and cooldowns.
For example, special actions could be CV and gimbal based, instead of winch based. The testing action currently implemented in the daemons is LOOK <value>, which commands Bot-Controller to direct the camera at the specified object based on CV.
TucoChat CLI Commands
The TucoChat-CLI supports all the commands that daemons support (but with other syntax), and it has Admin commands.
Admin commands (Not discussed before)
Admin commands help the admin (you) moderate actions happening through the other daemons. For example, with admin commands, you can modify the cooldown of a specific special action, disable or enable voting, disable or enable the usage of special actions, and set the interval of the vote cycles.
Authentication
Daemon commands (votes & special actions)
Daemon commands do not require authentication, since they have to have safeguards built in to prevent damage from users through the daemon.
So if someone breaks into the LAN and finds Bot-Controller, but can't authenticate, they can't do physical damage to TucoFlyer.
Admin commands
Admin commands require authentication, since they control sensitive settings.
WebSocket commands
Vote commands
For voting, we'd need a websocket command that takes:
- a direction (UP/DOWN/LEFT/RIGHT/FORWARD/BACKWARD),
- a username, to prevent multiple voting in a cycle
- and the name of the daemon's platform, to prevent clashing usernames between platforms
Special action commands
For special actions, we'd need a websocket command that takes:
- an action type (LOOK, etc),
- action data (object to look at, etc.),
- a username, for checking if there are enough points for executing the action, and for checking cooldowns,
- and the name of the daemon's platform, to prevent clashing usernames between platforms
Admin commands
In my opinion, it would be logical to have admin commands seperated, instead of munching them into one websocket command and taking a command type and data.