-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not all commands give a response & another EventEmitter memory leak #7
Comments
So I think this is still an issue. It's not because of just some commands not returning this, but more along the lines of what the server sends back. For example, I have two CS:GO servers. One hosted on a custom platform, one on DatHost. If I send
And here's the response from the server that I've been working on setting up:
It's missing that last line, and I'm still trying to figure out why, but is it possible that it is a server configuration issue as well? |
That is correct, since this is the workaround for valve not flagging answers with multiple packets in any way. |
Wouldn't it be possible to do much like they note in the Valve Dev Wiki and just send an empty response value right after you send your request? https://developer.valvesoftware.com/wiki/Source_RCON_Protocol#Multiple-packet_Responses Or is it not possible within the given implementation? |
As I added this part of the code, I can say it looked more elegant to me than the empty response workaround. But if this does not work in all cases, maybe this should be changed. |
Unfortunately it does not, since I have a handful of servers that seem to give that last line response as it's "end packet" :( It seems DatHost servers are very constant, but from a setup from a friend (on pterodactyl), and fhost, I found that the line that includes a timestamp happens less often than I've seen. |
As I just found out, the server cvar "sv_logecho" is responsible. If it is set to 1, the message is logged at the end of the transmission. So for now, this should be a workaround. |
This would also require E: Also, it appears that it isn't quite fixed, as calling certain things like |
I'm looking into why My initial thought was it just doesn't respond with anything, but the docs never mention that, rather "some commands may not respond", but |
When you execute According to Valve, |
To check for the success of a mapchange, I look for the following in the logs:
Until now, I did not find another way... |
Sadly, that requires listening to UDP logs created by the server, which is out of the library's scope. I had a look at how eBot (an old match manager for CS:GO running through rcon commands) handles map changes and it just sends a |
With the latest pullrequest, this should also be closable. |
It seems that only responses following this if-condition will return a message. This has some issues though:
Furthermore if you keep repeating the commands that don't respond, it will create a memory leak.
The text was updated successfully, but these errors were encountered: