Still love the game, but please FIX IT.

  • Seriously Rare, the game is getting worse month after month. The hit registration is a complete mess, tonight we fought against players unkillable after 8/10 hits.

    Loading times randomly longer than usual after death, and megalodons that bite your ship and warp it across half of the map in one second, or turn it 180 degrees and instantly sink it.

    I don’t care about endless skins, fireworks, dices and other millions of useless features.

    PLEASE, JUST FIX THE GAME BECAUSE IS UTTERLY BROKEN TO THE CORE.

    Sincerely and desperately
    Fox, a player with more than 108 days spent in this game.

  • 19
    Posts
    2.7k
    Views
  • @fox-gr

    90% of the time I've seen someone complain about hit registration in a gameplay video - they were just a garbage shot.

  • @gravesilence272 said in Still love the game, but please FIX IT.:

    @fox-gr

    90% of the time I've seen someone complain about hit registration in a gameplay video - they were just a garbage shot.

    This exists for sure but there are examples by people with skill/knowledge that show how bad it can be on youtube. Depends on the server and people that are accurate will obviously experience it a lot more but there is definitely a lot of hit reg issues out there and it has been steadily headed in the wrong direction for quite a long time now.

  • @gravesilence272

    I wrote about my 108 days of game time just to avoid the “you suck, get good” replies.

    The issue with hit reg is massive and well know

  • If it were a simple fix they would’ve done it ages ago. I don’t think it’ll ever truly be gone but they might be able to make it better.

  • @fox-gr said in Still love the game, but please FIX IT.:

    The issue with hit reg is massive and well know

    No it isn't. People believe it is. Not the same thing.

    Even in cases where it's not just bad aim, most of the hit registration complaints I've seen people make are not actually due to hit reg code at all - but because the player fails to understand the interactions of input latency, network lag and client forward prediction.

  • @gravesilence272 Even if you are right, there's still a problem. I shouldn't have to understand 'client forward prediction' to hit something with my flint-lock. I should be able to simply aim and shoot, just like I do in other fps online games. Obviously ping can be an issue, but I've had sessions where I've had really low ping and hit-reg has still been unreliable.

    I agree with the OP; hit-reg continues to be an issue with SoT. For me it's not game-breaking, but it is definitely frustrating. I have found that shutting down the game completely and starting a new session sometimes alleviates the problem...not always though, and that option can be pretty annoying if I'm deep into a session before the issue becomes apparent.

  • @gravesilence272

    No it isn't. People believe it is. Not the same thing.

    it has been acknowledged that both gun and sword hit registration is not good by Rare.

    the main issue is that Hit marker and actual hit registration are calculated on different locations (hit marker client side and actual hit server side)
    due to this situations can occur where the client says its a hit but the server doesnt acknowledge it ( meaning no damage is dealt to the opposing player)
    but also something known as backtrack, where the shot on the client clearly misses but the server says its a hit and thus deals damage to the opposing player

    i am quite often on both sides of the coin, where my hits dont register but also in situations where i clearly see a bullet hit me and i receive no damage.

    it also happens more often when there is alot of ships,players or loot are together in a relatively small area, in which the server starts having issues keeping everything in parity.

    just for fun have a full arena alobby all emote at the same time, you will see a slideshow instead of animations

    hit registration is an issue and shouldnt be shoved under the rug, however it is also an issue that is very hard to fix because of the general intricacies between all moving parts.

    @fox-gr Hit registration is still on Rare's radar and they are trying to fix it, new content is not blocking that work, there are multiple dev teams at work on Sea of Thieves, some of them are working on future content while others are working on fixing issues

  • @callmebackdraft said in Still love the game, but please FIX IT.:

    @gravesilence272

    No it isn't. People believe it is. Not the same thing.

    it has been acknowledged that both gun and sword hit registration is not good by Rare.

    the main issue is that Hit marker and actual hit registration are calculated on different locations (hit marker client side and actual hit server side)
    due to this situations can occur where the client says its a hit but the server doesnt acknowledge it ( meaning no damage is dealt to the opposing player)
    but also something known as backtrack, where the shot on the client clearly misses but the server says its a hit and thus deals damage to the opposing player

    You are only agreeing with me here. Everything you are talking about isn't technically "hit registration".

    What you are describing is precisely what I was talking about. What the player sees (client side) is only an approximation of a predicted server state - NOT the actual server state. Even if it looks (to you) like your shot should have hit, your view MAY NOT HAVE BEEN CORRECT. You may, in fact have been aiming off, but not been able to perceive it because of latency and client prediction.

    "Backtrack" is again NOT "hit reg", but a symptom of the above. When an enemy fires, the server has the REAL game state, and the client is showing it's best approximation taking into account latency, movement etc...

    It may seem to the player that they were standing behind a door and should not have been hit, when in fact they were actually in the doorway and the enemy's shot was perfectly good.

    Of course, because players are ignorant of game mechanics, and don't realize their view is an approximation and NOT the real game state, when they either miss or get hit because of latency and player prediction - they whine about "hit reg" instead of educating themselves.

  • @gravesilence272 Cool.

    Whatever it is, would be nice if we had less of it.

  • @gravesilence272 it is hit registration, a difference in it… and the issue being that there is too many occurences of hits being registered different then they are shown to either of the parties.

    It is a known issue and rare itself calls it ranged and melee weapon hit detection.

    What you are trying to make an argument of is known as semantics.

    The desync between client and server which causes the issue is acknowledged by RARE and you arguing semantics with people holds no bearing

    Call it whatever you want, hit reg, back track, hit detection or apple crumble pie the issue stands

    What people see is bullet hitting target and target tanking straight trough it for an entire clip (not even mentioning the hit marker) and yes in that case the server has either one or both of the targets locations different then we see client side which can be acceptable every now and then but not at the rate that is happening currently

  • @callmebackdraft said in Still love the game, but please FIX IT.:

    @gravesilence272 it is hit registration, a difference in it… and the issue being that there is too many occurences of hits being registered different then they are shown to either of the parties.
    What you are trying to make an argument of is known as semantics.

    Again, this is not "hit registration" which has a technical meaning, and the difference is NOT just semantics - the difference is crucial in whether or not to take player complaints seriously.

    It is a known issue and rare itself calls it ranged and melee weapon hit detection.

    Good, this at least shows they acknowledge the issue isn't technically one of "hit registration".

    For clarity, "hit registration" (in game coding terms), means specifically the issue of determining whether a vector or trajectory intersects with a defined bounding box. Issues with hit registration have to do with things like polygon clipping, vertex and edge detection, approximations of mesh topography etc... An actual "hit reg" bug would be when a shot should have connected based on the server state, but a bug in the code caused the hitbox check to fail.

    THAT is "hit reg".

    The desync between client and server which causes the issue is acknowledged by RARE and you arguing semantics with people holds no bearing

    It isn't semantics, and it absolutely has bearing. Actual hit reg issues are solvable - while the problems people seem to label as "hit reg" that are not actual hit reg issues, and are caused by what is essentially an unsolvable NP hard problem equivalent to the three body problem in physics.

    Call it whatever you want, hit reg, back track, hit detection or apple crumble pie the issue stands

    What people see is bullet hitting target and target tanking straight trough it for an entire clip (not even mentioning the hit marker) and yes in that case the server has either one or both of the targets locations different then we see client side which can be acceptable every now and then but not at the rate that is happening currently

    What you call it absolutely does matter because calling it "hit reg" issues makes it seem like the issue is easily solvable with just a bit more hard work, and the only reason it isn't "fixed" to your liking is because the devs are lazy.

    Just realize that 90% (or more) of what people whine about being "hit reg" has nothing actually to do with hit registration, and is almost entirely due to a virtually unsolvable dynamic physics problem, one that even NASA scientists haven't been able to solve.

    It's ridiculous to demand that the RARE devs solve a problem that nobody else has been able to, simply because you refuse to educate yourself on what the actual issue is, and prefer to pretend it's something else by using the wrong label.

  • @gravesilence272

    hitreg
    -noun

    1.) Short for "hit registration" usually in reference to first-person shooter (FPS) video games.

    2.) The act of registering or detecting a hit from a bullet, knife, or another object in a game environment.

    like i said semantics

  • @callmebackdraft said in Still love the game, but please FIX IT.:

    @gravesilence272
    2.) The act of registering or detecting a hit from a bullet, knife, or another object in a game environment.

    Oh, wow. A dictionary definition!!! Weapon of the true warrior! LOL

    Regardless, the definition above is correct (if a bit vague), yet still remains NOT the thing you are complaining about all the same.

    like i said semantics

    You keep using that word. I do not think it means what you think it means.

  • @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

    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.

    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.

    At its core what we are having is a difference in oppinion to wat "hit registration" means or how it is used, 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

  • @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

    1. 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

    2. 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

    3. 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

    4. 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

    1. server adjusts positions of players and ships, now taking into account P1's new movement command

    2. 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.

  • @gravesilence272 like i said… i know what the issue is AND i know that sot is WAY more “moving parts” then just any fps however. These moving parts (sea, ship, player hit box which in sot is just a square of the same size independent of character model) basicly havent changed since release and in the first year the hit detection was WAY more reliable.

    Comparatively between then and now:
    Back then hits that failed (hit marker but no damage) happened 1 out of a 100 times

    While now it is more in the 25 out of a 100 times.

    Thats why i said sot was way better at this and your highly explanatory post was unnecessary, i could go into the same depth since i work in the software engineering field but it is useless to do so.

    Thats why we also shouldnt hang ourselves to what something is called (hitreg, hit detection etc) because players are going to call it whatvis most convenient.

    When the avarage player experiences situations where it looks like his shot should hit but it didnt he is going to call it that and nobody is going to change that because of how its been embroiled into the players head.

    And when the same average player gets a kill although he saw that his shot was way off he is going to call it back track for the same reason.

    And then we get to the core of the issue which people complain about, the amount of times the systems (client and server) disagree on what happened has become more and more abundant over the last 3 years.

    And saying that it being highly complex (which i have stated here and on many other “hitreg” posts over the years) and impossible to improve upon is doing the dev team a major disservice.

    They are actively working and getting it better and have had some small improvements every now and the, however us old-timers of the seas know it can be better since we have experienced that way back in year 1

  • If you "Improved Hit Registration" why did it get worse? I feel as though I am shooting nerf darts at my enemy

  • I still think they should delete the hitmarker from the game...many times I thought I didn't hit, I got a marker, but the enemy was running around without healing himself...
    On the other side, I thought I hit them, didn't get a marker, but he died...at this point I don't think hitreg is the problem, just the hitmarker
    That is just my opinion, I know I'm almost alone with that opinion...

19
Posts
2.7k
Views
16 out of 19