Netcode and rockets

This video show what I mean. (Recorded in real time with fraps at 100 fps)

Rockets feels more and more laggy to get hit by, the higher ping you have. As you see in the video, when you have 0 ping they are smooth and awesome. But with higher ping and in slow motion it looks like you get a fps drop. If it's possible maybe client should predict when rockets/nades will explode. So the knockback from rockets will feel more like 0 ping. Just a wish for further versions.
(updated 2012-06-26 08:54:57)

It's because of rockets being client-side-predicted that the push feels lagged. It's not possible to remove latency, all it's possible to do is to choose the place where it's less disturbing, and in this case that was my choice. At least this way you see the rocket flying in the right place for being able to dodge it.
(updated 2012-06-26 10:42:25)

if im not wrong, remembering the wsw code, the rockets antilag code is not even enabled due to some weird feeling with the weapon. Correct me if i'm wrong.

Jal is the knockback also predicted. Or do my client get it from server when to get popped up in to the air. It seems like the higher ping you have the more steps in the knockbakck path you skip in the beginning. Just wondering.

Koochi wrote:
if im not wrong, remembering the wsw code, the rockets antilag code is not even enabled due to some weird feeling with the weapon. Correct me if i'm wrong.

I think it has the offset code, that it calculates the distance the rocket would have travelled according to your ping and then gives enough offset for the rocket to compensate the ping (so the rocket spawns further away from the launcher)

But nothing else.

hugteddy wrote:
Jal is the knockback also predicted. Or do my client get it from server when to get popped up in to the air. It seems like the higher ping you have the more steps in the knockbakck path you skip in the beginning. Just wondering.

Predicting the knockback is not reliable enough. Chances of misspredicting are too big, and misspredictions result in huge corrections.

Such prediction would be worth making in a game where players move at normal speeds and stay on ground most of the time, but in a game where the player will be moving on the air at above 700ups any minimal mistake can result in predicting a totally diferent pushing angle giving very ackwards corrections.

EDIT: I honestly think there isn't much that can be done to improve wsw's netcode. It's as good as a netcode can be and I haven't seen a game with a better one yet.

Huksi` wrote:

I think it has the offset code, that it calculates the distance the rocket would have travelled according to your ping and then gives enough offset for the rocket to compensate the ping (so the rocket spawns further away from the launcher)

But nothing else.

That's what the server does to compensate the time since you clicked the fire button until it got to the server.

What the client does is render the rocket at the proper position based on the initial fire time and projectile velocity. Time in the client is ping-compensated so the rocket representation is properly balanced for fitting client prediction.
(updated 2012-06-27 13:40:25)

from those videos i actually thought that the delay wasnt really that noticable at all... and ye, the warsow netcode is smooth as hell. i remember when cpm netcode was the big deal - but after recent experience with both, i can certainly say that the wsw one feels more responsive to me.
(updated 2012-06-27 14:02:49)

thelawenforcer wrote:
from those videos i actually thought that the delay wasnt really that noticable at all...

Well, actually those videos are probably taken from demos and the delay isn't so noticable in demos, but it is when playing and I did understand what he meant cause it also pisses me off a little :)

When playing the client is predicting our player movement, and those pushes create a missprediction with their corresponding prediction correction. The correction is what makes it feel ackwards. The bigger the ping, the bigger the amount of prediction we were using so the bigger the correction.

In theory predicting the push would remove these misspredictions, but unfortunately there's a limit on how far we can go with prediction, and trying to predict the push would be based on predicted data (both, the player and the rocket) making it not reliable enough. The micro-innacuracies accumulate, and the errors to predict this would lead to corrections way much bigger than the actual ones. Also, the actual ones are ok on average pings, they only start getting really noticable above 80 ping or so.
(updated 2012-06-27 16:48:45)

ah that does explain it about the video because i was indeed thinking that surely it would be more noticable than in the video as if i play highping i definately notice a delay.

seeing as i play mostly under 50 ping tho, i've never really had an issue with the delay at all.

the warsow system works very well in the conditions that the game is meant to be played in, but whatever system you choose there will always be downsides/upsides. i think this mix is better than the old quake style where it was all server side or the battlefield3 style which is entirely client side. its 'fair'
(updated 2012-06-27 15:08:46)

I do agree with thelawenforcer. And I do love the wsw netcode and now I love it even more when you explained that Jal. Thanks for explaining. You learn something new each day :)
(updated 2012-06-27 21:32:25)

Hey, Jal, I would like to learn, is there any difference between "anti-lagging" and "prediction"?)

There probably is as 'antilag' will be many possible solutions to reducing influence of ping, prediction being one of them.

adem wrote:
Hey, Jal, I would like to learn, is there any difference between "anti-lagging" and "prediction"?)

They are complementary things. Putting it very simplified:

Both the client and the server work always with outdated data. The server works with outdated client data, the client works with outdated server data.

Prediction is about the client guessing how the outdated server data would look in the present time. Because the client must represent the present as close as possible, there's no other choice.

Antilagging is about the server remembering how the server data looked when the outdated client data was happening (in this case we can work with real data by moving our world back in time).
(updated 2012-06-28 14:55:29)

jal wrote:
trying to predict the push would be based on predicted data (both, the player and the rocket) making it not reliable enough.

Why so ? The client have all the data here : the rocket position and his own position are perfectly predictable from last recieved game state, so i would think you can reliably predict push as well...

Am i missing something ? Is it the timestamp that have error on it or all entities prediction behave the same way and that would make it unreliable when knocking a (loosely predicted) opponent ?

jal wrote:
EDIT: I honestly think there isn't much that can be done to improve wsw's netcode. It's as good as a netcode can be and I haven't seen a game with a better one yet.

In general, yes, but i miss a few features, like teleport prediction, picking prediction...
(updated 2012-06-30 23:01:12)

Another question for you Jal.

What happens to the shoots I make while Im in the 35 ms gap where Im hit by a rocket, but my client shows that Im on the ground and it's waiting to get corrected? Do my rockets ebs lg whatever get corrected so I miss, because on server I was in the air?

As far as I know, since lg, rg, eb, and mg are hitscan, if you see yourself hit with them, you hit with them.
(updated 2012-07-21 20:30:06)

hugteddy wrote:
Another question for you Jal.

What happens to the shoots I make while Im in the 35 ms gap where Im hit by a rocket, but my client shows that Im on the ground and it's waiting to get corrected? Do my rockets ebs lg whatever get corrected so I miss, because on server I was in the air?

The server always has the final word. The shot will be in the pushed position.

But I don't want anyone to get a wrong idea from this. It is absolutely impossible that a player would move his mouse to adjust in the lapse of the missprediction,and the chances or the push making fail the shot in that lapse are really, really, really microscopical. We are talking about a very small time window here. The shot would be the same with or without push prediction, only the visualization of the EB trail would vary a bit, and not much.
(updated 2012-07-22 04:28:57)

jal wrote:

The server always has the final word. The shot will be in the pushed position.

But I don't want anyone to get a wrong idea from this. It is absolutely impossible that a player would move his mouse to adjust in the lapse of the missprediction,and the chances or the push making fail the shot in that lapse are really, really, really microscopical. We are talking about a very small time window here. The shot would be the same with or without push prediction, only the visualization of the EB trail would vary a bit, and not much.

That small correction can be the decision if you win or not in close combats. Microscopical time laps can decide if you hit that shot or not, especially if the difference form hit and miss is 1 px. 30 ms is enough time to move the shot 1 px to the right. Just saying.

But guess kb and stuff is what is the hardest to do equal, even if ping difference is high.

No it can't. As I said you would NEVER be able to correct after the impact is received. It's not enough time for the eye to pass the information to the brain, analize it and send it back to the arm. That's why I wanted to make it clear, cause I knew this would lead to wrong asumptions. The only change would be aesthetic. You percieve that glitche afterwards, you have no time to think while it's happening.

The real inconvenience here is that when getting the impact your brain keeps calculating based on the data it has, and then recieves a modifiction late, so it has to start recalculating later than it should.
(updated 2012-07-24 19:01:20)

jal wrote:
No it can't. As I said you would NEVER be able to correct after the impact is received. It's not enough time for the eye to pass the information to the brain, analize it and send it back to the arm. That's why I wanted to make it clear, cause I knew this would lead to wrong asumptions. The only change would be aesthetic. You percieve that glitche afterwards, you have no time to think while it's happening.

The real inconvenience here is that when getting the impact your brain keeps calculating based on the data it has, and then recieves a modifiction late, so it has to start recalculating later than it should.

There is a 2nd real inconvenience, you have less time to shoot than you think you do, because you are used to see a delayed knockback while the real one happen earlier than what you can experience. It is very possible to miss a shoot in that time window even if it's small, if you earlier took the decision judging you had enough time while you did not.

I also bump my question about why isn't it an exact calculation, if there is any precise reason ? I am aware that perfect client/server synch is not possible but I don't see why kb prediction can't be reasonably accurate even given the player speed, since we talk about such a small window as you said and that the angle most of the time will be much alike and probably that the correction would feel less awkward.