|Anonymous | Login | Signup for a new account||2019-05-21 00:34 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003314||Zandronum||[All Projects] Bug||public||2017-10-28 01:06||2018-05-21 00:58|
|Target Version||3.1||Fixed in Version|
|Summary||0003314: The ticbuffer isn't completely processed in some cases|
|Description||The loop that is supposed to process it is wrong:|
for ( unsigned int i = 0; i < g_aClients[ulIdx].MoveCMDs.Size(); ++i )
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 Reproduce||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)
|Additional Information||After the fix, the ticbuffer catches up (almost) immediately.|
|Starting with the easiest: PR.|
Torr Samaho (administrator)
Thanks! I added your pull request.
For the record, this problem was already in 2.1.2.
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.
|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.|
|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 - 2019 MantisBT Team|