Support for Query Protocol #150
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "Query"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I finally did it. I tested it with my own test http://pastebin.com/SQ7TekwR
Actually, because I had to rewrite it after first accidentally deleting all my work, I forgot something and going to fix it.
Looks good for the most part, just a few corrections and I'll get this merged up.
Ok, I'll fix all of it. One thing though, when I tried setting the port to 26556 it simply didn't work.
25565, and how so?
Sorry, 25565. I don't know how. But apparently I was receiving ICMP host unreachable via a SocketException. I'll try it again.
Okay. If you can't figure it out, we can merge with 25566 and look into it later.
FIY the build failed in the TrueCraft.Client, because of some other commit. It's a property which needs to have both
{get; set;}
not just get.I'll get this merged as soon as I fix some other things.
That, or mark the property as abstract, not virtual.
That's not why the build failed. Don't worry about it, I'm on top of it.
@manio143 I tested this on localhost and it does not seem to work. The reason why isn't immediately obvious to me. I used Dinnerbone's mcstatus to test it.
Ok, I'm working on that. With one thing to have in mind: only
MinecraftServer.query
from mcstatus applies here.Yep, that's what I used.
I think I found the problem. Python is sending the challenge token (and other int as well) as LittleEndian. Which is wrong since we expect BigEndian. Weird thing is though, it works with some old Minecraft server (12w2 or something like that).
I'd say that Dinnerbone's implementation is effectively the reference implementation.
Yes, but in his script I set sessionId to 1, and in truecraft, when debugging, I get 16777216, so clearly something is wrong.
Maybe I shouldn't be processing those high bits, I don't know.
Yeah, that's just the endianness being wrong. Reverse the endianness of 16777216 and you get 1.
But then won't I be using Little Endian, which is against the specification?
The "spec" was authored by the community through reverse engineering. If it's wrong in practice, then go with the practical spec.
Alright, will do.
It shouldn't matter anyway, though. Whatever endianness you read, so long as you write it back in the same endianness, in theory won't case any side effects on the client.
You just have to be consistent with your endianness.
The thing is, the script reads big endian and send little endian which is confusing.
That's weird.
Ok, I fixed it all. I added a new commit to the same branch. Do I have to open another pull request?
Yep.