135 replies to this topic

[Matthew Craig]

Red squirrel, on 15 January 2013 - 11:09 AM, said:

With server side auth. players might create lag on purpose to get an advantage? If so what can you do about it?

Can you clarify a bit, creating lag shouldn't infer any particular advantage you should be just as easy to hit (once the net-code is fully addressed) if you are lagging as not lagged. All you'd be doing is reducing your own quality of experience and by the time your client catches up your Mech will likely be toast.

[StalaggtIKE]

Bagheera, on 15 January 2013 - 09:36 AM, said:

Whoah.

This thread is way above my pay grade.

I find this thread to be quite sexah.

[Pando]

How I wish the Q&A session was answered close to the speed questions are being answered here

[wish]
Here goes nothing
[/wish]

[vonWeber]

excellent read. thanks to all contributers.

[pesco]

Matthew Craig, on 15 January 2013 - 09:56 AM, said:

It's also called lag compensation here's a good article for those interested by some guys who know a thing or two

https://developer.va...ag_compensation

Great to hear about state rewinding!

Are you going to do (or are you already doing) client-side prediction?

I also wonder:
How do you determine the point in time at which a shot was fired? Do you just take half of ping (round-trip time) as measured by the server?

[Chief 117]

Matthew Craig, on 15 January 2013 - 10:40 AM, said:

Once we're out of open beta the lag shield issues will be a fading memory

I will take your word for it.

[Mawai]

stjobe, on 15 January 2013 - 09:41 AM, said:

It's important to realize that this state rewinding is for hit calculation purposes only, it has no bearing at all on where your 'mech is or seems to be in the game, nor where your target is or seems to be.

Basically, as others have said, when you pull the trigger and send a "fire!" command to the server, it checks where you and your target was at the time of firing and whether your shot would hit. AFAICT it doesn't move either you or your enemy around at all, that's another piece of code that's responsible for that.

Yep - the hope is that your client will have done a good enough job of drawing the target where it should have been so that you don't have to aim in front of it to hit it. On the other hand, since it is still server authoritative, there is no guarantee that where the mech is drawn on the client will actually be where the target is on the server when the shot is fired ... but this should help eliminate the effect of the lag of the target to the server.

If you have a low ping then the target mech should be drawn relatively closely to where the server thinks it is at that moment in time and firing at that position should result in a hit ... though this will depend somewhat on how the server deals with updating positional information from the target mech ... if the target client has a lot of lag the server estimate of its position for resolving fire will lag behind where the target's client thinks it is ... a key element to this technique will be how the server updates the target mech position when resolving fire.

Positional data on the server is essentially a set of discrete points along a time line ... updated with a specific frequency. Variable lag causes the spacing of these points to vary. The algorithm the server uses to connect these dots will be crucial in getting this technique to work ... especially since the server estimated position of a lagged mech just before a positional update is unlikely to agree with the actual reported mech position in that update. The client on the firer is likely displaying the same estimated mech position as is calculated on the server ... but when the positional update of the target arrives on the server it may change the actual position of the target going back along the time line depending on the implementation.

The choices would appear to be ...
1) The server calculates the target mech position based on last reported position + prediction ... this is used by both the firing client and the server to determine hits ... actual target position doesn't matter until the next update from the target client. This will make mechs with high lag more vulnerable to fire and will eliminate the benefits of intentionally adding lag to make yourself harder to hit.

2) The server updates the mech track every time new positional data becomes available and interpolates backward in time to connect the dots. In this case, the firing client drawing of the mech position may be less accurate and it may be harder to register a hit.

Its a knotty problem any way you look at it .. presumably, they already have code that given the mech position and facing determines the details of hits and the key element here is coming up with an algorithm to determine the positions of the firing and target mechs at the moment the fire button is pressed ... and making this determination as close to the client side representation as possible while still be server authoritative.

[Matthew Craig]

pesco, on 15 January 2013 - 11:24 AM, said:

Great to hear about state rewinding! Are you going to do (or are you already doing) client-side prediction? I also wonder: How do you determine the point in time at which a shot was fired? Do you just take half of ping (round-trip time) as measured by the server?

Already doing basic client side prediction. Determining the point in time a shot was fired is a combination of ping and time stamps.

[FrDrake]

pesco, on 15 January 2013 - 11:24 AM, said:

Great to hear about state rewinding!

Are you going to do (or are you already doing) client-side prediction?

I also wonder:
How do you determine the point in time at which a shot was fired? Do you just take half of ping (round-trip time) as measured by the server?

Packets are generated at a point in time that can be included as timestamp data. I guess eventually someone could write a packet generator that gave false timestamps but I don't immediately see how that would give them an advantage.

*Edit ^ he beat me to it.

Edited by FrDrake, 15 January 2013 - 11:37 AM.

