Why isn't character position resolved player-side?

[Eery Petrol]

When a player does a tricky manuever on deck that could have ended up moving that player in one way or the other, the game sometimes comes back on its decision that the player went one way, and suddenly rubber bands the player into the other. I assume that this occurs because player positions are not being tracked player-side.

My question is why? So far, this has been the bottleneck for the on-deck movement freedom I've experienced in the game. And if I'm right in thinking that player position isn't done player-side, I'm curious to know why not. I'd think it can't be collision detection. The only detection with which player movement is involved, is with static ship architecture which I'd assume can be resolved player-side. So what's left that has to be done server side?

The thing that is relevant to the other players when any player is moving freely on the ship, is when that player legitimately clicks on or presses 'use' on ship objects. To check legitimacy of object interaction you do need server side info; you need to know whether the object is available for interaction. But this data is already being sent to the player. So why not just combine server side object status and player-side location data to determine legitimacy? This way you'd only send legitimate interactions and player position to the server. Wouldn't this allow more precise tactical movement and reduce the server load? I'm not saying. I don't know this stuff well enough, just curious.

p.s. If there is a previous topic that covers this please let me know, I did some searches and didn't come across any.

[Watchmaker]

There are two reasons.

The first about is reducing the potential for cheating.  A basic rule of competitive networked games is "never trust the client" - because whenever you do, you open yourself up to possible cheating/hacking by a malicious client.

The second is simulation stability.  Resolving multiple independent simulations that are connected over the internet in a consistent way is hard and prone to error; even with corrections like the character snaps you refer to, an authoritative server produces fewer strange situations than a peer-to-peer one in my experience.  (there's a formal name for this problem in distributed computing literature: the Byzantine Generals Problem.)

To illustrate this, consider your own example of object interaction: part of the check to see if an object interaction is legitimate is checking the player's position, because repairing something from across the ship is clearly an unfair advantage to the engineer.  If your client and the client of someone on another ship disagree about whether you can repair the hull armor before their mortar shot lands, who wins?  The answer in our case is a neutral third party that acts as a fair broker: the server.  This does mean that sometimes the server disagrees with your client about where you are, and if this disagreement is bad enough it corrects you.

Now, this is not to say that we couldn't come up with clever ways to reduce the impact of this on your general experience of ship parkour; there's almost always something we can do to improve this sort of thing given time and effort.  That improvement just has to take place within the constraints I describe, because those constraints are there for a reason.

[Squidslinger Gilder]

Moral of the story...if in life you come across someone using cheats and hacks to dominate games because they are just terrible people for whatever reason, take their keyboard shine it up real nicely, put some steak on it, turn it sideways, and stick it straight up their $#@&@&^$#&.

The same also implies for trolls and powder monkeys.