MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0003314 | Zandronum | [All Projects] Bug | public | 2017-10-28 01:06 | 2024-11-15 18:00 |
|
| Reporter | Leonard | |
| Assigned To | Leonard | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | open | |
| Platform | | OS | | OS Version | |
| Product Version | 3.0 | |
| 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 )
{
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. |
| 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. |
| Tags | No tags attached. |
| Relationships | | parent of | 0002859 | resolved | Leonard | Gametic-based unlagged seemingly goes out of sync often compared to ping-based unlagged |
|
| Attached Files |  unlagged_debug_03.wad (13,507) 2024-03-12 08:32
https://zandronum.com/tracker/file_download.php?file_id=2935&type=bug |
|
| 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 | bug_revision_view_page.php?rev_id=11200#r11200 |
| 2017-10-28 01:54 | Leonard | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=11202#r11202 |
| 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 | bug_revision_view_page.php?bugnote_id=19255#r11548 |
| 2018-05-21 00:58 | StrikerMan780 | Note Edited: 0019255 | bug_revision_view_page.php?bugnote_id=19255#r11549 |
| 2024-03-12 08:10 | unknownna | Note Added: 0023374 | |
| 2024-03-12 08:10 | unknownna | Status | needs testing => feedback |
| 2024-03-12 08:32 | unknownna | File Added: unlagged_debug_03.wad | |
| 2024-11-15 07:03 | unknownna | Note Added: 0024141 | |
| 2024-11-15 18:00 | Kaminsky | Note Added: 0024146 | |
|
Notes |
|
|
|
|
Starting with the easiest: PR. |
|
|
|
|
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.
|
|
|
|
|
I'm not sure how quite to test this properly, cl_debug_clientupdates seems to be a non-existent variable.
Clicking, holding and releasing the the window causes the red debug actor to shift back for a little before catching up again. However, this seems to be faster in 3.0 than 3.1 after the fix. It actually catches up slower and choppier now compared to before. |
|
|
|
|
With the new clock offset and buffer fixes by Kaminsky, this seems to work really nicely again. After clicking and holding the window a little, the player and the debug actor both catch up really smoothly and not choppy at all anymore.
The only minor nitpick I have is that the player and debug actor "snap" to their final position after recovery with a small jump. Is this OK? |
|
|
|
|
|
I'll have to take a look at this "snap" effect to see if there's anything that can be done to improve it, if necessary. |
|