Add the first of the SSE event broadcasting functionality as originally planned#144
Merged
Add the first of the SSE event broadcasting functionality as originally planned#144
Conversation
added 17 commits
April 28, 2024 18:54
…omments, fmt, clippy
Contributor
Author
|
ISSUES: Windows build fails due to: |
Bash-09
reviewed
Apr 30, 2024
Contributor
Bash-09
left a comment
There was a problem hiding this comment.
This is pretty cool so far, I hope we can get something using it soon.
Bash-09
reviewed
May 5, 2024
Contributor
Bash-09
left a comment
There was a problem hiding this comment.
Otherwise everything looks pretty good. I'll be happy to approve and merge once you fix up the conflicts and address the last little bit of feedback.
Contributor
|
Looks like you just need to run |
added 2 commits
May 27, 2024 15:27
…emselves after a VoteOptions event
Bash-09
reviewed
May 28, 2024
Bash-09
reviewed
May 28, 2024
added 2 commits
May 29, 2024 09:25
Bash-09
approved these changes
May 29, 2024
Bash-09
reviewed
May 29, 2024
| self.votes.insert(options.voteidx, values); | ||
|
|
||
| // Replay shunted messages if we have them. This ensures that we don't print VoteCast events for Vote we haven't seen the | ||
| // VoteOptions event for yet. Saves |
Bash-09
approved these changes
May 29, 2024
Contributor
Bash-09
left a comment
There was a problem hiding this comment.
Assuming from your testing it still all behaves as expected. I haven't had a chance to do any in-depth testing but I trust your judgement and as far as I can tell the code looks fine 👍
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Way back yonder when things were a lot simpler, we created the footings for SSE (Server-Sent Events) broadcasting, with the intention that this channel would be how the backend alerts the frontend to things, without the frontend have to poll for it. We uh, never used it.... UNTIL NOW
This is a simple implementation, but it lays a lot of ground work that would make copy pasting further SSE broadcasting quite the easier process.
We broadcast 3 subtypes of ConsoleOutput messages - ChatMessage events, Kill events, and DemoStop events. These are broadcast to subscribers as a JSON blob that looks something like the follow:
{ "type":"ChatMessage", "uuid":"c7bcd50a-6f5d-4a84-8fb7-01b906ed15b7", "time":"2024-04-29T11:59:56.979901203Z", "event": { "player_name":"Lilith", "steamid":"76561198071482715", "message":"this is for the haters" } } { "type":"PlayerKill", "uuid":"c486298d-155b-4ccc-9bbd-876e9e4802ac", "time":"2024-04-29T12:00:09.269070783Z", "event": { "killer_name":"WITCH", "killer_steamid":null, "victim_name":"Lilith", "victim_steamid":"76561198071482715", "weapon":"tf_projectile_rocket", "crit":false } } { "type":"VoteStarted", "content": { "count":2, "option_1":"ctf_doublecross", "option_2":"Extend current Map", "option_3":"", "option_4":"", "option_5":"", "voteidx":3 }, "time":"2024-04-30T09:37:06.325924920Z", "uuid":"f8b59643-1724-4f61-98c6-f59d54d70cb1" } { "type":"VoteCast", "content": { "voter":76561198071482715, "voter_name":"Lilith", "choice":"ctf_doublecross", "event": { "vote_option":0, "team":0, "entity_id":1, "voteidx":3 } }, "time":"2024-04-30T09:37:06.325977329Z", "uuid":"2f2123ff-b274-4b21-a6c0-6b2f710cd80f" }Note that in the above PlayerKill example, WITCH is a bot, and thus doesnt have a steamID (so null is perfectly expected).
The intention is to use this same framework to broadcast votes to the frontend so it can display votes, vote options, and who voted for what, etc etc.
Use cases for the current messages? Cute little pop ups in the corner or something that show these things, to display game state and also useful as a meter for whether or not the client is actually properly reading TF2 data. Also, its COOL.
The code is a bit messy, so please eat me alive. Thanks.
FOR TESTING
You can use the python package
requests-sseto subscribe to SSE endpoints and display messages as they come in. I have a short demo module (that is literally copy pasted sample code from the PyPI page for requests-sse, wrapped in a poetry project) that you can use: https://github.com/lili7h/http-sse-event-viewer