MantisBT - Zandronum
View Issue Details
0000750Zandronum[All Projects] Bugpublic2012-04-01 22:452018-09-30 21:48
kgsws 
Edward-san 
highminoralways
closedfixed 
98d 
3.03.0 
0000750: Missing DropItem prediction online
Actors don't toss their items online.
1. zandronum -file dropitem_01.wad -host
2. zandronum -file dropitem_01.wad +connect localhost
3. Join the game.
4. Kill the zombieman a few times.
No tags attached.
parent of 0002522closed Edward-san sv_dropstyle 1 or 2, coursing items to desync online 
has duplicate 0002307closed  Dropped items mispredictions online 
related to 0000765closed Torr Samaho RandomSpawner thing z desync on 3D floors after map resets online 
? dropitem_01.wad (4,951) 2015-06-07 03:54
/tracker/file_download.php?file_id=1525&type=bug
png Screenshot_Doom_20150607_054108.png (51,295) 2015-06-07 03:54
/tracker/file_download.php?file_id=1526&type=bug
png
Issue History
2012-04-01 22:45unknownnaNew Issue
2012-04-01 22:45unknownnaStatusnew => confirmed
2012-04-07 17:59TIHanAssigned To => TIHan
2012-04-07 17:59TIHanStatusconfirmed => assigned
2012-04-07 18:57TIHanNote Added: 0003176
2012-04-07 18:57TIHanStatusassigned => feedback
2012-04-12 06:15unknownnaRelationship addedrelated to 0000765
2012-04-12 23:37Torr SamahoNote Added: 0003224
2012-04-13 02:26TIHanNote Added: 0003231
2012-04-13 03:19MP2ENote Added: 0003233
2012-04-18 06:04TIHanNote Added: 0003345
2012-04-23 11:21unknownnaReporterunknownna => kgsws
2012-04-29 04:23TIHanNote Edited: 0003345bug_revision_view_page.php?bugnote_id=3345#r1883
2012-04-29 04:24TIHanStatusfeedback => needs review
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2012-07-11 02:34ZzZomboNote Added: 0003945
2012-07-11 19:45Torr SamahoNote Added: 0003950
2012-08-05 08:28Torr SamahoNote Added: 0004254
2012-08-05 08:28Torr SamahoStatusneeds review => confirmed
2015-06-07 03:54unknownnaNote Added: 0012576
2015-06-07 03:54unknownnaFile Added: dropitem_01.wad
2015-06-07 03:54unknownnaFile Added: Screenshot_Doom_20150607_054108.png
2015-06-07 03:58unknownnaAssigned ToTIHan =>
2015-06-07 03:58unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7294#r7294
2015-06-07 04:00unknownnaPrioritylow => normal
2015-06-07 04:00unknownnaSeveritytrivial => minor
2015-06-14 03:51unknownnaRelationship addedhas duplicate 0002307
2015-07-21 12:00unknownnaTarget Version => 2.2
2015-07-22 19:03CombinebobntNote Added: 0012996
2015-07-22 20:44unknownnaPrioritynormal => high
2015-08-25 12:36DuskNote Added: 0013269
2015-08-25 12:36DuskNote Edited: 0013269bug_revision_view_page.php?bugnote_id=13269#r7945
2015-08-25 13:19DuskNote Edited: 0013269bug_revision_view_page.php?bugnote_id=13269#r7946
2016-10-18 15:49unknownnaNote Added: 0016046
2016-10-18 19:10Edward-sanNote Added: 0016048
2016-10-18 19:13Edward-sanNote Edited: 0016048bug_revision_view_page.php?bugnote_id=16048#r9781
2016-10-19 08:39unknownnaNote Added: 0016056
2016-10-19 09:59Edward-sanNote Added: 0016057
2016-10-19 09:59Edward-sanAssigned To => Edward-san
2016-10-19 09:59Edward-sanStatusconfirmed => assigned
2016-10-19 10:01Edward-sanNote Edited: 0016057bug_revision_view_page.php?bugnote_id=16057#r9789
2016-10-19 10:14Edward-sanNote Edited: 0016057bug_revision_view_page.php?bugnote_id=16057#r9790
2016-10-19 10:15Edward-sanStatusassigned => needs review
2016-11-26 09:37Edward-sanNote Edited: 0016057bug_revision_view_page.php?bugnote_id=16057#r9913
2016-11-26 13:07Torr SamahoNote Added: 0016326
2016-11-26 13:18Edward-sanNote Added: 0016327
2017-01-04 14:48Edward-sanRelationship addedparent of 0002522
2017-01-04 15:38Edward-sanNote Added: 0016599
2017-01-04 15:39Edward-sanNote Edited: 0016599bug_revision_view_page.php?bugnote_id=16599#r10015
2017-01-15 10:00Torr SamahoNote Added: 0016639
2017-01-15 10:01Torr SamahoStatusneeds review => needs testing
2017-01-15 10:01Torr SamahoTarget Version2.2 => 3.0
2017-02-07 23:26Ru5tK1ngNote Added: 0016819
2017-02-07 23:26Ru5tK1ngStatusneeds testing => resolved
2017-02-07 23:26Ru5tK1ngResolutionopen => fixed
2017-02-07 23:26Ru5tK1ngFixed in Version => 3.0
2018-09-30 21:48Blzut3Statusresolved => closed

