0000705: Projectile Nudge

Notes
(0002805) TIHan (reporter) 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 (developer) 2012-03-12 10:17 edited on: 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 (reporter) 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 (developer) 2012-03-12 15:01	About the name, I myself called it "projectile prediction" when I was thinking about it.

(0002812) Torr Samaho (administrator) 2012-03-13 00:15	>'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 (reporter) 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.

(0002814) Torr Samaho (administrator) 2012-03-14 00:38	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 (reporter) 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 (reporter) 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 (developer) 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).

(0010412) Torr Samaho (administrator) 2014-10-09 06:13	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 (reporter) 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 (developer) 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 (developer) 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.

(0010432) Torr Samaho (administrator) 2014-10-09 19:23	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 (developer) 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?

(0010438) ZzZombo (reporter) 2014-10-09 21:48	Watermelon, but what if A_Recoil(ACS_ExecuteWithResult(...)) used?

(0010439) Watermelon (developer) 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.

(0010855) Watermelon (developer) 2014-11-11 03:04	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.

(0010863) ZzZombo (reporter) 2014-11-11 08:18	So the server will then have to validate every action function used on the projectile? That makes no sense.

(0010879) Watermelon (developer) 2014-11-13 03:59	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?

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

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	View Revisions
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	View Revisions
2012-03-13 10:17	TIHan	Note Edited: 0002813	View Revisions
2012-03-13 11:10	TIHan	Note Edited: 0002813	View Revisions
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	View Revisions
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	View Revisions
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	View Revisions
2014-10-09 16:06	Watermelon	Note Added: 0010426
2014-10-09 16:07	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:08	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:09	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:12	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:13	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:14	Watermelon	Note Edited: 0010426	View Revisions
2014-10-09 16:16	Dusk	Note Added: 0010427
2014-10-09 16:19	Watermelon	Note Edited: 0010426	View Revisions
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	View Revisions
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	View Revisions
2014-10-09 22:00	Watermelon	Note Edited: 0010439	View Revisions
2014-10-09 22:00	Watermelon	Note Edited: 0010439	View Revisions
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 =>

Relationships