MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000705 | Zandronum | [All Projects] Suggestion | public | 2012-03-12 06:32 | 2024-05-14 06:00 |
|
| Reporter | TIHan | |
| Assigned To | | |
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | new | Resolution | open | |
| Platform | | OS | | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0000705: Projectile Nudge |
| Description | This will be the last feature I will add before 98e is released. Until then, I will be doing pure bug fixing.
'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22projectile_nudge%22) [^]'
This is a variant of the original concept here:'http://www.ra.is/unlagged/walkthroughs.html#PN [^]'
The concept and implementation here is rather simple. When a missile is spawned, it will move ahead in time on the client based on what his ping is. This helps clients have a better chance to dodge missiles at high ping, 150-300.
Notes:
-Currently, it only works for projectiles that move in one direction, that means bouncing and seeking projectiles will not be nudged, for now.
-A client firing his own projectile will not be nudged.
-Very high pingers will notice visual anomalies such as projectiles going through enemies for half a second.
Future 99x+ plans:
-Seeker and grenade projectiles could be predicted.
-Moving sectors and doors could be predicted.
|
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2012-03-12 06:32 | TIHan | New Issue | |
| 2012-03-12 08:18 | TIHan | Note Added: 0002805 | |
| 2012-03-12 10:17 | Dusk | Note Added: 0002806 | |
| 2012-03-12 10:17 | Dusk | Note Edited: 0002806 | bug_revision_view_page.php?bugnote_id=2806#r1453 |
| 2012-03-12 13:19 | TIHan | Note Added: 0002807 | |
| 2012-03-12 15:01 | Dusk | Note Added: 0002808 | |
| 2012-03-13 00:15 | Torr Samaho | Note Added: 0002812 | |
| 2012-03-13 00:36 | TIHan | Note Added: 0002813 | |
| 2012-03-13 00:41 | TIHan | Note Edited: 0002813 | bug_revision_view_page.php?bugnote_id=2813#r1457 |
| 2012-03-13 10:17 | TIHan | Note Edited: 0002813 | bug_revision_view_page.php?bugnote_id=2813#r1458 |
| 2012-03-13 11:10 | TIHan | Note Edited: 0002813 | bug_revision_view_page.php?bugnote_id=2813#r1459 |
| 2012-03-14 00:38 | Torr Samaho | Note Added: 0002814 | |
| 2012-03-14 05:53 | TIHan | Note Added: 0002815 | |
| 2012-03-17 20:57 | TIHan | Note Added: 0002823 | |
| 2012-03-17 20:58 | TIHan | Note Edited: 0002823 | bug_revision_view_page.php?bugnote_id=2823#r1461 |
| 2014-06-11 21:20 | Watermelon | Status | new => acknowledged |
| 2014-10-09 00:11 | Watermelon | Assigned To | => Watermelon |
| 2014-10-09 00:11 | Watermelon | Status | acknowledged => assigned |
| 2014-10-09 00:14 | Watermelon | Note Added: 0010399 | |
| 2014-10-09 00:17 | Watermelon | Note Edited: 0010399 | bug_revision_view_page.php?bugnote_id=10399#r5620 |
| 2014-10-09 06:13 | Torr Samaho | Note Added: 0010412 | |
| 2014-10-09 12:05 | ZzZombo | Note Added: 0010420 | |
| 2014-10-09 12:06 | ZzZombo | Note Edited: 0010420 | bug_revision_view_page.php?bugnote_id=10420#r5628 |
| 2014-10-09 16:06 | Watermelon | Note Added: 0010426 | |
| 2014-10-09 16:07 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5630 |
| 2014-10-09 16:08 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5631 |
| 2014-10-09 16:09 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5632 |
| 2014-10-09 16:12 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5633 |
| 2014-10-09 16:13 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5634 |
| 2014-10-09 16:14 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5635 |
| 2014-10-09 16:16 | Dusk | Note Added: 0010427 | |
| 2014-10-09 16:19 | Watermelon | Note Edited: 0010426 | bug_revision_view_page.php?bugnote_id=10426#r5636 |
| 2014-10-09 19:23 | Torr Samaho | Note Added: 0010432 | |
| 2014-10-09 20:23 | Watermelon | Note Added: 0010436 | |
| 2014-10-09 20:24 | Watermelon | Note Edited: 0010436 | bug_revision_view_page.php?bugnote_id=10436#r5640 |
| 2014-10-09 21:48 | ZzZombo | Note Added: 0010438 | |
| 2014-10-09 21:59 | Watermelon | Note Added: 0010439 | |
| 2014-10-09 21:59 | Watermelon | Note Edited: 0010439 | bug_revision_view_page.php?bugnote_id=10439#r5644 |
| 2014-10-09 22:00 | Watermelon | Note Edited: 0010439 | bug_revision_view_page.php?bugnote_id=10439#r5645 |
| 2014-10-09 22:00 | Watermelon | Note Edited: 0010439 | bug_revision_view_page.php?bugnote_id=10439#r5646 |
| 2014-11-11 03:04 | Watermelon | Note Added: 0010855 | |
| 2014-11-11 03:04 | Watermelon | Status | assigned => needs review |
| 2014-11-11 08:18 | ZzZombo | Note Added: 0010863 | |
| 2014-11-13 03:59 | Watermelon | Note Added: 0010879 | |
| 2016-04-10 19:25 | Dusk | Status | needs review => new |
| 2016-04-10 19:26 | Dusk | Assigned To | Watermelon => |
| 2024-05-14 06:00 | unknownna | Note Added: 0023697 | |
|
Notes |
|
|
(0002805)
|
|
TIHan
|
|
2012-03-12 08:18
|
|
|
I hate gold plating, but if this type of prediction could work with other stuff besides projectiles, projectile nudge could be called something else. Perhaps "Time Nudge" or "Client Prediction". |
|
|
|
(0002806)
|
|
Dusk
|
|
2012-03-12 10:17
|
|
I was thinking of doing this stuff at one point. Cool that you got it. I'd probably had done it wrong. :)
|
|
|
|
(0002807)
|
|
TIHan
|
|
2012-03-12 13:19
|
|
> I was thinking of doing this stuff at one point. Cool that you got it. I'd probably had done it wrong. :)
Thanks. But, this will definitely needs some review. :) Since it is short, it wont be bad to troubleshoot. |
|
|
|
(0002808)
|
|
Dusk
|
|
2012-03-12 15:01
|
|
|
About the name, I myself called it "projectile prediction" when I was thinking about it. |
|
|
|
|
>'http://www.ra.is/unlagged/walkthroughs.html#PN [^]'
Hmm, the first two sentences of your link say:
> So now, players are backward reconciled by 50ms for missile hit tests. That makes projectiles easier to use, but also harder to dodge.
This assumption is not true for Skulltag's unlagged code. In particular, the projectile nudging will make it even more difficult for people with high ping to hit other players with missiles (admittedly it will make it more difficult to hit for everybody). I'm not really sure if it is desirable to have projectile nudging without projectile backward reconciliation. |
|
|
|
(0002813)
|
|
TIHan
|
2012-03-13 00:36
(edited on: 2012-03-13 11:10) |
|
Maybe the term "variant" wasn't a good one. I should have said "similar". It doesn't do exactly what that site says, but its where I got the idea.
> This assumption is not true for Skulltag's unlagged code. In particular, the projectile nudging will make it even more difficult for people with high ping to hit other players with missiles (admittedly it will make it more difficult to hit for everybody). I'm not really sure if it is desirable to have projectile nudging without projectile backward reconciliation.
I agree. I'm not ready to do backward reconciliation for projectiles just yet. Currently, the nudging doesn't affect the client firing his own projectile, so that hasn't changed. I mentioned this in the notes: "A client firing his own projectile will not be nudged." This means the difficulty of firing projectiles will be the same as before.
Projectile nudging may not be a good term. "Projectile Prediction" or we need a more general term, "Client Prediction". I did some testing on stuff besides projectiles, and it is very possible we could predict doors as well.
Edit:
In fact, Projectile Nudge is not the term we want. Projectile Prediction is perfect.'https://bitbucket.org/TIHan/tst/changeset/b5b4a66ac996 [^]'
I was trying to be ubiquitous with what I was reading on the unlagged site. I need to be careful on how I present and name features such as this properly. There can be some confusion and mis-communication.
To be more specific on what this does: Every projectile (non-seeking and non-bouncing) will be predicted for the client. This makes it where the client has a better chance to dodge a projectile. Also, the client's own projectile will not be predicted.
|
|
|
|
|
Let me rephrase what I said: Your code is supposed to make projectiles easier to dodge, right? And of course if projectiles are easier to dodge for you, you can also say that it's more difficult for the others to hit you.
The site you cited had an additional approach that makes it easier to hit. And they reason that the "easier to hit" part balances with the "easier to dodge" part. And I'm wondering if you actually want to have one of these without having the other one. |
|
|
|
(0002815)
|
|
TIHan
|
|
2012-03-14 05:53
|
|
> The site you cited had an additional approach that makes it easier to hit. And they reason that the "easier to hit" part balances with the "easier to dodge" part. And I'm wondering if you actually want to have one of these without having the other one.
Now I understand what you are saying. Hope you are not frustrated... :(
In that case, there are only two things we can do. We could either try lag compensating projectiles by 50 or x ms, or - we do not predict player projectiles at all, just monster projectiles.
Which would you prefer? |
|
|
|
(0002823)
|
|
TIHan
|
2012-03-17 20:57
(edited on: 2012-03-17 20:58) |
|
I've updated this to the latest codebase and made a change where projectiles will not be predicted if it came from a player.
I did make an attempt to try lag compensation for projectiles - there are two ways you can do it. On the unlagged site, projectiles are lag compensated 50ms at every tick of a projectile. Another way is to only compensate 200ms of a projectile's life from where it spawned. Both these methods are real CPU hogs. Especially if you try to lag compensate projectiles against monsters. Following Valve's footsteps, do not lag compensate projectiles at all.
|
|
|
|
(0010399)
|
|
Watermelon
|
2014-10-09 00:14
(edited on: 2014-10-09 00:17) |
|
This was discussed on IRC.
What is the desired behavior we want?
- Clients see their projectiles come out predicted?
- Other clients can choose how much they want to nudge it (0.0f means no nudging, 1.0f means it's nudged to a predicted position so they player can respond to it as need be based on their gametic/ping behind the server)
- Is there a way to make them not be rendered through walls? When I implemented this into my own custom build, they would be rendered through walls until the explosion on a wall was sent
--------------------------
I'd like to note that trying the method I've described (ticking the projectile by how many tics you're behind the server) makes it much easier to dodge at higher ping (150+). The current way, you can actually run into a rocket and watch it go through you, or pass a rocket and still get it. When I had the client using max prediction (a nudge of 1.0f), it was synced up perfectly. The only issue was that you'd not see it fired out of the body. However, users can adjust the slider bar to get the best of both worlds (a bit better prediction without too much x/y/z changing).
|
|
|
|
|
Quote from Watermelon
What is the desired behavior we want?
See 0000705:0002814. I still think that projectile nudging alone is not too desirable. |
|
|
|
(0010420)
|
|
ZzZombo
|
2014-10-09 12:05
(edited on: 2014-10-09 12:06) |
|
I don't think this is a great idea at all. How can you determine if a missile uses weaving, speed changing, etc? Also some missiles are fake. I use a lot of +MISSILE tagged actors just to keep track of the owner and do stuff on it like repeatedly give it health and armor if I don't want to involve ACS scripting. Some missiles only live for a tic to move Speed distance and do something at that place and remove itself (like placing an actor there at a radius of the shooter+radius of the thing away from owner, simulating A_SpawnItemEx() but if it collides with anything nothing will be spawned, useful to check for lack of space and attempt again later).
You could, however, check if a projectile is a default stock missile, and apply the code to them, since most of them are linear, but, again, not all.
|
|
|
|
(0010426)
|
|
Watermelon
|
2014-10-09 16:06
(edited on: 2014-10-09 16:19) |
|
Quote
See 0000705:0002814. I still think that projectile nudging alone is not too desirable.
I read over everything above multiple times, so can you confirm if I'm missing something:
- Missiles are sent to the clients with the offset of tics the client should do based on their gametic offset (requires gametic unlagged), or the last client gametic can be sent back, divide that by 2 and advance by that (this would be more stable in case a packet gets toasted on the wire)
- Client multiplies this difference by their requested nudge factor (0.0f to 1.0f) and then cast to an int to round down
Example, if the client wants a nudge factor of 0.5, if the client is 6 tics behind, then it would only predict it by 3 tics
- Client performs the ticker on the missile by the number of ticks it is behind based on the above calculation
Therefore it shouldn't be harder for people to hit others since the actual actor itself isn't being reconciled or anything, it's just being pushed to its predicted position on the client. There would be no reconciliation on the server. It makes it easier to dodge since you know it's exact position relative to your client and can move out of the way without appearing to have moved out of the way, see the rocket pass you, and kill you even though your client's prediction shows you're out of the way.
Other clients do not have to adjust their aiming, as the server stays completely unchanged.
Am I possibly missing anything?
Also I have tested this in my custom builds I made for the community and it worked great for high ping. There was no issues hitting anyone.
Also check the last part of this ticket post.
Quote
I don't think this is a great idea at all. How can you determine if a missile uses weaving, speed changing, etc? Also some missiles are fake. I use a lot of +MISSILE tagged actors just to keep track of the owner and do stuff on it like repeatedly give it health and armor if I don't want to involve ACS scripting. Some missiles only live for a tic to move Speed distance and do something at that place and remove itself (like placing an actor there at a radius of the shooter+radius of the thing away from owner, simulating A_SpawnItemEx() but if it collides with anything nothing will be spawned, useful to check for lack of space and attempt again later).
You could, however, check if a projectile is a default stock missile, and apply the code to them, since most of them are linear, but, again, not all.
This is a good point, I only tested this with rockets.
Note that this won't affect serverside stuff. For example, if you're using it for 'can we spawn this', the client isn't supposed to see that anyways and it won't matter on their end. Nothing is predicted on the server end and all projectiles will act the exact same as they do now. The only difference is the client would render projectiles to where it would be as if they had 0 ping.
For this, I propose there would be a +CLIENTSIDEINTERPOLATE flag that mod users can add to projectiles that only go straight or do predictable patterns.
I also think it should be (if it worked out well) the default behavior for vanilla projectiles like the rocket/plasma/bfg without using the new flag, since it's likely people have inherited from these and added decorate functions that change it.
Since this may be confusing, what I mean is that we hardcode the rocket/plasma/bfg/hexen/heretic/strife weapons that can be interpolated to automatically interpolate... without attaching the flag. This way any inherited mods don't have this flag accidentally on them, but projectiles we know that are safe to interpolate can be done so by the client if they wish.
Now since the projectile is ticked, that means any velocity actions or anything that is deterministic should still be fine. Let us take this example:
Quote
MISL A 3
MISL B 1 A_Recoil(100)
MISL C 3
Let's say we are far behind the server, maybe 5-6 gametics. When we get the projectile, we will run the ticker 5-6x. This will put it in state MISL C. Since the ticker is being run and A_Recoil is a deterministic function that doesn't rely on world input (like ACS_Execute(...) would), the client can correctly predict it's location since it will still perform the ticking of the MISL B state and sum up it's velocity/position/etc.
Therefore anything like weaving or non-tracer stuff (maybe tracers could work? I'm not sure) or anything deterministic should be fine to use.
Interestingly, this should still be possible to do if a projectile gives you health because the server will be handling the decorate code, and it will send you the health updates (the client wont be predicting that). However I'm fairly sure there are definite cases where predicting the missile would yield a desync, and propose that a flag is used.
======================================================
1)
For compatibility reasons: people will by default have projectile prediction by default to 0.0f so there won't be any difference between what we currently see and if this is implemented. This was the default on my client and everything acted normal.
2)
A problem here is that the projectile is instantly ticked into position. There are two ways to go about this, but I need input on what would be the best
- Let it just be a consequence of players selecting to use prediction (for me, I'd be fine with this because the benefits highly outweigh the negatives)
- Add in a ticbuffer on the client for projectiles that would act like the ticbuffer Torr added -- FURTHERMORE: can be expanded so the client can select how much they'd like to advance it per tick (
- Have it sum up the delta x/y/z and perform that in one tick -- which would make it wonderfully smooth for straight projectiles, but would look bad for weaving projectiles... this could also be another decorate flag though, not that I'm proposing we flag every little case.
3)
Is a projectile being rendered behind a wall a bug? For some reason when you tick it ahead it gets rendered behind walls if you're lagging bad (200+ ms).
4)
I haven't looked at clientside missile prediction of when the client fires. This would only be doable if the decorate flag I propose is accepted for the same reasons that we can't apply this to every projectile.
|
|
|
|
(0010427)
|
|
Dusk
|
|
2014-10-09 16:16
|
|
|
Here comes a crazy idea. Perhaps we can execute the first (ping/ticrate) tics of the spawned missile on the client when the missile gets spawned? This would cater for non-straight moving missiles, at the potential risk of possibly breaking some missiles on the client-side when heavy scripting is involved. |
|
|
|
|
Quote from Watermelon
Am I possibly missing anything?
I think you are missing what I tried to say with the following:
Quote from Torr Samaho
if projectiles are easier to dodge for you, you can also say that it's more difficult for the others to hit you.
Clients don't have to adjust their aiming, but this feature still considerably reduces their chances to hit because the opponents can avoid being hit easier.
Currently, both your ability to hit somebody with a missile and to avoid missiles are hampered by your ping. With the nudging, at least under perfect conditions, you can evade projectiles as if you had a ping of 0. When trying to hit somebody, you are still fully hampered by your ping. From this perspective, the nudging creates an imbalance. |
|
|
|
(0010436)
|
|
Watermelon
|
2014-10-09 20:23
(edited on: 2014-10-09 20:24) |
|
Quote
Clients don't have to adjust their aiming, but this feature still considerably reduces their chances to hit because the opponents can avoid being hit easier.
Currently, both your ability to hit somebody with a missile and to avoid missiles are hampered by your ping. With the nudging, at least under perfect conditions, you can evade projectiles as if you had a ping of 0. When trying to hit somebody, you are still fully hampered by your ping. From this perspective, the nudging creates an imbalance.
For this:
- The laggy player would already be suffering from the nudge placing it ahead, so they are still at a disadvantage even with prediction. The laggy player must deal with collision issues, shooting second, dying when he's behind a wall, and probably a lot of other things that are much more painful than any bonus this feature would add.
- Doesn't this go against the philosophy of trying to improve the gameplay?
- Unlagged creates an imbalance because you can shoot people behind walls and have to learn to juke according to the other players ping, that would also fit the 'imbalance' area but it was added anyways to help improve gameplay. Would this be any different?
- What about coop monsters where there is no competitive nature?
|
|
|
|
|
|
Watermelon, but what if A_Recoil(ACS_ExecuteWithResult(...)) used? |
|
|
|
(0010439)
|
|
Watermelon
|
2014-10-09 21:59
(edited on: 2014-10-09 22:00) |
|
I was thinking more about this: doesn't the server have to send the velocity regardless to update the projectile? Regardless, I still think it's probably unsafe and should be marked with a decorate flag if this is to be implemented for mod usage.
It would be really interesting to see prediction with something like A_Recoil(ACS_...) and how it works on tracers. Hopefully I can get results soon.
Nonetheless, I'm not willing to even remotely think of claiming it safe to implement for all projectiles, even if the tests come back that its okay.
|
|
|
|
|
I'd need some input on this:
What if projectiles could have a flag like +PREDICTABLE put on them which would allow the server to allow prediction for some projectiles? This way if anyone does any weird action events, a warning could be issued. |
|
|
|
|
|
So the server will then have to validate every action function used on the projectile? That makes no sense. |
|
|
|
|
Quote
So the server will then have to validate every action function used on the projectile? That makes no sense.
Where did I say that? |
|
|
|
|
Hey, sorry for bumping this. Coming from someone who used to play a lot of survival back in the day, this feature would be mostly appreciated in coop/survival modes where the nudging would allow you to dodge monster projectile attacks better if you ping, say 140-150 compared to others at 40-50. Having the monster projectiles shifted forward to compensate for the higher ping would help other players with surviving a lot better, and actually be very cool to have.
For competitive modes, maybe nudging other players' rockets etc. could be nice, but I don't think many would like to have their own projectiles nudged, as that would make the tactile weapon feedback feel odd and inconsistent between different games on different servers.
And the nudging would ideally only be purely visual, nothing else, to help you dodge incoming attacks better. |
|