pyCraft
pyCraft copied to clipboard
DisconnectPacket not getting called on kick
/networking.packets.clientbound.play.DisconnectPacket sometimes doesnt get called when the server kicks you and instead only raises a python error, is this intentional?
Could you post the actual error to make it easier to debug the issue?
The errors are raised by the socket module really, heres one:
File "/python/lib/python3.8/site-packages/minecraft/networking/encryption.py", line 71, in read
return self.decryptor.update(self.actual_file_object.read(length))
File "/python/lib/python3.8/socket.py", line 669, in readinto
return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer
Could you explain what you were trying to do or did you use the default start.py?
Happens with me using start.py and me using my own code (not doing anything special really just reading chat and sending commands), but whenever any error gets raised like an EOFError: Unexpected end of message.
error or something like the one i sent before the DisconnectPacket doesnt get called
Can you post a repo for your code because other than the default start.py code, I don't know what you did with the chat code.
Also, have you tried running the code in debug mode?
Also, have you tried running the code in debug mode?
How do I enable it?
Can you post a repo for your code because other than the default start.py code, I don't know what you did with the chat code.
Nothing much, just ASCII and characters I know are allowed. I don't see why this is useful though, My problem is that DisconnectPacket doesn't get called on those types of errors, not with the errors themselves
Also, have you tried running the code in debug mode? How do I enable it?
python start.py -d It's part of the original options supplied in start.py. It will basically output a wall of text so linking a pastebin here can also help with debugging this issue.
My problem is that DisconnectPacket doesn't get called on those types of errors, not with the errors themselves
I usually like to cover my bases in a debugging issue. Even if you believe that it doesn't make a difference. It sounds like a raised condition with your early error message: "ConnectionResetError: [Errno 104] Connection reset by peer" is normally a polite way of a server slamming the phone down upon picking it up. The only time encryption.py is used in networks is for logins.
Are you trying to connect to 1.17 server because the current pycraft isn't updated to handle it. Try my repo
Also, are you on a Mojang or Microsoft account? Because, the current pycraft doesn't support Microsoft and my repo doesn't have Microsoft AUTH changes pushed on it just yet.
About the disconnect packet, the reason why I asked to see your code is because in the original pycraft; there is no registered packet listener that handles the disconnect packet.
Here is some code that might help with your issue:
disconnect_flag = False
def disconnect_function(disconnect_packet): #pycraft return field type CHAT as literal string but declared it as json_data
disconnect_flag = True
print(disconnect_packet.json_data)
....
connection.register_packet_listener(disconnect_function, clientbound.play.DisconnectPacket)
connection.connect()
while True:
if disconnect_flag: break #if you received disconnect packet you should break out of loop.
try:
text = input()
if text == "/respawn":
print("respawning...")
packet = serverbound.play.ClientStatusPacket()
packet.action_id = serverbound.play.ClientStatusPacket.RESPAWN
connection.write_packet(packet)
else:
packet = serverbound.play.ChatPacket()
packet.message = text
connection.write_packet(packet)
except KeyboardInterrupt:
print("Bye!")
sys.exit()
Thank you, also what im doing right now is
@connection.listener(clientbound.play.DisconnectPacket)
def reconnect_on_kick(disconnect_packet):
print("Disconnected.")
connection.disconnect()
connection.connect()
@AbdelrahmanMostafaSamy
/networking.packets.clientbound.play.DisconnectPacket sometimes doesnt get called when the server kicks you and instead only raises a python error, is this intentional?
Sometimes, the server may just drop the connection without attempting to send a Disconnect packet, or the connection may be closed before the Disconnect packet reaches the client. Unless you have reason to believe that the client is actually receiving a Disconnect packet and isn't triggering its handlers, I think this is working as intended. If you want to catch every instance of the connection being terminated, use the handle_exception
and handle_exit
parameters to Connection()
to handle erroneous and orderly disconnections, respectively.