

Does Server Authoritative Shot Calculation Make Snap-Shots Unreliable?
#1
Posted 21 November 2012 - 10:52 PM
I think this applies to aim too. When you fire, you shoot where the server thinks you are aiming a split second before, not where you are actually aiming at that exact time.
Since a snap shot by definition is a quick turn of the mouse and firing in a very fast move, if this is correct then the server is almost always going to throw your shot off by a good margin when you are moving the mouse quickly and firing at the same time.
When I snap shot with ACs, this seems to be the case, as they never seem to fire where I aim unless I hover the reticle in the direction I want for a time before firing.
If this is true, it's more than a little absurd. Quick shots are a part of any FPS, and I know PGI wants to stop cheaters, but doing it at the cost of making the aiming substandard for every legitimate customer is too high of a price to pay. I'd rather have a few cheaters than have aiming be broken for all.
#2
Posted 21 November 2012 - 10:58 PM
#3
Posted 21 November 2012 - 11:17 PM
Deadoon, on 21 November 2012 - 10:58 PM, said:
Um, if that were the case then they would make the reticles move slower. Yes, you're using a big mech. That's why the torso reticle moves slowly. Arms move faster. If the arm reticle is on a target, that's where it should fire. That's the whole point of having arm actuators. Currently with the flawed netcode, arm mounted ACs are almost more of a liability, because the faster arm aiming actually fools you into thinking you can line up a shot quicker when you can't.
What you're saying really doesn't make any sense. If the arms can't aim that fast, then the reticle should move slower. Either way, that's a pretty poor excuse for the flawed netcode throwing shots in a random direction.
Also, light mechs turn and aim quite quickly, but the netcode is still flawed with them just the same. Your excuse is not logical.
I'm not interested in making up rationalizations to fool myself into believing that the netcode is really some ingenious design decision so mechs can't aim quickly. We both know it's the netcode, not the gameplay design, so let's not fool ourselves here.
The arm reticle aims faster for a reason, and it's currently not very valuable, aside from using lasers and aiming vertically.
It's pretty obvious arms are for snap shots. Currently, that is not a viable tactic except with lasers.
Therefore, it is broken.
How sad it is that I'm having to explain "the game should shoot where it puts the crosshair" in the year 2012?
Edited by Tilon, 21 November 2012 - 11:55 PM.
#4
Posted 21 November 2012 - 11:51 PM
#5
Posted 22 November 2012 - 12:01 AM
Tilon, on 21 November 2012 - 11:17 PM, said:
Um, if that were the case then they would make the reticles move slower. Yes, you're using a big mech. That's why the torso reticle moves slowly. Arms move faster. If the arm reticle is on a target, that's where it should fire. That's the whole point of having arm actuators. Currently with the flawed netcode, arm mounted ACs are almost more of a liability, because the faster arm aiming actually fools you into thinking you can line up a shot quicker when you can't.
What you're saying really doesn't make any sense. If the arms can't aim that fast, then the reticle should move slower. Either way, that's a pretty poor excuse for the flawed netcode throwing shots in a random direction.
Also, light mechs turn and aim quite quickly, but the netcode is still flawed with them just the same. Your excuse is not logical.
I'm not interested in making up rationalizations to fool myself into believing that the netcode is really some ingenious design decision so mechs can't aim quickly. We both know it's the netcode, not the gameplay design, so let's not fool ourselves here.
The arm reticle aims faster for a reason, and it's currently not very valuable, aside from using lasers and aiming vertically.
It's pretty obvious arms are for snap shots. Currently, that is not a viable tactic except with lasers.
Therefore, it is broken.
Snap shots are not quick shots, snap shots are twitch reaction shots that are delayed due to the user purely, quick shots are delayed due to game mechanics, such as scoping in, aiming your gun or slowing down after a sprint.
The former is very easily exploitable by any coder, down to the most basic rgb aimbots. The former requires some effort on the players part to properly exploit for similar results, by implementing a travel time, movement delay and fire delay you make an aim bot nigh impossible without immense effort on the coder, and would be quite easily noticeable by a heuristic anti cheat due to the calculations involved. The game using twitch aim, one could make an aimbot out of a screen recording program and a mouse emulator hooked not into the game but rather the recorder.
So no twitch aiming is a thing i do not want brought to this game, if you need to separate the arms from torso, use the control key.
Once netcode is fixed, quick aiming and targeting will be a more viable solution, but until then, use high rate of fire weapons and lasers for consistent damage.
Edited by Deadoon, 22 November 2012 - 12:02 AM.
#6
Posted 22 November 2012 - 12:29 AM
Gristle, on 21 November 2012 - 11:51 PM, said:
I don't know, there seem to be other games with server authorative shots, and they don't seem to have these problems. Or am I misinformed?
I don't think it can stay this way. They must improve, considerably, or else the game will never be able to shake of the Beta tag. And it may never become succesful. It's just too fundamental of an issue IMO. This is a online game, not a solo PVE game with a multiplayer mode. If it's online code isn't high performant and precise, it's a failure. And I am not likely to say works like "Epic Fail" or "Fail".
You can get away with some bad net code - if, fo example, things lag around, but since all hit calculaitons are done automatically instead of requiring manual aim, it's not such a big deal. But MW:O isn't that kind of game.
Edited by MustrumRidcully, 22 November 2012 - 12:30 AM.
#7
Posted 22 November 2012 - 12:47 AM
Deadoon, on 21 November 2012 - 10:58 PM, said:
The recticle reflects where the arms ARE aiming though. It doesnt keep up to speed with your mouse movement it lags behind on screen as well as additional lag due to auth.
The current setup makes ballistics a USA exclusive item for competitive play. Sure, you can use them in pug matches with a 300ms ping but your not going to hit anyone skilled unless you spray shots all over the place.
This is on top of some weapons (like missiles) also having Intentional delays added on top of everything else making it even worse.
Deadoon, on 22 November 2012 - 12:01 AM, said:
they can improve and make optimisations im sure, but they can't "Fix" netcode as people seem to think because to do that they would need to "Fix" lag, which i dont see happening in the next 10-20 years of the internet.
Edited by Asmosis, 22 November 2012 - 12:50 AM.
#8
Posted 22 November 2012 - 01:31 AM
Asmosis, on 22 November 2012 - 12:47 AM, said:
The recticle reflects where the arms ARE aiming though. It doesnt keep up to speed with your mouse movement it lags behind on screen as well as additional lag due to auth.
The current setup makes ballistics a USA exclusive item for competitive play. Sure, you can use them in pug matches with a 300ms ping but your not going to hit anyone skilled unless you spray shots all over the place.
This is on top of some weapons (like missiles) also having Intentional delays added on top of everything else making it even worse.
they can improve and make optimisations im sure, but they can't "Fix" netcode as people seem to think because to do that they would need to "Fix" lag, which i dont see happening in the next 10-20 years of the internet.
There is such thing as authoritative interpolation. You make a move and the server verifies if that move is within the bound of your mechs potential at that time +~5-10% to account for acceleration, ping variance and packet loss to some extent, if it is not, you get rubber banded back to a similar viable location that is close to where you wanted/expected to be client-side, while everyone else is still seeing you as if nothing happened/moved slightly off to the side a bit.
For aiming, you utilize 2 pieces, server side position and client based position, if you fire a round you get the round to come out instantly for clientside rendering, and due to perfect accuracy of weapons, the round should be precisely where you were aiming. This is part 2 of authorized shots, say your round hits your opponent just as he almost gets behind a wall, that will still count as a hit due to your legal shot had impacted due to the client being in a now authorized and authenticated position. But wait you will say, he would have been behind the wall by the time the round actually impacted due to the delay between the server and users! Wrong. He will have a minor delay of taking the damage, he will be behind that wall when he is caught up with the interpolated game, but this shot in a real time scenario where delay is not an issue, did in fact occur and would have occurred whether or not ping was an issue in this system. This also has a built in anti-cheat function, the server authentication can be utilized to detect if someone is utilizing a speed hack easily, as well as if they are "enhancing" their mechs capabilities, aim bots that do not force aiming still need client-side anti cheat but that can be delayed.
This may seem unfair to those who have lower ping to some extent, but for those with higher ping even interpolation of position is a difficult feat, they can be jumping several meters to the side due to ping delays, and it makes sway running a lagger especially effective.
The problem with coding these kinds of systems is that they are finicky and take time to develop to the point of reliability and smoothness of actions, but even so, these kinds of systems are nearly standard in almost every fps and many rts nowadays.
Did I seriously just explain the basics of a anti-lag system for a forum argument....
Edited by Deadoon, 22 November 2012 - 01:34 AM.
#9
Posted 22 November 2012 - 04:28 AM

Isn't PGI still looking for a net-coder..?
Edited by MustrumRidcully, 22 November 2012 - 04:29 AM.
#10
Posted 22 November 2012 - 04:30 AM
#11
Posted 22 November 2012 - 04:32 AM
Tilon, on 21 November 2012 - 10:52 PM, said:
I think this applies to aim too. When you fire, you shoot where the server thinks you are aiming a split second before, not where you are actually aiming at that exact time.
Since a snap shot by definition is a quick turn of the mouse and firing in a very fast move, if this is correct then the server is almost always going to throw your shot off by a good margin when you are moving the mouse quickly and firing at the same time.
When I snap shot with ACs, this seems to be the case, as they never seem to fire where I aim unless I hover the reticle in the direction I want for a time before firing.
If this is true, it's more than a little absurd. Quick shots are a part of any FPS, and I know PGI wants to stop cheaters, but doing it at the cost of making the aiming substandard for every legitimate customer is too high of a price to pay. I'd rather have a few cheaters than have aiming be broken for all.
that is now how things are implemented in games. The server do not fire where it had registered you aiming a fraction of a second earlier. It extrapolates based on your current first derivative and sometiems second derivative movment (speed and acceleration) and fires where your aim would be if you continued those trought he tiem it has registered as the current delay bewteen your client and the server.
#12
Posted 22 November 2012 - 04:54 AM
Tilon, on 21 November 2012 - 10:52 PM, said:
What you are describing is the classic convergence issue with all arm mounted weapons.
In this game, convergence takes time - there even is a elite level skill reducing that time.
So if you snapshot, your convergence will (most likely) be wrong and the shot will go wherever he pleases but not where you have aimed at. You need to wait at least for a tenth of a second before firing.
#13
Posted 22 November 2012 - 05:07 AM

Between the 'lucky crits' and this convergence babble, I say babble in the upmost respect as in I dont completly understand what you all are talking about. I will just have to re-read the post. So server side aiming nullifies aimbots?
#14
Posted 22 November 2012 - 05:32 AM
#15
Posted 22 November 2012 - 05:59 AM
#16
Posted 22 November 2012 - 06:03 AM
#17
Posted 22 November 2012 - 06:12 AM
All weapons on a Mech adjust their aim point to the location under the crosshair. If that aim point is, say, 750m away, then the weapons will be set to converge their lines of fire at 750m. Since the arms are farthest apart, arm weapons have the most radical angle to match that aim point.
Say you then want to shoot a target at 250m. That's a 500m difference, and the weapons must all adjust their aim points by said 500m. Torso weapons pretty much shoot straight, so they don't need much time to converge properly (they still do take some time, though it seems most noticeable when going from a near target to a far one). Arms, though, are very finicky. They need to change their angle of fire pretty significantly because they are so far to each side, and that really messes up ballistics some times. This tends to be most pronounced against close-in, fast-moving targets, since it can be hard to keep your crosshairs on the target long enough for the weapons to converge where you want them (the same is true to a certain extent for arm-mounted SRMs as well).
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users