MantisBT - Zandronum
View Issue Details
0001646Zandronum[All Projects] Bugpublic2014-01-06 15:102014-07-06 07:33
HexaDoken 
 
normalminorhave not tried
closedunable to reproduce 
MicrosoftWindowsXP/Vista/7
2.0-beta 
 
0001646: DMFlags desyncing between server/clients
Player 1 and player 2 join the server. Player 1 is the hoster of the server, player 2 is some guy with around 100 ping. sv_disallowspying is true, neither of the players are able to use coop-spy.

Player 1 changes sv_disallowspying to true on the server, receives the message about changed dmflags and is able to use coop-spy. Player 2 does NOT receive the message about changed dmflags and is NOT able to use coop-spy.

Player 2 then reconnects the server and is able to use coop-spy.

Not tested with other flags.

Encountered on Zandronum 2.0-alpha-131223-1820
No tags attached.
Issue History
2014-01-06 15:10HexaDokenNew Issue
2014-01-06 15:12HexaDokenNote Added: 0007895
2014-01-06 16:12DuskDescription Updatedbug_revision_view_page.php?rev_id=4371#r4371
2014-01-06 16:13DuskNote Edited: 0007895bug_revision_view_page.php?bugnote_id=7895#r4373
2014-01-06 17:50DuskNote Added: 0007899
2014-01-06 18:00DuskTarget Version => 2.0
2014-01-07 19:49Torr SamahoNote Added: 0007912
2014-01-07 21:16Torr SamahoNote Edited: 0007912bug_revision_view_page.php?bugnote_id=7912#r4384
2014-01-12 10:13Torr SamahoNote Added: 0007973
2014-01-12 10:14Torr SamahoStatusnew => feedback
2014-07-06 07:31Torr SamahoNote Added: 0009874
2014-07-06 07:33Torr SamahoStatusfeedback => closed
2014-07-06 07:33Torr SamahoResolutionopen => unable to reproduce
2014-07-06 07:33Torr SamahoTarget Version2.0 =>

Notes
(0007895)
HexaDoken   
2014-01-06 15:12   
(edited on: 2014-01-06 16:13)
> "0000024:0000100 ping"
Meh. Ignore, randomly happened, dunno how to edit it, was supposed to say "approximitely 100 ping".

fixed -Dusk

(0007899)
Dusk   
2014-01-06 17:50   
I think I know what's up: SERVERCOMMANDS_SetGameDMFlags is still using the old-form system and SERVER_CheckClientBuffer simply doesn't have a high enough value here.


        SERVER_CheckClientBuffer( ulIdx, 13, true );
        NETWORK_WriteHeader( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, SVC_SETGAMEDMFLAGS );
        NETWORK_WriteLong( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, lDMFlags );
        NETWORK_WriteLong( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, dmflags2 );
        NETWORK_WriteLong( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, compatflags );
        NETWORK_WriteLong( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, zacompatflags );
        NETWORK_WriteLong( &SERVER_GetClient( ulIdx )->PacketBuffer.ByteStream, zadmflags );


The actual traffic here is 21 bytes, not 13. Solution of course is to NetCommand this one up.
(0007912)
Torr Samaho   
2014-01-07 19:49   
(edited on: 2014-01-07 21:16)
You are completely right.

EDIT: This shouldn't cause the reported bug though. As far as I can tell, the only consequence of the wrong check is that the packet send to the client could be a few bytes bigger than specified with sv_maxpacketsize.

(0007973)
Torr Samaho   
2014-01-12 10:13   
I updated SERVERCOMMANDS_SetGameDMFlags to use NetCommand. Nevertheless, I'm still pretty sure that this will not have any affect on the reported issue.
(0009874)
Torr Samaho   
2014-07-06 07:31   
Since this is not reproducible, I'm closing this for now. If it happens again, please reopen the ticket.