LATEST CHATTY HEADER
Subscribe to Shacknews Mercury starting at $1/month!
Chrome Shack Community Guidelines Chatty Search
Scroll down to join the conversation.
New to Shacknews? Signup for a Free Account
Already have an account? Login Now
Subscribe to Shacknews Mercury starting at $1/month!
Chrome Shack Community Guidelines Chatty Search
Scroll down to join the conversation.
TL;DR: Post your in-game name here if you want to play on Chicago 69
Thread Truncated. Click to see all 562 replies.
Helter Skelter Wrote:
-------
This is a snippet of conversation from one of the admins of the SA server re: their admin tools.
Question:
"I have a question.. are you directly manipulating the server with your Python script, by sending RCON commands through the CLI or something, or are you using an intermediate app such as Guardian or BFBC2CC?"
Answer:
"I have a daemon (written in twisted python) that connects (twice due to the shitty rcon implementation, 1 for events and 1 for commands) to the rcon/admin protocol port. It then exposes about 60% of the admin commands through XMLRPC so I can call it from TCL (for the IRC bot) and other various scripts (like kfs-settings)."
kfs-settings I believe refers to the webadmin portion of the app (only available to actual the actual server admins, general user input is through the IRC bot with it's status and pubbie kicking commands).
Also:
"It's still under active development. If there's a specific feature you've seen on KFS you'd like to see code for find me on IRC and I'll see if I can separate out the relevant files (hope you like python).
The mode switcher in particular (currently) relies on an internal daemon that performs bc2 admin protocol <-> xmlrpc protocol conversion. However it would be trivial to adapt it to a dedicated admin connection."
I may be able to snag the python code for at least some of this stuff from him, though as you see above, he mentions that it's very much a work in progress.
The mode switcher mentioned switches the server back and forth between Conquest and Rush after every round. Currently, this means that one team will always be the "attacking" team in Rush games since it doesn't go through the normal 2-round rotation since there's currently no way to get much in the way of useful information like player scores or the current round count. To wit:
"DICE doesn't tell us what round the game is in (or the ticket counts, or the player scores, or or or), until we get that exposed via the admin protocol there's no way to get this working any better than it is right now.
The script also can't tell _where_ in the maplist the game is. The only good way I've figured out where we could have the 2-3 rounds on each map would be to only switch at the end of the set of (rush|conquest), so you'd get 3 maps of proper 2-3 round play, followed by a single round on the last map."
But yeah, if you want some code samples or whatever, I can see what I can do about that, or maybe see if he's willing to talk to you or one of the more coding-happy admins directly about stuff. Let me know.
So I think we should start with someone who knows about python - I'll assist in any way I can but I am not a coder. Thanks in advance!
The post has been reported. Thank you!
You must be logged in to post.
You must be logged in to post.