@callmebackdraft said in Still love the game, but please FIX IT.:
@gravesilence272 dude, for real the point is we both know what the issue is and you saying its
one that even NASA scientists haven't been able to solve.
makes it seem something that it is something that its not
Ok, this is the crux of what I have been trying to say. The problem IS something that you think it's not, and by calling it a "hit reg" issue or insisting that the actual issues aren't much different, you are trivialising something that is much more complex than most people are aware.
Actual "hit reg" issues, like polygon clipping, collision model approximations etc... can be difficult to implement properly, but have actual analytical & deterministic solutions. Complaining devs can't get the "hit reg" right is basically saying they are too lazy or incompetent to do their jobs properly.
The actual cause of the real issues that you have already acknowledged are the ones you are complaining about - REALLY is a problem that even NASA hasn't been able to solve. No horsehockey - straight up truth.
yes all FPS games have cases where hit detection/registration whatever fails, usually in cases of high ping but more reasons occur
but not to the same level as SoT is having issues with it.
Sure, but for most FPSs the calculations involved only need to account for 2 independent unpredictably moving actors in a single fixed reference frame. That's mathematically equivalent to the 2 body problem in physics which is essentially trivial.
In SoT, your client prediction and latency compensation has to account for (minimally) 2 independent unpredictably moving actors, each within
independent unpredictably moving reference frames (ship, sea etc...). Multiply uncertainties like that and the maths quickly get out of hand, making the problem SoT faces equivalent to the 3 body problem in physics, which does not have an analytical solution, only various "good enough" approximations that involve a LOT of contextual trade-offs.
Give me one example of an FPS that faces the same issue (2 actors moving separately in 2 separately moving reference frames) as the main combat context, has equivalently complex environmental features, but yet handles client prediction and latency compensation in a manner more satisfactory to you.
better yet, SoT itself used to be WAY better at it back in the day. over time the mismatch between client side registration/detection and server side registration/detection became worse and worse.
Back in the day, SoT's environment itself was simpler, and has gotten more complicated over time. This is an obvious extrapolation. They could fix the problem for you by removing most of the new features and graphics - but I doubt you actually want that.
At its core what we are having is a difference in oppinion to wat "hit registration" means or how it is used,
No, not really. "Hit registration" has a well defined and clear meaning, and the problems you are pointing at are NOT generally understood to included in that.
A "semantic" argument is one where people are talking about the same thing, but using different terms: e.g. people arguing over whether the color on the wall is "blue-green" or "turquoise" - in the end it's a "distinction without a difference" the wall is the color it is and the label doesn't really matter.
What we have here is the opposite of that. You are pointing at a red wall (client prediction & latency compensation) and calling it "blue-green" (hit reg); while I am saying "no, that wall is red, this turquoise one over here is blue-green".
but at the core of the dispute , which you acknowledged, lays the fact of those mismatches. something that probably will never 100% get fixed, there is too many moving parts in this game for that
however the state where it is now is becoming more and more cumbersome
It's not that it "probably will never 100% get fixed" - it's LITERALLY IMPOSSIBLE to fix. The best anyone can do is "good enough" approximate solutions, which ALWAYS involve trade-offs that someone will inevitably complain about.
Consider the following basic scenario in SoT (and associated variables) if you can figure out what the "correct" solution that everyone will agree on in all situations from every viewpoint, I will be happy to credit your complaints. If you can't be bothered to read this, or can't understand it and provide a solution, then you don't understand the issue well enough to complain about why the devs haven't fixed it to your liking:
Scenario
2 players, 2 ships, passing by each other, player0 shoots at player1, player1 dodges
Variables
Player0 Reponse Time (P0R), Player1 ResponseTime (P1R) - average human response time is 250ms with variances between like 50-100ms, gamers are a bit better than avg, let's assume 200ms +/-50ms each and
Player0 Input Latency (P0I), Player1 Input Latency (P1I) - unless you are using a real-time OS (which Windows is NOT) input devices (keyboards, mice) take roughly 50ms to process inputs (double that for USB or wireless)
Player0 Network Latency (POL), Player1 Network Latency (P1L)- this is your network ping, 100ms is a good avg to assume
Player0 Total Latency (P0TL), Player1 Total Latency (P1TL)- simply the sum of all three of the above for each player, roughly 400ms on avg (almost half a second)
P0TL, P1TL =~ 350-450ms
Quite simply, P0TL and P1TL mean that from the time either player initiates an action, it's 350-450ms before the game server can register that action. A LOT can change in that 400ms gap, especially when you consider the following further variables:
Player0 Velocity (POV), Player1 Velocity (P1V) - the direction and speed the player is moving
Player0 Acceleration (P0A), Player1 Acceleration (P1A) - the rates at which the players direction and speed are changing
Ship0 Velocity (S0V), Ship1 Velocity (S1V) - the direction and speed the ship is moving
Ship0 Acceleration (S0A), Ship1 Acceleration (S1A) - the rates at which the ships direction and speed are changing
Normal values for all 4 of the above variables are large enough that the relative positions of 2 players on 2 moving ships can very easily change enough in 400ms to move one player entirely out of the line of fire of the other.
Player0's perspective
P0 is on their deck, passing within pistol range of P1, who is also standing on their deck, near the mast.
P0 sees P1, aims their pistol dead-on P1's sprite and fires. From P0's view it's a perfect shot, dead center of mass.
However, from P0's view, after the shot, P1 moves behind the mast and somehow doesn't get hit! WTfudge?
"%^&$%^&$^* hit reg!" P0 whines!
Obviously the solution is that if the shot was dead on when P0 "fired" we should just force the server-state to recognize the hit, right?
Ok, let's see THAT from
Player1's perspective
P1 is on their deck, passing within pistol range of P0, who is standing on their deck with a pistol raised.
P1 sees P0, and dodges behind the mast out of line of sight. P1 then hears a shot, after dodging away, but somehow still gets shot? WTfudge?
"%^&$%^&$^* backtracking!" P1 whines!
Huh, so "backtracking" IS the trade-off solution to the (supposed) "hit reg" issue?
The main problem boils down to one thing that players just fail to seem to understand: THE PLAYER PERSPECTIVE IS AN APPROXIMATION - IT IS NOT A PRIVILEGED VIEW
The only privileged view (the representation of which is guaranteed to match the game state) is THAT OF THE SERVER. So let's look at both the above scenarios from
The SERVER's perspective
P0 and P1 act at roughly the same time T0, P0 firing, P1 dodging.
Each of P0s and P1s actions are registered locally with their respective clients, after their response time and input latency at T0+P0R+P0I and T0+P1R+P1I, and renders the local effects then.
However the server will not know about either action until T0+P0TL and T0+P1TL. Whichever command (P0 fire, P1 dodge) arrives first is essentially arbitrary, and can vary depending on all sorts of things outside either player's control.
Let's say P0's action arrives first.
At time T0+POTL, the server has been modeling both ships and players movements based on what their P0V, P0A, S0V, S0A, P1V, P1A, S1V and S1A variable values were at time T0 (roughly 400ms in the past). In this deliberately simplified example, the ships are moving completely predicatbly and can be treated as fixed reference frames. At time T0 neither player is moving within their frames, so all their variables are initially 0 at T0.
So what happens on the server at time T0+P0TL, when the server receives the command from P0 to fire?
T0+P0TL
-
since it's been P0TLms since P0 perceived their perfect shot and initiated action, both ships positions are first altered by applying their respective velocities over the intervening time, player positions don't need to be altered since neither was moving 400ms ago as far as the server knows
-
after adjusting positions of players and ships, the server traces a line instantaneously directly along the barrel from the P0's adjusted position, to see if it intersects with P1s bounding box
-
at this point, if the two ships movements have not moved P0s line of fire out of P1s bounding box, it is counted a hit, otherwise a miss
-
the server sends data packets to both players implementing the shot & hit, these arrive at each players clients at T0+P0TL+P0L and T0+POTL+P1L (respectively)
Now, slightly after (10-20ms or so), P1's commend to dodge behind the mast comes in. They've already been hit, and that command sent. But what else happens?
T0+P1TL
-
server adjusts positions of players and ships, now taking into account P1's new movement command
-
the server sends data packets to both players implementing P1's movement, these arrive at each players clients at T0+P1TL+P0L and T0+P1TL+P1L (respectively)
What does each player see though?
Player0
T0 - P0 initiates action
T0+P0R+P0I - P0 firing registered locally, gun animation & sound started locally
T0+P0TL - server registers shot & hit
T0+P1TL - server registers P1s movement
T0+P0TL+P0L - P0 sees their shot hit
T0+P1TL+P0L - P0 sees P1 start to move
Player1
T0 - P1 initiates action
T0+P1R+P1I - P1 moving registered locally, movement animation and sound started locally
T0+P0TL - server registers shot & hit
T0+P1TL - server registers P1s movement
T0+P0TL+P1L - P1 sees their player get shot
In this case, P0 sees things "correctly" they see themselves shoot, and then P1 move. But P1 does not see things "correctly" - P1 sees themselves move first, and get shot after. P1 might whine about "backtracking" at this point, even though they were actuall hit according to the servers "canon" gamestate.
But consider the exact same situation, except P1's command arrives 10-20ms before P0's. In this case BOTH PLAYER PERSPECTIVES WOULD BE EXACTLY THE SAME AS BEFORE: P0 would see themselves shoot, and then P1 move. P1 would see themselves move and then P0 shoot. However in this case because P1s packet arrived first, the shot would be a miss. Despite no change whatsoever in what either player sees the outcome is different and "who's perspective is correct" is completely inverted. In this case it is P0s view that is wrong, and P1s that is correct.
What about other situations - where the ships movements move P0's shot out of alignemnt before it registers and P1 doesn't move - so it looks to BOTH players like it should have hit, but doesn't because it was a miss on the server state?
You might be tempted to think you can solve this by privileging the clients views in someway - by timestamping them locally before sending to the server and the re-ordering, or merging the clients predicted positions and servers actual positions etc... except that if you privilege information received front the client in ANY way, you open a GIGANTIC back door for hacking and cheating.
It's simply unfeasible for modern game servers to privilege client information in any way (early NetQuake code did this before QuakeWorld came out and you could do some wild stuff with clever game packets!), so the only canonical gamestate view MUST be that maintained by the server, which will always be unavoidably out-of-sync with what the players see.
You can see the effects of this anytime you have a lot of local lag - you will see yourselves moving forward a bit (your client's local predictions based on the commands it's sending to the server) and then suddenly "pop back" to where you where 3 seconds ago. This is because the packets were missed because of the lag and the server never received the clients movements commands and syncs the game stat by forcing the client back to the servers last known values.
All of the above is about as simple a scenario I can think of in SoT, throw in more players, moving ships and players that are moving turning and jumping for initial states, and the math quiclly becomes intractable. It's literally like the butterfly effect: every additional variable multiplies your uncertainties exponentially.
But hey, point out how to fix the above to everybody's satisfaction, or give us some idea what the SoT devs in particular are messing up about any of the above, and I'm happy to listen to you.