0001744: Server and client can get out of sync about character position

(0000467)
Incanus (reporter)
10-05-10 17:53

Disabling UsePacketPriority does not fix this problem

(0000470)
Incanus (reporter)
15-05-10 22:36

Added two SpyUO logs. The logs were created running through a teleporter logging the pacekts ReqMove (02), CharMoveRejection (21), MoveAllowed (22) and MoveMobile (20).

Sphere sends the CharMoveRejection Packet after using a teleporter, with the sequence number 0.
The error occurs when the client sends a new ReqMove Packet with sequence number 0, before it has received the CharMoveRejection packet for the teleport.
Thus the client thinks its move request got rejected causing server and client getting out of sync about the characters position.

(0000477)
HOCOK (reporter)
27-05-10 13:06
edited on: 27-05-10 13:08

confirm.

it's only with new sockets, if you use sphere "September 20 2009" , there is no such problem.

you can reproduce it by putting teleport(end) 1 tile after wall, and run into teleport(start), and you will be in wall.

(0000481)
MrSugarCube (administrator)
30-05-10 15:41

I'm struggling to reproduce this, although I have found and fixed what I think would cause this problem.

Could you please re-check this in tomorrow's automated build? (version #1287+)

(0000483)
Incanus (reporter)
31-05-10 02:38
edited on: 31-05-10 02:41

Thank you, it's much better now. But I'm afraid the problem is not fixed 100%. I walked like 200 times through my test gates and the bug appeared only 2 times. Before rev 1287 I had the bug in 25% of the tests.
I'll add the SpyUO logs.

Tested with these settings on an remote server:
EF_NetworkOutThread
MaxPacketsPerTick=100
MaxQueueSize=400
MaxSizePerTick=18000
UseAsyncNetwork=1
UsePacketPriority=1

(0000490)
MrSugarCube (administrator)
15-06-10 08:39

