MantisBT - Zandronum
View Issue Details
0003314Zandronum[All Projects] Bugpublic2017-10-28 01:062018-05-21 00:58
Leonard 
Leonard 
normalmajoralways
needs testingopen 
3.0 
3.1 
0003314: The ticbuffer isn't completely processed in some cases
The loop that is supposed to process it is wrong:
for ( unsigned int i = 0; i < g_aClients[ulIdx].MoveCMDs.Size(); ++i )
             {
                 g_aClients[ulIdx].MoveCMDs[0]->process ( ulIdx );
 
                 // [BB] Only limit the amount of movement commands.
                 if ( g_aClients[ulIdx].MoveCMDs[0]->isMoveCmd() )
                     ++numMoveCMDs;
 
                 delete g_aClients[ulIdx].MoveCMDs[0];
                 g_aClients[ulIdx].MoveCMDs.Delete(0);
 
                 if ( numMoveCMDs == 2 )
                     break;
             }

As you can see, i increases each step however Size() decreases since we deleted one entry from the TArray.
This becomes problematic if for example there are 2 movement commands left in the buffer, only one will be processed and then the condition (i < Size()) will no longer be true.
An easy way to directly notice this is to use sv_unlagged_debugactors:
Using the commit and testing wad referenced in 0002859:0018627:
-host a server on MAP01 with sv_unlagged_debugactors true
-connect and join 2 clients (locally)
-additionally you can enable the debug output (cl_debug_clientupdates)
-make sure to have cl_ticsperupdate on 1 so as to not run into 0003317
-simply hold the window for a second or so, this will freeze zandronum and will make it fill your ticbuffer when it recovers
-notice that the ticbuffer struggles to catch up for a moment at the very last tic (this is indicated both by the debug output and the unlagged debug actors being one tic behind for a moment)
After the fix, the ticbuffer catches up (almost) immediately.
No tags attached.
parent of 0002859needs testing Leonard Gametic-based unlagged seemingly goes out of sync often compared to ping-based unlagged 
Not all the children of this issue are yet resolved or closed.
Issue History
2017-10-28 01:06LeonardNew Issue
2017-10-28 01:06LeonardStatusnew => assigned
2017-10-28 01:06LeonardAssigned To => Leonard
2017-10-28 01:09LeonardDescription Updatedbug_revision_view_page.php?rev_id=11200#r11200
2017-10-28 01:54LeonardSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11202#r11202
2017-10-28 02:06LeonardNote Added: 0018628
2017-10-28 02:06LeonardStatusassigned => needs review
2017-10-28 10:54Torr SamahoNote Added: 0018631
2017-10-28 10:54Torr SamahoStatusneeds review => needs testing
2017-11-08 00:59LeonardRelationship addedrelated to 0002859
2017-11-08 01:00LeonardRelationship replacedparent of 0002859
2018-05-21 00:53StrikerMan780Note Added: 0019255
2018-05-21 00:56StrikerMan780Note Edited: 0019255bug_revision_view_page.php?bugnote_id=19255#r11548
2018-05-21 00:58StrikerMan780Note Edited: 0019255bug_revision_view_page.php?bugnote_id=19255#r11549

Notes
(0018628)
Leonard   
2017-10-28 02:06   
Starting with the easiest: PR.
(0018631)
Torr Samaho   
2017-10-28 10:54   
Thanks! I added your pull request.

For the record, this problem was already in 2.1.2.
(0019255)
StrikerMan780   
2018-05-21 00:53   
(edited on: 2018-05-21 00:58)
Not sure if this is related, but I'm having some really crazy weirdness as of the latest official beta.https://zandronum.com/downloads/testing/3.1/ZandroDev3.1-180520-0650windows.zip [^]

I'm hosting SimpleInstagib on TSPG with this build. They run on linux.

The weirdness I'm seeing, is players disappearing without a trace when they are hit, then the game registering the death after a delay, making their corpse and gibs show up at the respawn point. I'm also seeing things like, getting pushed from being shot by another's instagib rail, but it taking a few moments later for it to register that you've taken the damage... the two should coincide and happen together at the exact same time. The last weird bug I've seen, is people shooting rails with their ass turned to me.

Everything feels disjointed and out of order.

If it helps, my ticks per update is set to 1.