Bug 3966 - Ping in the server list is always off by one frame
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: GIT MASTER
Hardware: PC All
: P3 minor
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2009-02-12 08:25 EST by Amanieu d'Antras
Modified: 2009-07-07 18:13:24 EDT
0 users

See Also:

Attachments
Fix for previous patch (2.17 KB, patch)
2009-07-05 16:38 EDT, Amanieu d'Antras

Description Amanieu d'Antras 2009-02-12 08:25:03 EST 
getinfo response packets (used for ping) are handled at the beginning of the common frame, but before the client frame. Therefore cls.realtime is still set to the time of the previous frame. When the packet is handled, the time is compared to cls.realtime, which is of course off by one frame. This is the cause of the strange 1 ping servers on the server list. Patch:

--- trunk/src/client/cl_main.c	2009/02/12 00:41:12	306
+++ trunk/src/client/cl_main.c	2009/02/12 13:15:20	307
@@ -3687,6 +3687,7 @@
 	char	info[MAX_INFO_STRING];
 	char	*infoString;
 	int		prot;
+	int		realmsec = Sys_Milliseconds();
 
 	infoString = MSG_ReadString( msg );
 
@@ -3703,7 +3704,7 @@
 		if ( cl_pinglist[i].adr.port && !cl_pinglist[i].time && NET_CompareAdr( from, cl_pinglist[i].adr ) )
 		{
 			// calc ping time
-			cl_pinglist[i].time = cls.realtime - cl_pinglist[i].start + 1;
+			cl_pinglist[i].time = realmsec - cl_pinglist[i].start + 1;
 			Com_DPrintf( "ping time %dms from %s\n", cl_pinglist[i].time, NET_AdrToString( from ) );
 
 			// save of info
Comment 1 Amanieu d'Antras 2009-02-12 08:25:43 EST 
Thanks to wireddd for finding the bug and making the patch.
Comment 2 Ludwig Nussel 2009-03-02 12:31:19 EST 
need some ack/nack on this
Comment 3 Tim Angus 2009-03-02 12:50:00 EST 
Looks alright to me. I don't think you need a new local variable though.

Also this doesn't address the separate issue of your ping times being quantised into whatever your frame period is... of course that's a more complicated problem and should probably be in a separate report.
Comment 4 Zachary J. Slater 2009-07-04 15:45:33 EDT 
Fixed in 3966 with a slightly different patch via Amanieu in IRC.
Comment 5 Zachary J. Slater 2009-07-04 16:25:20 EDT 
oops, revision # was 1580
Comment 6 Amanieu d'Antras 2009-07-05 16:38:03 EDT 
Created attachment 2089 [details]
Fix for previous patch

I forgot that there was another part to that patch. Here is another patch to apply on top of the one already applied.
Comment 7 Zachary J. Slater 2009-07-07 18:13:24 EDT 
Committed revision 1581.