hll_rcon_tool
hll_rcon_tool copied to clipboard
Expand Auto Settings
This is a big one so it'll be hard to review.
I didn't explicitly name all of the arguments for the set_
user config endpoints, I cheated and just passed **kwargs
straight through, so it won't auto expose the parameters, but it would have been dramatically more work to do so. If we're happy with all of these changes it wouldn't be hard to go back and explicitly define them later.
- Create a sub class of
Rcon
calledRconAPI
and moves almost all of the endpoints that were separately defined into it so that they are available to use with Auto Settings - Tweaks how we auto expose the
Rcon
(nowRconAPI
) endpoints to account for some edge cases - Standardizes some of the older endpoint names that didn't fit our current patterns (
do_blacklist_player
instead ofblacklist_player
) for instance- I kept the old endpoints for now, but would like to remove them in a few releases so we have less clutter
- Updates the UI to use the new endpoint names
- Updates the
get_api_documentation
endpoint to explicitly show which endpoints are usable with Auto Settings - Updates Auto Settings to allow partial updates for any
user config
settings, i.e. instead of passing the entireAutoModSeedingUserConfig
you can pass a single (or multiple) keys likeenabled
and it will merge them with the previous values - Adds some miscellaneous typing
- Removes some miscellaneous console log stuff that was in the UI
- Removes a couple of miscellaneous endpoints that weren't (or ever?) exposed so they weren't usable and weren't used by anything
- Update the discord audit function to allow optional escaping of markdown as it was escaping the automatically exposed
Rcon
endpoints - Updates
remove_flag
to allow removing a flag if a specific player has it (by the string value of the flag) instead of only supporting passing in the primary key of the flag recorsd - This carves out some exceptions to the
POST
andGET
requirements that were being done by endpoint name, for instance theget_recent_logs
endpoint has a lot of parameters and is traditionally passed via JSON
I believe (but I have not explicitly tested 100% of this manually) that I preserved the previous behaviors and argument names and I've been running this on our RCON for awhile now (two weeks maybe?) and have fixed all of the problems I've been able to find with it.
Old versus new API documentation: https://www.diffchecker.com/Km3MOLEV/