Notes
(0003176)
TIHan   
2012-04-07 18:57   
Fixed.
'https://bitbucket.org/TIHan/tst/changeset/9739a0f5cf7e [^]'
(0003224)
Torr Samaho   
2012-04-12 23:37   
The fix needs a considerable amount of net traffic for in my eyes very little gain. Unfortunately that's the only way to fix this and the reason why I never worked on this so far. Probably items are dropped seldom enough though so that it doesn't matter. Does anybody know a mod with a lot of drops that we could use to test the real world net traffic increase of the fix?
(0003231)
TIHan   
2012-04-13 02:26   
I don't think I've ever seen an instance where there were many drops happening in a second.
(0003233)
MP2E   
2012-04-13 03:19   
I also have never seen an instance where many drops were happening in a second, except for back in 97d-ish when it could be used in capture the flag to double ammo count and you could spam it.
(0003345)
TIHan   
2012-04-18 06:04   
(edited on: 2012-04-29 04:23)
I know we are still questioning this. If we wanted to use a little less bandwidth, I say let SERVERCOMMANDS_SpawnThing/Exact set the momentum. Also, I guess we don't have to use Exact here.

Edit:
There really shouldn't be a problem here using full precision and momentum.

(0003945)
ZzZombo   
2012-07-11 02:34   
Do you still need a testcase WAD? I can do it for you.
(0003950)
Torr Samaho   
2012-07-11 19:45   
Yes, it would still be nice to have a testcase WAD for this.
(0004254)
Torr Samaho   
2012-08-05 08:28   
We should consider handling this by a new connection type userinfo option as mentioned in 0000913:0003944.
(0012576)
unknownna   
2015-06-07 03:54   
This issue is very noticeable in Complex Doom. Monsters often drop items near ledges that you can't pick up due to the desync between client and server.
(0012996)
Combinebobnt   
2015-07-22 19:03   
Happens often in zdoomwars as well, with mana drops on ledges or even on the ground not displaying their true position
(0013269)
Dusk   
2015-08-25 12:36   
(edited on: 2015-08-25 13:19)
Hmm. Issue 0000453 was fixed by a patch that made the flags be synced to clients when the item is dropped. This added 8 bytes of network traffic per dropped item and nobody noticed a thing until now.

So a patch that synced the velocity of the dropped item (11 bytes) would add only 3 more additional bytes per dropped item if the item's NOGRAVITY flag is actually cleared (which in retrospect should've been done in the first place but oh well). So is syncing the velocity that much of a problem?

On the other hand, I also have a solution tailored to this particular issue. We could introduce a sentinel thinker that watches the dropped item for a second and, if it falls far enough, syncs the position and velocity to clients in full. This could produce optimal bandwidth usage at the cost of accuracy when the thinker does not fire.

EDIT: But hmm the problem is that the client appears to give the dropped item some sort of velocity. So the client drops it instead of the server. Bleh.

(0016046)
unknownna   
2016-10-18 15:49   
I noticed in a recent 3.0 build that actors now toss their items if cl_connectiontype is 1, which they did not do before. However, since this particular issue was never fixed the items are still unfortunately desynced as usual.
(0016048)
Edward-san   
2016-10-18 19:10   
(edited on: 2016-10-18 19:13)
Quote from unknownna
I noticed in a recent 3.0 build that actors now toss their items if cl_connectiontype is 1, which they did not do before. However, since this particular issue was never fixed the items are still unfortunately desynced as usual.


Are you talking about ticket 0002522 ? The fix ignores intentionally clients with slow connections.

(0016056)
unknownna   
2016-10-19 08:39   
Yes, that seems to be it. I know that items aren't tossed when cl_connectiontype is 0, but what I meant was that the items are still not synced properly on the clients when they're tossed with cl_connectiontype 1.
(0016057)
Edward-san   
2016-10-19 09:59   
(edited on: 2016-11-26 09:37)
Urgh, right. This happens only if the drop style is 1 and 2.

Should be fixed with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/f180f8a86c74e1e1038fd1241a5c389790b68a2f [^]' .

[edit] Rebased to current tip with this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/422e4ca2630236ecb9e66a94f7548bb71c0fd11e [^]'

(0016326)
Torr Samaho   
2016-11-26 13:07   
That should work, but almost doubles the additional bandwidth.
(0016327)
Edward-san   
2016-11-26 13:18   
This makes me think the old approach would be better. What do you think?
(0016599)
Edward-san   
2017-01-04 15:38   
(edited on: 2017-01-04 15:39)
Resurfaced the old approach, because the bandwidth consumption is much less than 0000750:0016057 . Should be fixed with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/61f26dc53ca2c9ad8c6ea44a346caf9c6e68f5d6 [^]' .

(0016639)
Torr Samaho   
2017-01-15 10:00   
To avoid additional maintenance overhead, I added'https://bitbucket.org/zandronum/zandronum-sandbox/commits/422e4ca2630236ecb9e66a94f7548bb71c0fd11e [^]'
(0016819)
Ru5tK1ng   
2017-02-07 23:26   
Tested this online with the latest build and the zombieman dropped the armor bonus each time it was fragged with sv_dropstyle 0, 1, and 2.