|
Notes |
|
|
|
|
To be more precise, make a new server from the command line, join the server and do as the demo shows. It's not easy to spot the right angle, but it happened sometimes that monsters projectiles stopped at a certain edge but later they hurt the player. Pretty annoying. |
|
|
|
|
|
I can confirm this. With 2 clients, both clients agree that the missile visually/sonically explodes in the wrong place. The actual explosion is on the pillar on the left in the screenshot. |
|
|
|
|
Quote from Torr Samaho
To save bandwidth the server only sent the player's position at 16 bit accuracy. When at a sector boundary, this could cause a player to be rounded to the neighboring sector and since a player can't be inside the floor, it was then raised to the floor height. I made the server sent the x/y position at full precision, fixing the problems for players. I really don't want to send the puffs at full precision though, since there are potentially a lot of puffs, this would eat a lot of bandwidth. |
|
|
|
(0003338)
|
|
TIHan
|
|
2012-04-17 22:13
|
|
This does feel like a precision problem. The question is whether we should allow the full precision of projectiles spawning. IMHO, we don't want to have edge cases of projectiles desyncing nor do we want to waste a lot of bandwidth.
If this is indeed a precision issue (which I believe it is), there needs to be a discussion on whether or not all missiles should spawn with full precision. Reading this "monsters projectiles stopped at a certain edge but later they hurt the player." is a big problem. |
|
|
|
|
|
It should be completely sufficient if the client doesn't execute the explode on hit logic and waits for the server to tell it about the explosion. That's how I fixed the client side explosions mispredictions on actor hits. |
|
|
|
(0003342)
|
|
TIHan
|
|
2012-04-18 02:15
|
|
|
|
|
(0003347)
|
|
TIHan
|
|
2012-04-18 23:43
|
|
|
This apparently isn't complete yet. I'll let you know when I have updated it. |
|
|
|
(0003350)
|
|
TIHan
|
|
2012-04-21 00:03
|
|
This should take care of it.
'https://bitbucket.org/TIHan/tst/changeset/4c932e6148fe [^]'
I thought about this for a while and IMHO, I do not think it is a problem if we let projectiles fire on exact positions as they do not occur THAT frequently between seconds. Until we really know setting projectiles to exact firing positions causes some very significant bandwidth issues should we even consider hacky methods.
But anyway, if you disagree, then that fix should take care of your original plan.
|
|
|
|
|
Regarding the precision: Deciding to always increase bandwidth usage to fix problems that only occur rarely is a decision that you can probably make a few times, but recently I have seen a tendency that this kind of decisions are proposed to be made on a regular basis.
All this additional bandwidth usage accumulates and may very well get us in trouble. What we could consider is to reintroduce a client side connection setting, where the client tells the server whether he favors less bandwidth usage or more accuracy. |
|
|
|
(0003369)
|
|
TIHan
|
|
2012-04-21 20:21
|
|
> kind of decisions are proposed to be made on a regular basis.
Because we have desyncs. We do not know for sure how precision in these cases would affect bandwidth typically. But we do know for sure because of no precision we have bugs. I would prefer that we not gold plate anything here. Let's make everything work and if there is a performance/bandwidth problem then we will address it.
> where the client tells the server whether he favors less bandwidth usage or more accuracy.
IMHO, the client should never determine how much bandwidth the server should use. That should be entirely up to the server admin. |
|
|
|
|
> Let's make everything work and if there is a performance/bandwidth problem then we will address it.
The big problem I see with that approach is that by the time the bandwidth usage gets to excessive, we made so many changes that each increased the bandwidth that it's a lot of work to go back to the old bandwidth usage.
> IMHO, the client should never determine how much bandwidth the server should use. That should be entirely up to the server admin.
Well, you may argue that the server should be able to set an upper cap on the bandwidth. That's fine. But I don't see why a client should not be able to say, send me less stuff, I don't care about small desyncs. The client knows best how much download bandwidth he has and it doesn't make sense if the server admin forces the client to receive more than the connection of the client can handle. |
|
|
|
(0003375)
|
|
TIHan
|
|
2012-04-21 23:39
|
|
> we made so many changes that each increased the bandwidth that it's a lot of work to go back to the old bandwidth usage.
The only changes I see concerning precision are items dropped on actor death and spawned projectiles. If we talk about how we can design such things where we can flip a switch and turn on and off precision would be the best approach to avoid this problem.
> But I don't see why a client should not be able to say, send me less stuff, I don't care about small desyncs. The client knows best how much download bandwidth he has and it doesn't make sense if the server admin forces the client to receive more than the connection of the client can handle.
I sort of agree with this, but then are we wanting to make clients be able to play ST on 512kbit connections? Also, should precision be enabled by default? I wouldn't feel warm and fuzzy about players joining games where their settings having turned off precise spawning of projectiles. That seems like a cheap way to cut bandwidth down on people who don't even know such a setting exists. |
|
|
|
|
|
Your patch intentionally desyncs the ZDoom flags of the actor between clients and server which IMHO is a bad idea. The other code is written under the assumption that these flags are synced and since all other code handles it this way, the server can easily overwrite the client flag change you added. Note that the special Skulltag flags are intentionally not synced between client and server. |
|
|
|
(0003502)
|
|
TIHan
|
2012-04-30 01:18
(edited on: 2012-04-30 02:50) |
|
> Your patch intentionally desyncs the ZDoom flags of the actor between clients and server which IMHO is a bad idea. The other code is written under the assumption that these flags are synced and since all other code handles it this way, the server can easily overwrite the client flag change you added. Note that the special Skulltag flags are intentionally not synced between client and server.
Ok, I understand what you are saying. I agree.
I have noticed another problem with the hit detection on floors/ceiling. Projectiles with bounce just get stuck in floor and ceiling. I understand why.
|
|
|
|
(0003505)
|
|
TIHan
|
|
2012-04-30 02:45
|
|
|
|
|
|
|
The patch looks very clean now, how well it works is hard to say though just looking at the diff. How did you test how well it works? |
|
|
|
(0003841)
|
|
TIHan
|
|
2012-06-24 15:44
|
|
Thanks for the review.
I tested by having heavy packet loss and firing non-bouncing missiles to see if they indeed go through actors, walls, ceilings, and floors; which they did when I tested it.
Note: The hit detection for ceiling and floors are separate from actors + walls. |
|
|
|
|
|
Alright, I added you patch, still can't confirm how well it works though. Thus this should be thoroughly tested in the next beta build. |
|
|
|
|
|
Unfortunately 0000718:0003505 introduced two serious problems 0000912 and 0000914. Both should be fixed now, but please test this very thoroughly in the next beta build to make sure that we found and fixed all adverse side effects the fix introduced. |
|
|
|
(0004045)
|
|
Qent
|
|
2012-07-22 17:19
|
|
|
I get "CLIENTDEMO_ProcessDemoHeader: Expected CLD_DEMOSTART" when trying to play the demo in 98d. What version is it in? |
|
|
|
|
Quote from "Description"
Done with r3417.
ie old skulltag 98e beta r3417. |
|
|
|
|
|
Since you recorded the demo, you should know how to reproduce the problem ;). So can you try if this is still broken in the latest beta build? |
|
|
|
|
|
Hmmm... I wasn't able to reproduce the problem with the latest beta. It seems like the fix works :) . |
|
|
|
|
|
Alright, then let's assume that it's fixed. :) |
|
projbug.cld (61,043) 2012-03-25 21:02
Screenshot_Doom_20120328_051153.png (129,449) 2012-03-28 03:15