135 replies to this topic

[HC Harlequin]

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]

Client side movement prediction, Alexander Dumass
That means your client moves everyone's mech around smoothly based on their current speed/trajectory. message data is digital (that means it has distinct steps for people like you) whereas people view things analog (that means no distinct steps) So instead of having an object move like a freeze framed strobe light white boy it moves smooth along your screen.

[HC Harlequin]

The question I have is..
Since you HAVE to lead with ballistic trajectory weapons anyway, why is the range convergence still focused on what's under your target reticle instead of the target you have to lead. Why are my weapon's thinking they are shooting a target that may be 1500 meters away when the target is 5 meters in front of me?

AND, if I can't actually target a mech due to ECM then because they can't change the range convergence to match the target then how are the weapons convergence going to be addressed?

Because if the range convergence is going to be changed to "the current target" then ECM counters that
and if it remains the same then your ballistics are not hitting what you are aiming at (so why have convergence at all?)
or if it's a static range convergence set however it will be set is there a plan to implement that?

Range convergence as it is is a combination of netcode and ballistic trajectory issue. Even if they fix the netcode to have null impact on ballistic trajectory and range convergence there is still the issue of your rounds coming together at some other range besides the range to your target because you don't actually shoot at your target.. you deliberately lead them in front.

[Alex Wolfe]

TF2 uses this sort of lag compensation. Of course sometimes it means that you hide behind a wall, only to fall from headshot you were sure you'd be safe from half a second later. The overall gameplay experience feels very natural though, as long as your ping is in average levels - and on the other guy's screen the headshot was "legit", so it's not that big of an issue.

The occasional "lag compensation lol" shrug-worthy moments are preferable to constant frustration of having to shoot seventeen paces ahead of everything. I'm glad it's finally being looked at... only the part about "testing beginning in a few weeks" worries me a bit.

[N0MAD]

Ok just looking for information from people that are in the industry and may have legit answer. To me (an Aussie) Lag shield has never meant the number associated with ping latency eg, 50ms or 300ms i have always been able to compensate by leading a target (20 odd years of gaiming experience) the shield to me has always been my enemies packet loss where for instance i shoot say an AC slug its turned into a Packet but that packet is lost in cyber space due to poor internet or at times thru the use of packet editors (tsk,tsk). Does this new system in any way diminish the packet loss issue.
Thanks.

[Corvus Antaka]

with any luck thisll finally kill ballistic lag when shooting too.

[Countach]

Rokuzachi, on 15 January 2013 - 03:12 PM, said:

Blame Codejack all you want for 'running the dev off', but I've seen a lot of devs put up with much worse and still keep a smile on their face, instead of saying 'you've insulted me and now I'm taking my toys and going home'.

I don't expect much maturity from an online community (ever), but I'd like to think I can expect a certain amount of grace and maturity under fire from industry professionals that interact with the community.

The point is devs shouldn't have to "put up with much worse" at all for trying to come here and clarify things. People may have their criticism but if it's not constructive, you won't get anything out of it, what I mean by this was that there was no way the dev could say anything in response to codejack and have him (or anyone with the same mindset) happy and actually create a worse situation where they are either 1. ignoring posts 2. confusing people with too much information.

That being said, it could also have been a coincidence that the dev happened to be doing his last posts of the day when the comment came through and it became an appropriate time to sign off to make a point.

[VonRunnegen]

State-rewind is abusable with the client time stamping, its not true server-authoritative as some seem to think.

To demo: Lets say you know someone is coming towards where you are waiting round a corner. If you can delay your packets so they all go in a burst together then you can step out and shoot as as one burst without him ever having seen you.... the server will happily work out that you'd stepped from hiding before shooting in its rewind from the timestamps but as that info didn't reach the server until the same time as the shoot command there is no way for the other guy to know he was being shot at until after the event when you'll suddenly rubber-band out of cover and he'll have already taken damage.

[ElLocoMarko]

VonRunnegen, on 16 January 2013 - 05:15 AM, said:

State-rewind is abusable with the client time stamping, its not true server-authoritative as some seem to think.

To demo: Lets say you know someone is coming towards where you are waiting round a corner. If you can delay your packets so they all go in a burst together then you can step out and shoot as as one burst without him ever having seen you.... the server will happily work out that you'd stepped from hiding before shooting in its rewind from the timestamps but as that info didn't reach the server until the same time as the shoot command there is no way for the other guy to know he was being shot at until after the event when you'll suddenly rubber-band out of cover and he'll have already taken damage.

This sounds pretty mild. Especially since the server almost certainly controlling weapon cooldown (client-side would be bad). A cheater would get one alpha on target. To get two alpha's from high damage weapons like PPC or AC20... it would have to back-date the packets by 3000-4000 ms... State rewind has limits on how much it will apply before it throws the packets away.

Did I get it right?

[xenoglyph]

I asked about this very thing a month ago:
http://mwomercs.com/...g-compensation/

Glad to see they're doing it right.

[Matthew Craig]

Countach, on 15 January 2013 - 06:54 PM, said:

The point is devs shouldn't have to "put up with much worse" at all for trying to come here and clarify things. People may have their criticism but if it's not constructive, you won't get anything out of it, what I mean by this was that there was no way the dev could say anything in response to codejack and have him (or anyone with the same mindset) happy and actually create a worse situation where they are either 1. ignoring posts 2. confusing people with too much information. That being said, it could also have been a coincidence that the dev happened to be doing his last posts of the day when the comment came through and it became an appropriate time to sign off to make a point.

It was essentially both, when a thread get's inflammatory pretty much any response only adds fuel to the fire so the best course of action is to calmly walk away, plus we always have work to be doing.

The other reason is that the conversation is getting to the point where we're essentially discussing ongoing development work which means anything I add could be invalidated in a few days time if we alter our approach etc. but I'll be happy to update again more of how the system works when the work has been completed and tested.

[xenoglyph]

VonRunnegen, on 16 January 2013 - 05:15 AM, said:

State-rewind is abusable with the client time stamping, its not true server-authoritative as some seem to think.

To demo: Lets say you know someone is coming towards where you are waiting round a corner. If you can delay your packets so they all go in a burst together then you can step out and shoot as as one burst without him ever having seen you.... the server will happily work out that you'd stepped from hiding before shooting in its rewind from the timestamps but as that info didn't reach the server until the same time as the shoot command there is no way for the other guy to know he was being shot at until after the event when you'll suddenly rubber-band out of cover and he'll have already taken damage.

First off, if I was making such a system, it would have maximum threshold of like +500ms or so. Mostly to limit resource consumption, but also to mitigate risk, and partly because you have to put the limit somewhere.

Seriously though, if somebody is talented enough to exploit that system in the manner you describe, they're talented enough to own the game any way they please. Technically you're right, it could be exploited. But does the system put the game at any greater risk of being exploited? I would say abolutely not.

[MechGorilla]

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

Not in the slightest that's designs problem

Great answer! (Coming from another programmer who also likes to shove the blame/responsibility to another team )

[Multitallented]

@Matthew Craig: Thanks for explaining this! I have been patiently waiting for this to get fixed, and I will continue to wait. Best of luck!

PS- as a light pilot, I am very excited about lag shields going away and knockdowns being put back in. Separate the wheat from the chaff.

[Havyek]

Rokuzachi, on 15 January 2013 - 03:12 PM, said:

Blame Codejack all you want for 'running the dev off', but I've seen a lot of devs put up with much worse and still keep a smile on their face, instead of saying 'you've insulted me and now I'm taking my toys and going home'.

I don't expect much maturity from an online community (ever), but I'd like to think I can expect a certain amount of grace and maturity under fire from industry professionals that interact with the community.

The point is that the devs, community co-ordinators, or whoever else decides to step in and answer questions shouldn't have to put up with that BS. Especially when that jackass can't even be bothered to ask a question or request clarification on something.

If you want to join a discussion, it's your responsibility to DISCUSS. Not antagonize.

[Kousagi]

This method will be good to completely kill lag shield, but at the same time it will open the doors for a new kind of cheating. Not going to list it here as I'm sure the dev's are aware of it. As there is a way to abuse this system, and its used in other MMO's/FPS's that use this same system.

So while this will kill lag shield, it also puts the higher ping players at a advantage, where currently low ping players have a advantage. Which I think they are seeing as fine so long as the lag shield itself is removed, giving everyone a better footing overall. This will be the death of light mechs pretty much.

[Tice Daurus]

What I'm wondering however if once this is put into place, will this remove the 'speed cap' that's currently in place now? Will this allow mechs to move past the 140KPH barrier we have in place now?

[Kousagi]

Tice Daurus, on 16 January 2013 - 11:08 AM, said:

What I'm wondering however if once this is put into place, will this remove the 'speed cap' that's currently in place now? Will this allow mechs to move past the 140KPH barrier we have in place now?

They should be able to, so long as the game engine can handle things moving faster then 140, which I think might have been the problem before anyhow. The game engine itself could not handle stuff moving that fast, not being a netcode problem itself. Though not 100% sure on that, since i was not in the beta when they made that change.

Though I guess we'll figure out when it comes.

[Hawkwings]

Please explain how a high ping player will ever have an advantage. Be sure to consider three points of view (player A, Player B, and Server) and show your work.

[Glucose]

VonRunnegen, on 16 January 2013 - 05:15 AM, said:

State-rewind is abusable with the client time stamping, its not true server-authoritative as some seem to think.

To demo: Lets say you know someone is coming towards where you are waiting round a corner. If you can delay your packets so they all go in a burst together then you can step out and shoot as as one burst without him ever having seen you.... the server will happily work out that you'd stepped from hiding before shooting in its rewind from the timestamps but as that info didn't reach the server until the same time as the shoot command there is no way for the other guy to know he was being shot at until after the event when you'll suddenly rubber-band out of cover and he'll have already taken damage.

This may be less of an issue with a mech game that actually has some realistic impulse, i.e we simply can't move in a jerky fashion to do such things. I think their current approach suits this game well.

The only issue will be the whining you see on day 0 that people are getting hit by lasers that appear to miss from their POV.

Tice Daurus, on 16 January 2013 - 11:08 AM, said:

What I'm wondering however if once this is put into place, will this remove the 'speed cap' that's currently in place now? Will this allow mechs to move past the 140KPH barrier we have in place now?

I think speed cap was more of an issue for the movement code, and not the combat-prediction code.

[Windies]

State re-winding = Interpolation?

https://developer.va...ag_compensation

Well Lag Compensation, Interpolation is just the process of making server updates to the client appear smooth. Still they do play into one another using the system that he developers are describing.

Edited by Windies, 16 January 2013 - 11:23 AM.