-
Notifications
You must be signed in to change notification settings - Fork 71
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
messages.BrokenMessageError: Invalid value (65) for field 'response_type' #48
Comments
May I inquire as to what kind of server we are talking about here? TF2, CSGO, etc.. Also, is your workaround checked in anywhere so I could take a look at it? 👍 |
I got this issue with server query example from https://github.com/serverstf/python-valve page. |
I got the same exception when doing rules or player server query against Foxhole server (Unreal based game). Info works fine. When I modified messages.py to accept the 65 number number, I got following exception: Server IP and Port in question is: 144.217.11.227:27015 |
Adding a retry loop seems to indeed fix the problem and matches what the Steam client does. It's still not perfectly reliable, so whoever wrote the server code should definitely fix that. I also need to do some more testing before pushing this change. |
Getting same issue ... |
I am getting this error also on 2 Rust servers. 139.99.144.99:28015
|
Support for retries has been added to python-a2s |
THANK YOU, you saved all my project |
valve.source.messages.BrokenMessageError: Invalid value (109) for field 'response_type' |
Anytime i try to get the rules for a server i receive this error, all the others (info, players, ping, etc) work fine, but rules always fails with the same error for all servers.
Anyone have any clues?
Edit:
So I don't know why but the game I'm using this with will sometimes reply with another challenge number after sending the previous received challenge number, instead of the rules. The challenge number sometimes is the same and sometimes it's a different one.
For now I've "fixed it" by modifying messages-RulesResponse.decode to check if the response is a challenge response (x41), process the packet through RulesRequest instead, and then in a2s -ServerQuerier - rules added a loop sending another RulesRequest with the new challenge number until the response is an actual rules response (x45)
Probably not the right way to do it?
The text was updated successfully, but these errors were encountered: