39 replies to this topic

[IamSeanConnery]

Why validate every hit on every mech? It slows down the game and adds too much workload onto the server. Push the work back to the client and instead randomly validate a certain percentage of the shots.

If this validation is random enough and not predictable, this would curb any "cheaters" from editting client data. The only problem is PGI would have to take failed validation very seriously on this.

Another stipulation is that the client/netcode could not know whether the shot was being validated or not.

I think this solution would greatly increase how players felt about netcode and hit registration.

[Hauser]

Wouldn't work.

You simple can not trust client data because the client is lagging behind on the server simulation. As such it is not possible for the server to distinguish between a client that is sending truthfull hits and a client that has been hacked to send false hits. To the server both can appear as missed shots. Either because the client is lying, or because the simulation is lagging behind.

Acting on failed validation would see everybody banned.

Edited by Hauser, 03 December 2012 - 06:40 AM.

[IamSeanConnery]

Hauser, on 03 December 2012 - 06:40 AM, said:

Wouldn't work.

You simple can not trust client data because the client is lagging behind on the server simulation. As such it is not possible for the server to distinguish between a client that is sending truthfull hits and a client that has been hacked to send false hits. To the server both can appear as missed shots. Either because the client is lying, or because the simulation is lagging behind.

Acting on failed validation would see everybody banned.

Firstly, I agree. You cannot trust the client.
But I think you misunderstand me. What I mean is to validate part of the time, randomly. And use that random validation to detect hacks/ false hits. As long as the client doesn't know when it's being validated, this method is almost as good as verifying every hit. Hackers could be detected consistently.

This random validation could be escalated to a higher percentage on clients who are failing more to be "investigated" or if they have bad connections that cause more failures. This way, everyone doesn't have to deal with 100% hit validation. Some people might only be at 1% and others may be at 100% validation.

[Nightfangs]

Great idea from Platinum Booger!
If it was possible to validate some of the shots afterwards without slowing down the game, that could be the ultimate solution to lagshielding.
Ban everyone who abuses the system for a few days and let the 99.9 honest % of players enjoy a lagshield free game.
You had to make sure that the latency couldn't be artificially raised to "keep someone from escaping" of course!

Again, great idea!
Something like that has been spooking around in my mind for some time.

[IceSerpent]

Platinum Booger, on 03 December 2012 - 07:00 AM, said:

But I think you misunderstand me. What I mean is to validate part of the time, randomly. And use that random validation to detect hacks/ false hits. As long as the client doesn't know when it's being validated, this method is almost as good as verifying every hit. Hackers could be detected consistently.

How would the server know if the client has been hacked? In other words, how exactly would you "detect hackers consistently"?

[IamSeanConnery]

IceSerpent, on 03 December 2012 - 08:22 AM, said:

How would the server know if the client has been hacked? In other words, how exactly would you "detect hackers consistently"?

Because to hack you'd have to change data more than just once. When a hacker keeps changing data, they're eventually going to get caught by the validation. At that point validation is upped on that user and they are caught even more, showing their data is consitently being changed. Here's an example:

Validation rate at 1%, upon 1 failure, escalated to 100% for a period of 24 hours:

Hacker is changing fired packets. After 50-200 shots, the server eventually detects this due to 1% validation.
Validation is upped to 100% to look into this for 24 hours.

Hacker continues to change packets. All changed packets are detected by validation and account is flagged.

Edit:
If you didnt want to flag, you could just leave validation at 100% for that account to "correct" the packet mistakes. This accounts for people with bad or unreliable connections.

Edited by Platinum Booger, 03 December 2012 - 08:50 AM.

[Sibs]

Hit validation wouldn't detect aimbots. Hits from an aimbot would get vaildated the same as any other aimed shot.

[IamSeanConnery]

Very true.
However, the current hit validation system that my proposal replaces in the game does not detect aimbots either. I'm just suggesting 100% validation isn't necessary for this game. That's a different topic which would require tracking off hits/misses as done in other games.

The hacking im referring to is replacing data with other data to gain benefits (more damage, who knows what else).

[Volthorne]

Platinum Booger, on 03 December 2012 - 11:26 AM, said:

The hacking im referring to is replacing data with other data to gain benefits (more damage, who knows what else).

Already being monitored by the current system. If it ain't broke...

[IamSeanConnery]

Volthorne, on 03 December 2012 - 11:41 AM, said:

Already being monitored by the current system. If it ain't broke...

Read my original post at the top of the thread first.

I'm not trying to add any additional monitoring. Just streamlining the monitoring that exists. Hit verification on every single shot is a waste of server resources and bandwidth and probably accounts for delays between the client and server all the time, lag and maybe even sluggish servers.

[Volthorne]

Platinum Booger, on 03 December 2012 - 11:52 AM, said:

Read my original post at the top of the thread first.

I'm not trying to add any additional monitoring. Just streamlining the monitoring that exists. Hit verification on every single shot is a waste of server resources and bandwidth and probably accounts for delays between the client and server all the time, lag and maybe even sluggish servers.

Actually, another MMO-esque game I play had an issue with this sort of thing too. Then they switched to client-side spawning of projectile visuals. Again, if it ain't broke...

[IamSeanConnery]

The problem is it that it really is broke! I suspect the server cannot keep up with the load and on top of that, is adding lag to everyone's shots further making the netcode impossible to deal with. Which everyone is complaining about around me. It's probably one of the worst issues in the game currently.

I'm not saying to trust the client here. The random validation would be enough to keep it "honest" and still have the ability to up the validation higher if needed back to original operation.

[Imagine Dragons]

I think the server CAN keep up with the load.

Its just the terrible netcode native to CryEngine3 or lack there of.

The Devs have said they are rebuilding the netcode from the ground up...

Edited by XenomorphZZ, 04 December 2012 - 08:42 AM.

[IamSeanConnery]

XenomorphZZ, on 04 December 2012 - 08:42 AM, said:

I think the server CAN keep up with the load.

Its just the terrible netcode native to CryEngine3 or lack there of.

The Devs have said they are rebuilding the netcode from the ground up...

Assuming the server can keep up, it's still adding delay to shots already. And many times when peppering objects standing still with SRM, LRM, etc I think the server is missing hit registration.

There have been complaints regarding SRMs not doing full damage, and it's my belief LRMs are not doing full damage either (thank god). I think more SRM and LRMs are hitting than what it generally accepted and some of the shots are not registered.

Hit validation is part of this equation. Regardless, I'm looking forward to the netcode fix more than anything else. This is just a suggestion to streamline operation and reduce perceived lag and maybe even save a little bit of money who knows.

[Volthorne]

What you're suggesting wouldn't streamline anything. Instead, it would actually make it EASIER for hackers to use their scripts. Why? If they write a %chance to activate their script on each soht, let's say 10%, then the chance of there being a random verification (also 10% for simplicity's sake) while a hacked damage packet is being fired is 1%. Suddenly, people can die from a single AC/2 shot and the chance of the hacker being caught is so incredibly small that it's near non-existant.

IF IT AIN'T ******* BROKE. DON'T ******* FIX IT.

[IamSeanConnery]

Let me detail out your argument and show you are mistaken.
A hacker cheats 10% of the time. And never cheats just once. C'mon.
The validation it set to 10% of the time.
Statistically, he will be caught about 1% of the time roughly. 1% is a HUGE amount when you cheat and fire shots constantly. Sure. He may get away with cheating for about 10 minutes of gameplay, Then he will be flagged. At that point you could increase the validation on him to a higher value like 100% without him even knowing. Then catch him 100% and ban him.

10% or 1% is an arbitrary value I chose for example. This could be anything the devs wanted and could be tweaked.
Serial killers are caught because they do things over and over and are sloppy. Hackers/cheaters are no better. Well, outside of not killing anyone ;P Who gives a crap if someone cheats once and never again? The chances of the guy cheating just once is incredibly small. We will cheat. Cheat at a statistically significant rate. And be caught.

Ain't broke? Is that what you call shooting at mechs at not having it register or constatly delay the shot fired so that I miss my target? I think your version of ain't broke is a smoking 1980's station wagon rolling down the expressway at 10mph.

[Volthorne]

Platinum Booger, on 04 December 2012 - 10:05 AM, said:

Ain't broke? Is that what you call shooting at mechs at not having it register or constatly delay the shot fired so that I miss my target? I think your version of ain't broke is a smoking 1980's station wagon rolling down the expressway at 10mph.

My version of "ain't broke" is using 5-year-old tech in my computer - it still works and can play all my games fairly well, why would I need to "fix" it?

Verification has nothing to do with hit detection, which relies solely on netcode. Not oly does your solution NOT fix hit detection, it doesn't even contribute anything meaningful to preventing cheating, I'd even go so far as to say your method encourages it, because statisically, a 1% success rate is something only a man who has nothing to lose would bet on.

[Alois Hammer]

Platinum Booger, on 04 December 2012 - 10:05 AM, said:

We will cheat. Cheat at a statistically significant rate. And be caught.

And be caught 100% of the time under the current system, compared to 1% under your "fixed" system. I think your "fix" is more like the "fixing" done to the family dog here- it kind of removes the gonads from hack detection.

As was said before, by another- it ain't broke, so let's not "fix" it.

[IamSeanConnery]

Alois Hammer, on 04 December 2012 - 11:42 AM, said:

And be caught 100% of the time under the current system, compared to 1% under your "fixed" system. I think your "fix" is more like the "fixing" done to the family dog here- it kind of removes the gonads from hack detection.

As was said before, by another- it ain't broke, so let's not "fix" it.

Statistically, 1% in comparison to 100% is insignificant with taking in a vast amount of samples and looking for a repeated binary result.
Let me give you an analogy in return: One is put in a room and the door is opened 1% of the time. Without fail, another would find the poop on the floor.

[IamSeanConnery]

Volthorne, on 04 December 2012 - 11:20 AM, said:

My version of "ain't broke" is using 5-year-old tech in my computer - it still works and can play all my games fairly well, why would I need to "fix" it?

Verification has nothing to do with hit detection, which relies solely on netcode. Not oly does your solution NOT fix hit detection, it doesn't even contribute anything meaningful to preventing cheating, I'd even go so far as to say your method encourages it, because statisically, a 1% success rate is something only a man who has nothing to lose would bet on.

People bet on the lottery every day for much lower chances that 1%. But we aren't gambling here. See my above post to refute the statistics. Without getting into detailed math, the result is the same, as abstract as it may seem to you.

Let me go into more detail to further clarify broken: Verification uses resources. Time. Also power. Time is directly related to latency.

I agree, this doesn't "fix" the netcode to what we all want completely. But it's an idea and a step in the right direction. And should not impact cheat detection- which I am a huge proponent of.

Overall it's just a suggestion if needed for the devs if it makes sense based on the implementation and resources they have. I'm sure they're better qualified to deem it useful or stupid based on that. They're the only ones with the code to really know anyhow currently. We aren't playing WoW here, trying to stop duplicated items and such. Your argument is based on one time event hacks and is not relevant here.