The masterbase module has a few convenience functions and structus for managing connections with the masterbase. Most of the meat happens in demo.rs where the DemoManager has been reworked to run in the event loop as a handler. From there it waits for DemoBytes messages from the DemoWatcher source, and when it receives these messages it appends them to the current demo being watched and parses them out, and also handles connections with the masterbase.
In the settings, there is now the masterbase_host field which can specify an address or port to find the masterbase at (e.g. masterbase.chs.gg or whatever it's going to be, or 127.0.0.1:8001 for local testing). Connections to the masterbase will enforce https unless the --masterbase-http flag is given when the app is launched.
There's also a couple other flags that can be given to the app at startup:
--minimal-demo-parsing - Will only parse out the first chunk of the demo to get the header, then not parse the packets out of the later chunks. I think the chunks are small enough that there's probably not any noticeable performance difference whether or not the chunks are parsed out, but the option is there if potato PCs notice a difference. Since the packets aren't really used for anything atm it doesn't really affect anything else though.
--dont-parse-demos - Disables demo parsing entirely. Same as above, but it won't even parse the first chunk for the header, meaning it can't be uploaded to the masterbase either (since we rely on the headers of the demo for IP and map, as we can't really guarantee the internal server state from rcon is fully up to date)
--dont-upload-demos - Demos are still parsed, they just aren't sent to the masterbase
Perhaps a number of these could be persistent settings instead, but I didn't think too hard about it. Having them available as launch args is good enough for now.
The
masterbase
module has a few convenience functions and structus for managing connections with the masterbase. Most of the meat happens indemo.rs
where theDemoManager
has been reworked to run in the event loop as a handler. From there it waits forDemoBytes
messages from theDemoWatcher
source, and when it receives these messages it appends them to the current demo being watched and parses them out, and also handles connections with the masterbase.In the settings, there is now the
masterbase_host
field which can specify an address or port to find the masterbase at (e.g.masterbase.chs.gg
or whatever it's going to be, or127.0.0.1:8001
for local testing). Connections to the masterbase will enforce https unless the--masterbase-http
flag is given when the app is launched.There's also a couple other flags that can be given to the app at startup:
--minimal-demo-parsing
- Will only parse out the first chunk of the demo to get the header, then not parse the packets out of the later chunks. I think the chunks are small enough that there's probably not any noticeable performance difference whether or not the chunks are parsed out, but the option is there if potato PCs notice a difference. Since the packets aren't really used for anything atm it doesn't really affect anything else though.--dont-parse-demos
- Disables demo parsing entirely. Same as above, but it won't even parse the first chunk for the header, meaning it can't be uploaded to the masterbase either (since we rely on the headers of the demo for IP and map, as we can't really guarantee the internal server state from rcon is fully up to date)--dont-upload-demos
- Demos are still parsed, they just aren't sent to the masterbasePerhaps a number of these could be persistent settings instead, but I didn't think too hard about it. Having them available as launch args is good enough for now.