Is there any change on the latest automated build? (version #1289+)

(0000620)
MrSugarCube (administrator)
13-09-10 11:30

Can someone (who was able to reproduce this) check if this is still a problem on the latest automated builds? I would like to avoid having to close this issue without knowing if it has been resolved.

(0000622)
Incanus (reporter)
14-09-10 04:10

The bug stills exists for me on build r1332
Settings:
EF_NetworkOutThread
MaxPacketsPerTick=100
MaxQueueSize=400
MaxSizePerTick=18000
UseAsyncNetwork=1
UsePacketPriority=1
TooltipMode=1

Ping to server: 60 ms

Client: 5.04b

I found that I have the most success reproducing this bug is to run through a gate, changing direction immediately and taking the gate back in the other direction. This way I can reproduce the bug 5% of the tries.
If it helps I could make a video

(0000623)
MrSugarCube (administrator)
14-09-10 04:34

Thanks, can you check this again on the next automated build (version #1333+)? If the problem is still present, it may also help to try with UsePacketPriority=0 as well.

(0000624)
Incanus (reporter)
15-09-10 01:11

Thanks, seems to be fixed. I could not reproduce it anymore in like 100 tries.

(0000625)
MrSugarCube (administrator)
15-09-10 01:18

Was that with UsePacketPriority=1 as well?

(0000627)
Incanus (reporter)
15-09-10 01:24

yes, settings are:
EF_NetworkOutThread
MaxPacketsPerTick=100
MaxQueueSize=400
MaxSizePerTick=18000
UseAsyncNetwork=1
UsePacketPriority=1
TooltipMode=0
ToolTipCache=0

(0000628)
MrSugarCube (administrator)
15-09-10 01:53

Great news, thanks. ;)

Issue History
Date Modified	Username	Field	Change
04-05-10 02:16	Incanus	New Issue
04-05-10 02:16	Incanus	File Added: outofsync.png
04-05-10 02:16	Incanus	Nightly Version	=> Not Available
04-05-10 02:16	Incanus	Experimental Flags	=> None
04-05-10 02:16	Incanus	Option Flags	=> None
10-05-10 17:53	Incanus	Note Added: 0000467
15-05-10 22:24	Incanus	File Added: move_error.txt
15-05-10 22:24	Incanus	File Added: move_correct.txt
15-05-10 22:36	Incanus	Note Added: 0000470
27-05-10 13:06	HOCOK	Note Added: 0000477
27-05-10 13:08	HOCOK	Note Edited: 0000477
30-05-10 15:41	MrSugarCube	Note Added: 0000481
31-05-10 02:38	Incanus	Note Added: 0000483
31-05-10 02:39	Incanus	File Added: error_2.txt
31-05-10 02:39	Incanus	File Added: error_3.txt
31-05-10 02:41	Incanus	Note Edited: 0000483
15-06-10 08:39	MrSugarCube	Note Added: 0000490
03-07-10 00:21	MrSugarCube	Status	new => feedback
23-08-10 17:28	MrSugarCube	Priority	normal => high
13-09-10 11:26	MrSugarCube	Relationship added	related to 0001752
13-09-10 11:30	MrSugarCube	Note Added: 0000620
14-09-10 04:10	Incanus	Note Added: 0000622
14-09-10 04:10	Incanus	Status	feedback => new
14-09-10 04:34	MrSugarCube	Note Added: 0000623
15-09-10 01:11	Incanus	Note Added: 0000624
15-09-10 01:18	MrSugarCube	Note Added: 0000625
15-09-10 01:24	Incanus	Note Added: 0000627
15-09-10 01:53	MrSugarCube	Note Added: 0000628
15-09-10 01:53	MrSugarCube	Status	new => resolved
15-09-10 01:53	MrSugarCube	Fixed in Version	=> 0.56c Nightly
15-09-10 01:53	MrSugarCube	Resolution	open => fixed
15-09-10 01:53	MrSugarCube	Assigned To	=> MrSugarCube

Notes
(0000467) Incanus (reporter) 10-05-10 17:53	Disabling UsePacketPriority does not fix this problem

(0000470) Incanus (reporter) 15-05-10 22:36	Added two SpyUO logs. The logs were created running through a teleporter logging the pacekts ReqMove (02), CharMoveRejection (21), MoveAllowed (22) and MoveMobile (20). Sphere sends the CharMoveRejection Packet after using a teleporter, with the sequence number 0. The error occurs when the client sends a new ReqMove Packet with sequence number 0, before it has received the CharMoveRejection packet for the teleport. Thus the client thinks its move request got rejected causing server and client getting out of sync about the characters position.

(0000477) HOCOK (reporter) 27-05-10 13:06 edited on: 27-05-10 13:08	confirm. it's only with new sockets, if you use sphere "September 20 2009" , there is no such problem. you can reproduce it by putting teleport(end) 1 tile after wall, and run into teleport(start), and you will be in wall.

(0000481) MrSugarCube (administrator) 30-05-10 15:41	I'm struggling to reproduce this, although I have found and fixed what I think would cause this problem. Could you please re-check this in tomorrow's automated build? (version #1287+)

(0000483) Incanus (reporter) 31-05-10 02:38 edited on: 31-05-10 02:41	Thank you, it's much better now. But I'm afraid the problem is not fixed 100%. I walked like 200 times through my test gates and the bug appeared only 2 times. Before rev 1287 I had the bug in 25% of the tests. I'll add the SpyUO logs. Tested with these settings on an remote server: EF_NetworkOutThread MaxPacketsPerTick=100 MaxQueueSize=400 MaxSizePerTick=18000 UseAsyncNetwork=1 UsePacketPriority=1

(0000490) MrSugarCube (administrator) 15-06-10 08:39	Is there any change on the latest automated build? (version #1289+)

(0000620) MrSugarCube (administrator) 13-09-10 11:30	Can someone (who was able to reproduce this) check if this is still a problem on the latest automated builds? I would like to avoid having to close this issue without knowing if it has been resolved.

(0000622) Incanus (reporter) 14-09-10 04:10	The bug stills exists for me on build r1332 Settings: EF_NetworkOutThread MaxPacketsPerTick=100 MaxQueueSize=400 MaxSizePerTick=18000 UseAsyncNetwork=1 UsePacketPriority=1 TooltipMode=1 Ping to server: 60 ms Client: 5.04b I found that I have the most success reproducing this bug is to run through a gate, changing direction immediately and taking the gate back in the other direction. This way I can reproduce the bug 5% of the tries. If it helps I could make a video

(0000623) MrSugarCube (administrator) 14-09-10 04:34	Thanks, can you check this again on the next automated build (version #1333+)? If the problem is still present, it may also help to try with UsePacketPriority=0 as well.

(0000624) Incanus (reporter) 15-09-10 01:11	Thanks, seems to be fixed. I could not reproduce it anymore in like 100 tries.

(0000625) MrSugarCube (administrator) 15-09-10 01:18	Was that with UsePacketPriority=1 as well?

(0000627) Incanus (reporter) 15-09-10 01:24	yes, settings are: EF_NetworkOutThread MaxPacketsPerTick=100 MaxQueueSize=400 MaxSizePerTick=18000 UseAsyncNetwork=1 UsePacketPriority=1 TooltipMode=0 ToolTipCache=0

(0000628) MrSugarCube (administrator) 15-09-10 01:53	Great news, thanks. ;)