Self-hosting support for $checkgraph and $checkcount using !status command - #60
Self-hosting support for $checkgraph and $checkcount using !status command#60barretg wants to merge 8 commits into
Conversation
Uses the status command output instead of the webhost for $checkcount and $checkgraph commands.
Quasky
left a comment
There was a problem hiding this comment.
Right now, Bridgeipelago handles requests/messages to the room via queues that ensures there is only one connection open to the room at a time.
Like done in the discordbridge_queue for messaging from Discord->AP.
I'd like to keep it within the same method/style for now and submit requests this way.
While I do spin up clients on the side (HintClient in particular), I'd like to keep that interaction to a minimum as to not spin up/down connections to AP willy-nilly.
The workflow should be something like: (D - DiscordClient, T - TrackerClient)
- Someone does a $checkcount
- D - Discord processes that message and submits a request to a queue (using discordbridge_queue or a new one)
- T - Every processing cycle, the tracker reads incoming messages from AP, then processes the additional queues (L311)
- T - If there is something in the queues, it'll executes the command and returns the results to the chat_queue (That needs renamed, since it does way more than just chat)
- D - Discord watches the chat_queue and matches for the message type, then formats/sends that data to discord.
I'd ideally like messages sent to Discord to be funneled in this manner. As it'll be the one 'central' location for that communication to cross from AP->Discord.
As I've been updating some of the older functions, I've been converting them to use this method of processing, and would like to continue that work.
However, with that being said..... with this entire project, I'm also super open to conversation about how I can better to do things. So I can be super persuaded to make a change to how the core functions.
| async def run(self): | ||
| _ConnectionString = str(self.server_uri) + ":" + str(self.port) | ||
| try: | ||
| async with websockets.connect(_ConnectionString, max_size=None) as websocket: |
There was a problem hiding this comment.
While I like the asyncio tie-in (I should REALLY convert to that at some point and ditch the multithreadding modules, ooof i gave myself a headache just thinking about it... ) it deviates from the script standard practice to submit a request to the TrackerClient via a queue for processing.
(tied to main comment)
| checks = (row.find_all('td')[4].text).strip() | ||
| percent = (row.find_all('td')[5].text).strip() | ||
| checkmessage += slot.ljust(SlotWidth) + " || " + game.ljust(GameWidth) + " || " + checks.ljust(ChecksWidth) + " || " + percent + "\n" | ||
| else: |
There was a problem hiding this comment.
Honestly, I really kinda hated querying the tracker page for this. I didn't know about !status when I wrote this initially, and your code for using status is probably the better way to go and ditch the webhost bits all-together for checkgraph and checkcount.
$hints will probably need to stay with the tracker page query (at least till I convert it to hit the API instead)
but then we go from checkgraph, checkcount, and hints being unavailable when local-hosting to just hints
So that's a net win.
I can make those changes after-the-fact, or you're more than free to totally ditch the if(SelfHostNoWeb==false) and use ONLY use your regex !status code.
…read to avoid issues when crossing process boundaries
|
Okay, made those changes- I ran into an issue with using the queues where, because the queues are on a different thread than the discord client, it'd hang on $hint, $checkcount, and $checkgraph, so that's whats up with passing all the queues as arguments. let me know if there was some other way I was meant to handle that. Thanks for the hard work, super useful project! |
|
oops that second commit was not supposed to be pushed to here, hang on |
|
Okay fixed and merged |
Uses the !status command output instead of the webhost for $checkcount and $checkgraph commands when self hosting. Web hosting logic remains unchanged.