Active Member Klaus 158 Posted August 6, 2022 Active Member Share Posted August 6, 2022 (edited) Hello, my client is closing many times, mainly after a teleport or receiving a private message, when he clicks to open, the client is terminated. I don't have any new system related to packages with error, I've already checked variables and packages several times, compared with several other sources and I haven't had any success. I also searched and couldn't find anything about it. If anyone can help me, it doesn't have to be a fix, but where the problem is, I'd be very grateful. If need be, I'm willing to pay for the correction. Here are some logs I saved: Quote Phase Game does not handle this header (header: 81, last: 45, 81) 528 21:55:26441 :: Phase Game does not handle this header (header: 34, last: 114, 34) 0528 21:55:26780 :: Unknown packet header: 101, last: 114 34 0530 21:48:11876 :: Phase Game does not handle this header (header: 34, last: 3, 34) 0530 21:48:12275 :: Unprocessed packet header 32, state Game 0530 21:48:12666 :: Unknown packet header: 182, last: 34 32 0805 10:17:49861 :: Phase Game does not handle this header (header: 34, last: 171, 34) 0805 10:17:50149 :: Unknown packet header: 103, last: 34 46 Obs.: I even found some things of corrections etc, but without success. Edit: 34 is present in all errors basically, being the one that occurs most frequently (when receiving private message, pm) Anyway, thank you so much in advance! =D Edited August 6, 2022 by Klaus Link to comment Share on other sites More sharing options...
Premium WeedHex 635 Posted August 6, 2022 Premium Share Posted August 6, 2022 Is it happening on a release server with players or just in developing? Link to comment Share on other sites More sharing options...
Active Member Klaus 158 Posted August 6, 2022 Author Active Member Share Posted August 6, 2022 4 minutes ago, WeedHex said: Is it happening on a release server with players or just in developing? On both, but on the test server it is very rare, on the main server, with an average of 200 players, it happens on average 5/8 times a day, with at least 50% of players. 1 Link to comment Share on other sites More sharing options...
Active Member enzi 842 Posted August 10, 2022 Active Member Share Posted August 10, 2022 That is most common error when you are editing packet.h without really understanding what are you doing My advice for you is fully compare packet.h from binary+game they must be same.. check for duplicates, check if you dont have something // in game but dont in binary, check if every packet is defined in right way in (PythonNetworkStreamPhaseGame/Item.cpp) ex. if this packet in binary = 80 it has to be 80 in game too HEADER_CG_GUILD = 80, as last that = 80 must be unique so you cant use it for another packet, but be carefull there are 2 types of headers CG and GC (if you use 80 in CG packets you are free to use same number in GC but you cant use same number in 1 type of packets) ex. WRONG HEADER_CG_GUILD = 80, HEADER_CG_WHEEL_DESTINY = 80, I hope this will helps, if it dont, insert here your packet.h files I will look at it 1 Link to comment Share on other sites More sharing options...
Active Member Klaus 158 Posted November 18, 2022 Author Active Member Share Posted November 18, 2022 up! Update: When receiving a private message (whisper), the client randomly closes, if it is for an item with attributes/jewels, it seems to happen more frequently than just normal messages. Pay for help! Link to comment Share on other sites More sharing options...
Active Member iMerv3 768 Posted November 20, 2022 Active Member Share Posted November 20, 2022 On 8/10/2022 at 6:02 PM, enzi said: That is most common error when you are editing packet.h without really understanding what are you doing My advice for you is fully compare packet.h from binary+game they must be same.. check for duplicates, check if you dont have something // in game but dont in binary, check if every packet is defined in right way in (PythonNetworkStreamPhaseGame/Item.cpp) ex. if this packet in binary = 80 it has to be 80 in game too HEADER_CG_GUILD = 80, as last that = 80 must be unique so you cant use it for another packet, but be carefull there are 2 types of headers CG and GC (if you use 80 in CG packets you are free to use same number in GC but you cant use same number in 1 type of packets) ex. WRONG HEADER_CG_GUILD = 80, HEADER_CG_WHEEL_DESTINY = 80, I hope this will helps, if it dont, insert here your packet.h files I will look at it The compiler won't let u using the same number in a switch. The problem he have is a dynamic packet size mismatch. 1 Link to comment Share on other sites More sharing options...
Active Member Helia01 2134 Posted November 20, 2022 Active Member Share Posted November 20, 2022 (edited) If all packets between server and client are ok. This behavior may occur due to an attack on the server. In this case, phantom packet errors may occur. (usually this headache is created by _IMPROVED_PACKET_ENCRYPTION_) But you can't just turn off this function. We will have to rewrite some part of the code in order not to get buffer errors. If similar problems with packages occur on your local server, then this problem is precisely the difference between packages between the client and the server. Edited November 20, 2022 by Helia01 2 Link to comment Share on other sites More sharing options...
Developer Mitachi 1455 Posted November 20, 2022 Developer Share Posted November 20, 2022 Well, there are a few things to consider: If the error occurs every time you perform a certain action, the problem is definitely in the packet in question. If, on the other hand, it doesn't always happen but the package in question is always the same, skip to the part where I talk about the sequence system The packet header number itself isn't a problem, packets have their own cases in a switch, if the case has the same number, the compiler will warn you. It's not just the packet header number that's the problem, packages are literally typed structs, like this: /* We need to be sure that the data types used match */ // Server typedef struct SPacketGCTest { BYTE bHeader; WORD wSize; } TPacketGCTest; // Client typedef struct SPacketGCTest { BYTE bHeader; int wSize; // error, int <-> WORD are not the same. } TPacketGCTest; Usually the sequence system (or ENABLE_SEQUENCE_SYSTEM if you using martysama) corrects for differences in packet weights automatically but I don't like it to be honest, I don't find a valid use for it today, perhaps once it could have been useful. Honestly I turned it off, removing it I noticed less random crashes. TIP: If you have it enabled try disabling it, you will notice the error more easily. I have also disabled _IMPROVED_PACKET_ENCRYPTION_ in my mainline (and not, he didn't cause crashes or at least I didn't notice). But you have to change some things first, otherwise after some hours of activity you come across the sizebuffer error. PRO: More speed performance 34th packet are usually the HEADER_GC_WHISPER, do you have some custom system related? let me know. *ending* When it comes to mistakes of this kind, it is not black or white; there can be many reasons. I told you what I was going to do initially. This guide can certainly be useful to you: 1 2 1 Link to comment Share on other sites More sharing options...
Active Member Helia01 2134 Posted November 20, 2022 Active Member Share Posted November 20, 2022 3 hours ago, Mitachi said: Well, there are a few things to consider: If the error occurs every time you perform a certain action, the problem is definitely in the packet in question. If, on the other hand, it doesn't always happen but the package in question is always the same, skip to the part where I talk about the sequence system The packet header number itself isn't a problem, packets have their own cases in a switch, if the case has the same number, the compiler will warn you. It's not just the packet header number that's the problem, packages are literally typed structs, like this: /* We need to be sure that the data types used match */ // Server typedef struct SPacketGCTest { BYTE bHeader; WORD wSize; } TPacketGCTest; // Client typedef struct SPacketGCTest { BYTE bHeader; int wSize; // error, int <-> WORD are not the same. } TPacketGCTest; Usually the sequence system (or ENABLE_SEQUENCE_SYSTEM if you using martysama) corrects for differences in packet weights automatically but I don't like it to be honest, I don't find a valid use for it today, perhaps once it could have been useful. Honestly I turned it off, removing it I noticed less random crashes. TIP: If you have it enabled try disabling it, you will notice the error more easily. I have also disabled _IMPROVED_PACKET_ENCRYPTION_ in my mainline (and not, he didn't cause crashes or at least I didn't notice). But you have to change some things first, otherwise after some hours of activity you come across the sizebuffer error. PRO: More speed performance 34th packet are usually the HEADER_GC_WHISPER, do you have some custom system related? let me know. *ending* When it comes to mistakes of this kind, it is not black or white; there can be many reasons. I told you what I was going to do initially. This guide can certainly be useful to you: Maybe my answer looked terrible. Since I use a translator. Thank you for the detailed answer. I was too lazy to describe everything in such detail. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now