[Johnny Morgan]

Matthew Craig, on 15 January 2013 - 11:16 AM, said:

Can you clarify a bit, creating lag shouldn't infer any particular advantage you should be just as easy to hit (once the net-code is fully addressed) if you are lagging as not lagged. All you'd be doing is reducing your own quality of experience and by the time your client catches up your Mech will likely be toast.

I love you man!

[VonRunnegen]

(I know very little about net-coding so anyone wanting real info ignore me!)

As we take the clients time stamp for when things happen this is where lag can be an advantage in theory - were we to use client events but at the time the server receives them then lagging would only be a disadvantage no? Then again, it would make the experience rather more horrible on a laggy connection and with the current server setup that would be bad.

I'm still surprised given the fragmented nature of matches that there arn't nicely distributed servers all over the shop - though I guess player density could be an issue? That said, you could farm out game requests if not enough on your local node...

(Again, I don't know what I'm talking about, it just sounded good in my head....)

[Jman5]

Are you guys worried at all that once most of the net-code problems are resolved, light mechs will lose a huge chunk of their survivability?

[Matthew Craig]

Jman5, on 15 January 2013 - 11:50 AM, said:

Are you guys worried at all that once most of the net-code problems are resolved, light mechs will lose a huge chunk of their survivability?

Not in the slightest that's designs problem

[Codejack]

Matthew Craig, on 15 January 2013 - 11:35 AM, said:

Already doing basic client side prediction. Determining the point in time a shot was fired is a combination of ping and time stamps.

Ah, so you've just made it REALLY easy to cheat. Combine that with the fact that the netcode problem has nothing to do with ping, and you've just explained why nothing works.

[redacted]

Edited by miSs, 15 January 2013 - 01:52 PM.

[Hillslam]

Jasen, on 15 January 2013 - 10:59 AM, said:

If we're actually getting this reply - a short part on the same for Tech5 would be interesting... hell, even source.

My guess would be the CryEngine's advantage with viewDistance capability over Tech5's.

Ditto over the UT engine.

Jman5, on 15 January 2013 - 11:50 AM, said:

Are you guys worried at all that once most of the net-code problems are resolved, light mechs will lose a huge chunk of their survivability?

In a word: NO

I cannot think of ANYONE who is "worried" about that aside from exploiting losers.

Once the world behaves with internal consistency as it should then all mech's roles will setlle down to what their roles should be. AKA - lights will no longer be lightspeed knife-wielding impregnable assassins, but will be SCOUTs and stay OUT of the battleline as they should. Role appropriate.

After all, Destroyers and Frigates didn't go away when Battleships appeared did they?

Edited by Hillslam, 15 January 2013 - 12:06 PM.

[Matthew Craig]

Codejack, on 15 January 2013 - 12:00 PM, said:

Ah, so you've just made it REALLY easy to cheat. Combine that with the fact that the netcode problem has nothing to do with ping, and you've just explained why nothing works.
 [redacted]

And I'm done answering questions for the day (enjoy the patch everyone)

Edited by miSs, 15 January 2013 - 01:50 PM.
quote clean-up

[Sprouticus]

Ilwrath, on 15 January 2013 - 09:44 AM, said:

Do they happen when the mech is not under fire at all? At first I was thinking that they where overheating somehow.

Heat based ammo explosions as well.

[Bilbo]

Codejack, on 15 January 2013 - 12:00 PM, said:

Ah, so you've just made it REALLY easy to cheat. Combine that with the fact that the netcode problem has nothing to do with ping, and you've just explained why nothing works.

[redacted]

Codejack, on 15 January 2013 - 12:06 PM, said:

deleted

This, right here, is why we can't get any more community involvement from the devs than we do.

Edited by miSs, 15 January 2013 - 01:41 PM.
quote clean-up

[Codejack]

Bilbo, on 15 January 2013 - 12:12 PM, said:

This, right here, is why we can't get any more community involvement from the devs than we do.

Given the "community involvement" that we receive, I'm just as happy about that.

Seriously, do you enjoy it when corporate stooges are marched out to BS you?

[somedood]

Codejack, on 15 January 2013 - 12:00 PM, said:

Ah, so you've just made it REALLY easy to cheat. Combine that with the fact that the netcode problem has nothing to do with ping, and you've just explained why nothing works.

Do you people know even the first ****ing thing about games?!

What are you talking about? He just explained the reason why latency is currently a problem, why they chose the server-authoritive approach and what they are doing to adjust for latency to fix it in the future. Obivously latency is a problem right now, and a user that has varying latency causes problems right now, but the fixes will address those issues so that they will no longer be a problem (or at least a very minor problem compared to now).

Everything he posted made complete sense and you're just being a complete jerk, how is that helping anything?