Open SJonesy opened 4 years ago
We don't trust the client here, my guess is it's part of uoproxy's multi-head support?
Here's just the walking packets:
[client 1] walk seq_from_client=6 seq_to_server=6
sending packet to server, length=7
00000 02 80 06 00 00 00 00 .
walk_ack seq_to_client=6 seq_from_server=6
sending packet to client, length=3
00000 22 06 02 "
[client 1] walk seq_from_client=7 seq_to_server=7
sending packet to server, length=7
00000 02 80 07 00 00 00 00 .
walk_ack seq_to_client=7 seq_from_server=7
sending packet to client, length=3
00000 22 07 02 "
[client 1] walk seq_from_client=8 seq_to_server=8
sending packet to server, length=7
00000 02 80 08 00 00 00 00 .
walk_ack seq_to_client=8 seq_from_server=8
sending packet to client, length=3
00000 22 08 02 "
[client 1] walk seq_from_client=9 seq_to_server=9
sending packet to server, length=7
00000 02 80 09 00 00 00 00 .
walk_ack seq_to_client=9 seq_from_server=9
sending packet to client, length=3
00000 22 09 02 "
[client 1] walk seq_from_client=10 seq_to_server=10
sending packet to server, length=7
00000 02 80 0a 00 00 00 00 .
walk_ack seq_to_client=10 seq_from_server=10
sending packet to client, length=3
00000 22 0a 02 "
[client 1] walk seq_from_client=11 seq_to_server=11
sending packet to server, length=7
00000 02 80 0b 00 00 00 00 .
walk_ack seq_to_client=11 seq_from_server=11
sending packet to client, length=3
00000 22 0b 02 "
[client 1] walk seq_from_client=12 seq_to_server=12
sending packet to server, length=7
00000 02 80 0c 00 00 00 00 .
walk_ack seq_to_client=12 seq_from_server=12
sending packet to client, length=3
00000 22 0c 02 "
[client 1] walk seq_from_client=13 seq_to_server=13
sending packet to server, length=7
00000 02 80 0d 00 00 00 00 .
walk_ack seq_to_client=13 seq_from_server=13
sending packet to client, length=3
00000 22 0d 02 "
[client 1] walk seq_from_client=14 seq_to_server=14
sending packet to server, length=7
00000 02 80 0e 00 00 00 00 .
walk_ack seq_to_client=14 seq_from_server=14
sending packet to client, length=3
00000 22 0e 02 "
[client 1] walk seq_from_client=15 seq_to_server=15
sending packet to server, length=7
00000 02 80 0f 00 00 00 00 .
walk_ack seq_to_client=15 seq_from_server=15
sending packet to client, length=3
00000 22 0f 02 "
[client 1] walk seq_from_client=0 seq_to_server=16
sending packet to server, length=7
00000 02 80 10 00 00 00 00 .
[client 1] walk seq_from_client=1 seq_to_server=17
sending packet to server, length=7
00000 02 86 11 00 00 00 00 .
[client 1] walk seq_from_client=2 seq_to_server=18
sending packet to server, length=7
00000 02 86 12 00 00 00 00 .
[client 1] walk seq_from_client=3 seq_to_server=19
sending packet to server, length=7
00000 02 87 13 00 00 00 00 .
After further investigation, I'm pretty much desyncing after every time I cast a targeted spell.
this hacky patch fixes it, but it will cause "cancel target" packets to fail..
$ git diff
diff --git a/src/CHandler.cxx b/src/CHandler.cxx
index f8af00d..793f28e 100644
--- a/src/CHandler.cxx
+++ b/src/CHandler.cxx
@@ -288,7 +288,10 @@ handle_target(LinkedServer &ls,
sizeof(world->packet_target),
ls);
}
-
+
+ ls.connection->walk.seq_next = 0;
+ ls.connection->walk.queue_size = 0;
+
return PacketAction::ACCEPT;
}
This is a cleaner fix for it, but it still will cause desynchs sometimes such as for failed targets e.g. out-of-range teleports: https://github.com/SJonesy/uoproxy/commit/51f0d05bb11a21ca2f922f90c491fdfb27cb6d16
Using UOSteam with UOProxy .5 (latest master as of this post), I can 100% of the time reproduce a client desynch if I fire a spell while running on a mount. Doing the same thing when using just UOSteam does not result in a client desynch.
Here are repro steps, tested on UOOutlands:
Here's a packet log from one of these incidents: