Zandronum Chat on our Discord Server Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003314Zandronum[All Projects] Bugpublic2017-10-28 01:062018-05-21 00:58
Assigned ToLeonard 
Statusneeds testingResolutionopen 
PlatformOSOS Version
Product Version3.0 
Target Version3.1Fixed in Version 
Summary0003314: The ticbuffer isn't completely processed in some cases
DescriptionThe 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() )
                 delete g_aClients[ulIdx].MoveCMDs[0];
                 if ( numMoveCMDs == 2 )

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.
Steps To ReproduceAn 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)
Additional InformationAfter the fix, the ticbuffer catches up (almost) immediately.
Attached Files

- Relationships
parent of 0002859needs testingLeonard 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.

-  Notes
User avatar (0018628)
Leonard (developer)
2017-10-28 02:06

Starting with the easiest: PR.
User avatar (0018631)
Torr Samaho (administrator)
2017-10-28 10:54

Thanks! I added your pull request.

For the record, this problem was already in 2.1.2.
User avatar (0019255)
StrikerMan780 (reporter)
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. [^]

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.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2017-10-28 01:06 Leonard New Issue
2017-10-28 01:06 Leonard Status new => assigned
2017-10-28 01:06 Leonard Assigned To => Leonard
2017-10-28 01:09 Leonard Description Updated View Revisions
2017-10-28 01:54 Leonard Steps to Reproduce Updated View Revisions
2017-10-28 02:06 Leonard Note Added: 0018628
2017-10-28 02:06 Leonard Status assigned => needs review
2017-10-28 10:54 Torr Samaho Note Added: 0018631
2017-10-28 10:54 Torr Samaho Status needs review => needs testing
2017-11-08 00:59 Leonard Relationship added related to 0002859
2017-11-08 01:00 Leonard Relationship replaced parent of 0002859
2018-05-21 00:53 StrikerMan780 Note Added: 0019255
2018-05-21 00:56 StrikerMan780 Note Edited: 0019255 View Revisions
2018-05-21 00:58 StrikerMan780 Note Edited: 0019255 View Revisions

Questions or other issues? Contact Us.


Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker