0000750: Missing DropItem prediction online

(0003176)
TIHan (reporter)
2012-04-07 18:57

Fixed.
'https://bitbucket.org/TIHan/tst/changeset/9739a0f5cf7e [^]'

(0003224)
Torr Samaho (administrator)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
2012-07-11 02:34

Do you still need a testcase WAD? I can do it for you.

(0003950)
Torr Samaho (administrator)
2012-07-11 19:45

Yes, it would still be nice to have a testcase WAD for this.

(0004254)
Torr Samaho (administrator)
2012-08-05 08:28

We should consider handling this by a new connection type userinfo option as mentioned in 0000913:0003944.

(0012576)
unknownna (updater)
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 (reporter)
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 (developer)
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 (updater)
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 (developer)
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 (updater)
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 (developer)
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 (administrator)
2016-11-26 13:07

That should work, but almost doubles the additional bandwidth.

(0016327)
Edward-san (developer)
2016-11-26 13:18

This makes me think the old approach would be better. What do you think?

(0016599)
Edward-san (developer)
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 (administrator)
2017-01-15 10:00

To avoid additional maintenance overhead, I added'https://bitbucket.org/zandronum/zandronum-sandbox/commits/422e4ca2630236ecb9e66a94f7548bb71c0fd11e [^]'

(0016819)
Ru5tK1ng (updater)
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.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	WaTaKiD unknownna Leonard Combinebobnt Daedalus Karakurt Razgriz
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-04-01 22:45	unknownna	New Issue
2012-04-01 22:45	unknownna	Status	new => confirmed
2012-04-07 17:59	TIHan	Assigned To	=> TIHan
2012-04-07 17:59	TIHan	Status	confirmed => assigned
2012-04-07 18:57	TIHan	Note Added: 0003176
2012-04-07 18:57	TIHan	Status	assigned => feedback
2012-04-12 06:15	unknownna	Relationship added	related to 0000765
2012-04-12 23:37	Torr Samaho	Note Added: 0003224
2012-04-13 02:26	TIHan	Note Added: 0003231
2012-04-13 03:19	MP2E	Note Added: 0003233
2012-04-18 06:04	TIHan	Note Added: 0003345
2012-04-23 11:21	unknownna	Reporter	unknownna => kgsws
2012-04-29 04:23	TIHan	Note Edited: 0003345	View Revisions
2012-04-29 04:24	TIHan	Status	feedback => needs review
2012-06-09 13:22	Torr Samaho	Category	General => Bug
2012-07-11 02:34	ZzZombo	Note Added: 0003945
2012-07-11 19:45	Torr Samaho	Note Added: 0003950
2012-08-05 08:28	Torr Samaho	Note Added: 0004254
2012-08-05 08:28	Torr Samaho	Status	needs review => confirmed
2015-06-07 03:54	unknownna	Note Added: 0012576
2015-06-07 03:54	unknownna	File Added: dropitem_01.wad
2015-06-07 03:54	unknownna	File Added: Screenshot_Doom_20150607_054108.png
2015-06-07 03:58	unknownna	Assigned To	TIHan =>
2015-06-07 03:58	unknownna	Steps to Reproduce Updated	View Revisions
2015-06-07 04:00	unknownna	Priority	low => normal
2015-06-07 04:00	unknownna	Severity	trivial => minor
2015-06-14 03:51	unknownna	Relationship added	has duplicate 0002307
2015-07-21 12:00	unknownna	Target Version	=> 2.2
2015-07-22 19:03	Combinebobnt	Note Added: 0012996
2015-07-22 20:44	unknownna	Priority	normal => high
2015-08-25 12:36	Dusk	Note Added: 0013269
2015-08-25 12:36	Dusk	Note Edited: 0013269	View Revisions
2015-08-25 13:19	Dusk	Note Edited: 0013269	View Revisions
2016-10-18 15:49	unknownna	Note Added: 0016046
2016-10-18 19:10	Edward-san	Note Added: 0016048
2016-10-18 19:13	Edward-san	Note Edited: 0016048	View Revisions
2016-10-19 08:39	unknownna	Note Added: 0016056
2016-10-19 09:59	Edward-san	Note Added: 0016057
2016-10-19 09:59	Edward-san	Assigned To	=> Edward-san
2016-10-19 09:59	Edward-san	Status	confirmed => assigned
2016-10-19 10:01	Edward-san	Note Edited: 0016057	View Revisions
2016-10-19 10:14	Edward-san	Note Edited: 0016057	View Revisions
2016-10-19 10:15	Edward-san	Status	assigned => needs review
2016-11-26 09:37	Edward-san	Note Edited: 0016057	View Revisions
2016-11-26 13:07	Torr Samaho	Note Added: 0016326
2016-11-26 13:18	Edward-san	Note Added: 0016327
2017-01-04 14:48	Edward-san	Relationship added	parent of 0002522
2017-01-04 15:38	Edward-san	Note Added: 0016599
2017-01-04 15:39	Edward-san	Note Edited: 0016599	View Revisions
2017-01-15 10:00	Torr Samaho	Note Added: 0016639
2017-01-15 10:01	Torr Samaho	Status	needs review => needs testing
2017-01-15 10:01	Torr Samaho	Target Version	2.2 => 3.0
2017-02-07 23:26	Ru5tK1ng	Note Added: 0016819
2017-02-07 23:26	Ru5tK1ng	Status	needs testing => resolved
2017-02-07 23:26	Ru5tK1ng	Resolution	open => fixed
2017-02-07 23:26	Ru5tK1ng	Fixed in Version	=> 3.0
2018-09-30 21:48	Blzut3	Status	resolved => closed

Notes
(0003176) TIHan (reporter) 2012-04-07 18:57	Fixed. 'https://bitbucket.org/TIHan/tst/changeset/9739a0f5cf7e [^]'

(0003224) Torr Samaho (administrator) 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 (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 2012-07-11 02:34	Do you still need a testcase WAD? I can do it for you.

(0003950) Torr Samaho (administrator) 2012-07-11 19:45	Yes, it would still be nice to have a testcase WAD for this.

(0004254) Torr Samaho (administrator) 2012-08-05 08:28	We should consider handling this by a new connection type userinfo option as mentioned in 0000913:0003944.

(0012576) unknownna (updater) 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 (reporter) 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 (developer) 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 (updater) 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 (developer) 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 (updater) 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 (developer) 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 (administrator) 2016-11-26 13:07	That should work, but almost doubles the additional bandwidth.

(0016327) Edward-san (developer) 2016-11-26 13:18	This makes me think the old approach would be better. What do you think?

(0016599) Edward-san (developer) 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 (administrator) 2017-01-15 10:00	To avoid additional maintenance overhead, I added'https://bitbucket.org/zandronum/zandronum-sandbox/commits/422e4ca2630236ecb9e66a94f7548bb71c0fd11e [^]'

(0016819) Ru5tK1ng (updater) 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.