Notes |
|
(0003176)
|
TIHan
|
2012-04-07 18:57
|
|
|
|
|
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.
|
|
|
|
Do you still need a testcase WAD? I can do it for you. |
|
|
|
Yes, it would still be nice to have a testcase WAD for this. |
|
|
|
We should consider handling this by a new connection type userinfo option as mentioned in 0000913:0003944. |
|
|
|
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. |
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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) |
|
|
|
|
That should work, but almost doubles the additional bandwidth. |
|
|
|
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) |
|
|
|
|
|
|
|
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. |
|