Roadmap for new branch "cloud"

[SuperRayss]

This branch is for developing a singular version of the bot, one that only requires one instance to control multiple servers. This requires the bot to read from server log files in a central directory for output to discord, as well as for the servers to read commands to ingest. Previously, each bot had its own installation, and had to be located on the same machine as the server, in order to read and write to the necessary files.

As of now, we have seq working to ingest logs from all servers simultaneously, filter out irrelevant events, and forward the resulting events to logs stored in centralized directory that can be (theoretically) read by one bot instance. I want to explore putting additional tags to the logs that signify to the bot which server wrote it, rather than the file name prefix notation I'm using now (which requires 1 log file per server).

The major challenge from this point is how to ingest commands to the game servers using our database system. I know that taking commands from discord and outputting them to another service with the Python bot is easy, and I just need to move that to its own feed, but how we go about having the server read from that feed is what we have to figure out now.

[SuperRayss]

As of the latest commit, we can ingest commands to the servers. However, there are a few functions that are not supported by the cloud version yet, which either have to be changed or discarded, mostly due to them requiring file system access:

• The >start and >stop (and >restart) commands actually starting/stopping the server process. It's unlikely this will ever be a function of the cloud version, but in the meantime, the functions have been changed to pass along commands that the server can execute that act as a "soft" network-based restart, "host 1" and "disconnect" respectively.

• The find_dll() function, and the conditionals to do with it, due to file access.

• The >mods command, due to file access, though this could likely be adopted into a convar for BotCommands to execute. Adding it to the todo.

• Having the bot respond with output from the server log when using a command like >give_item. This is due to the new log being tailed not containing any non-essential log output. This could be figured out in time.

• Installing BotCommands from the setup launcher (again, due to no file system access). For this reason, BotCommands has to be installed separately, which I kinda don't mind anyways, since it now requires several new assemblies for connection to seq net, among other things that make the setup more involved than what's possible with just setup.py.

• The config.ini now has separate server info stored sequentially, as in, for 2 separate servers, you have to have the config entered like:
  server-addresses: (SERVER 1 ADDRESS), (SERVER 2 ADDRESS)
  commands-channels: (SERVER 1 CHANNEL), (SERVER 2 CHANNEL)
  etc... If they failed to be entered in corresponding order, there would be an information mismatch, since each set of server info are now stored as dictionary objects, which are appended sequentially to a list for iterating through by other functions when matching the context of the channel in which a command was invoked. I want to make a config.ini that works to categorize the different servers without having to do this, to make it less messy, but this system does work for now. Further note, there still exists a hardcoded dictionary of server values in shared.channels, which can be deleted and their implementations changed to work with the system described above.

---

I've probably missed some things, but these are what I know of now. Testing on the latest version will reveal if there's any further work to be done.

[SuperRayss]

We did it!

No, the >mods command still doesn't work with cloud. One day.