There seems to be another netcode bug its causing bogus data to be read in and the server goes screwy :
12:23:04 E World : Unknown id of 747080834 when looting!
12:23:04 E Recipe : Recipe (3452816845) not found in TradeskillMgr::BeginCrafting()
12:23:04 E World : Invalid ZoneAuthRequest, disconnecting client.
This seems repeatable (triggers loot and some other things, but always sends a ZAR), but unpredictable.
Split this issue in two
http://cutpon.com:3000/devn00b/EQ2EMu/issues/85 -- handles server->client desync
http://cutpon.com:3000/devn00b/EQ2EMu/issues/61 -- handles client->server desync
There seems to be another netcode bug its causing bogus data to be read in and the server goes screwy :
12:23:04 E World : Unknown id of 747080834 when looting!
12:23:04 E Recipe : Recipe (3452816845) not found in TradeskillMgr::BeginCrafting()
12:23:04 E World : Invalid ZoneAuthRequest, disconnecting client.
This seems repeatable (triggers loot and some other things, but always sends a ZAR), but unpredictable.
foof brought to my attention that the OP_Combined code tries for an overloaded size when it only supports max of 0xFF. This change needed to be reflected on the code for both reading input from client and output to the client.
In the case of input for the client we tried overloading if 0xFF was present, this is only possible for an OP_AppCombined. OP_Combined will max at 0xFF (that is the value sent)
These combined packets are likely the cause of the incorrect client/server communication such as seen on zone in.
foof brought to my attention that the OP_Combined code tries for an overloaded size when it only supports max of 0xFF. This change needed to be reflected on the code for both reading input from client and output to the client.
In the case of input for the client we tried overloading if 0xFF was present, this is only possible for an OP_AppCombined. OP_Combined will max at 0xFF (that is the value sent)
These combined packets are likely the cause of the incorrect client/server communication such as seen on zone in.
Still having the issue, something specific to the WS_PaperDoll packet and its messing up our processing of the client packets. More review needed.
The issue seems easier to replicate on a fresh executable, starting up the zone as the client may be high in cpu? Seems to be under a 'stressed' computer that the packets get a little deranged.
Still having the issue, something specific to the WS_PaperDoll packet and its messing up our processing of the client packets. More review needed.
The issue seems easier to replicate on a fresh executable, starting up the zone as the client may be high in cpu? Seems to be under a 'stressed' computer that the packets get a little deranged.
After these latest changes I cannot crash my client any further... probably just jinxed myself, but going to sit on this one till end of week and see if it re-appears since all these changes have been put in.
After these latest changes I cannot crash my client any further... probably just jinxed myself, but going to sit on this one till end of week and see if it re-appears since all these changes have been put in.
The client->server desync will be pursued further after the server->client desync is better understood through Issue #85.
This issue only causes the player to be kicked back to the character select screen.
Issue #85 causes the client to hard crash.
image
Split this issue in two
http://cutpon.com:3000/devn00b/EQ2EMu/issues/85 -- handles server->client desync http://cutpon.com:3000/devn00b/EQ2EMu/issues/61 -- handles client->server desync
There seems to be another netcode bug its causing bogus data to be read in and the server goes screwy :
12:23:04 E World : Unknown id of 747080834 when looting!
12:23:04 E Recipe : Recipe (3452816845) not found in TradeskillMgr::BeginCrafting()
12:23:04 E World : Invalid ZoneAuthRequest, disconnecting client.
This seems repeatable (triggers loot and some other things, but always sends a ZAR), but unpredictable.
foof brought to my attention that the OP_Combined code tries for an overloaded size when it only supports max of 0xFF. This change needed to be reflected on the code for both reading input from client and output to the client.
In the case of input for the client we tried overloading if 0xFF was present, this is only possible for an OP_AppCombined. OP_Combined will max at 0xFF (that is the value sent)
These combined packets are likely the cause of the incorrect client/server communication such as seen on zone in.
Still having the issue, something specific to the WS_PaperDoll packet and its messing up our processing of the client packets. More review needed.
The issue seems easier to replicate on a fresh executable, starting up the zone as the client may be high in cpu? Seems to be under a 'stressed' computer that the packets get a little deranged.
After these latest changes I cannot crash my client any further... probably just jinxed myself, but going to sit on this one till end of week and see if it re-appears since all these changes have been put in.
1/100 logins here it is:
https://cdn.discordapp.com/attachments/380808849722048525/700558385468145744/unknown.png
The client->server desync will be pursued further after the server->client desync is better understood through Issue #85.
This issue only causes the player to be kicked back to the character select screen.
Issue #85 causes the client to hard crash.
Resolved with latest changes pushed yesterday night with Aries Stage 2.0