As of right now, I am sure that you and many players are aware of the desync bug that is going on right now - where the player thinks they are flying around but the server thinks their ship is sitting still where they first entered the playfield; eventually sync is re-established, and suddenly the player is floating in space or falling through the atmosphere, and their ship is far away. I am not sure what is causing the desync, but what is apparent is that the game client is able to handle this sort of player position desync without completely crashing. Currently due to this bug, after sync gets re-established, the client seems to take precedence when deciding the player's position, the server seems to take precedence when deciding the server's position, and so the ship appears to be moving many kilometers away all of a sudden after flying for a while., which players seem to be misreporting as the ship moving far away all of a sudden for no apparent reason (See also: https://empyriononline.com/threads/ship-teleports-after-space-planet-transitions.97112/ and https://empyriononline.com/threads/...appear-on-other-areas-of-the-map.28285/page-6 and https://empyriononline.com/threads/...-from-client-after-changing-playfields.97057/ ) Well, what does any of this have to do with moving around inside a moving ship, you ask? Everything, it turns out! There is an interesting side-effect of the ship position desync bugs that are going on with the game right now - you don't need any frame of reference silliness to be able to implement having players move around a ship - you just need to allow the client to be able to desync the player's position and have the client THINK that the player is walking around, whereas in reality, the server actually has them still sitting in the seat. It turns out that this is enough, because almost anything the player might want to do in a moving ship is something they can do while seated anyway, and anything else they might want to be able to do can just be explicitly locked out on the server side if not already, like the way that the drill filler tool does not allow the player to fill in the spot they are standing on. Then it becomes a matter of whether you want to add code in the future to allow players to do more than they already can do from their cockpit while flying, and then players will be able to do those things while "walking around" too, because they're not really walking around. If for any reason something happens to the ship or the seat mid-flight, or the player hops out of the ship and leaves its dimensions, the player's position could be brought back into sync with the server, placing them where the seat was, and it could just handle it how it already handles it - have them go flying out the back. So, what does this add? It gives the player more immersion, they think they can walk around a moving ship, and thus they think the game is way deeper and more complete than it really is. And what does it cost? Probably just a few dozen lines of code, in addition to whatever the fix is for the position desync bug that's going on in v1.4 MP right now. The only cons is that players would not be able to shoot each other or be shot mid-flight. And if anyone asks for it, you devs already know how to say no
If this were ever implemented, there is a logical way to further optimize this which would allow a way to also handle flying before players have even initially sat down: The game could check within the ship's dimensions for any players, try to find at least one seat on the ship that they have access to sit in, and then allocate them to that seat. If the seat is already occupied, the game could potentially create a virtual copy of that seat at the same location and then assign them to that virtual seat. If there are no seats that they have access to, they could just fly out the back the way they already do. As far as I can tell, if the game allowed 10 invisible "virtual" seats at the same position, it would not cause any client-specific problem for players to exit the seat, because they can already walk through each other; the main issue would be dynamically adding and removing those virtual seats; for that reason, it would be best if this were treated as a sort of "phase 2".
I really doubt that. It doesn't sound like a good idea to rely on desync for a feature. Far better to do it properly from the start.
When I drill a rock and see the two resulting pellets fall into the ground, I see two very simple objects not obeing the laws of the game, in conditions where such a thing should just not happen. I extrapolate from that when I read elaborate suggestions and wonder if players see the same things I see...
@RedScourge Your explanation on how the movement of players around moving ships should be is cutting many corners and falls too simple at least. It is way more complicated then this: - First of all: De-sync objects in IT (Information Technology) is a very bad idea leading to unstable situations and the final result, with all probability, will be very rare things happening on screen, in the best case; or software (at client or server) crashes in the worst. - You have centered your theory around a Server / Client environment. What happens for single player when there are no Server side? - Dealing with moving objects "parented" with other moving objects, implies having a solid hierarchy and physicalized objects. The movement of a player inside a ship depends on the movement of the ship, and would depend on the movement of another object higher in the hierarchy (what happens if you move your character inside a SV / HV that it is docked inside a CV?). The movement has to take into account if you are inside something or not, to add all the velocity of all parent objects to the user input to calculate the new X, Y and Z. I bet this is why we must be seated in the cockpit in order to move the ships, or why we have no rotating space stations as POIs. - In order to support this feature, the engine must to be developed for this from the very start, it is very complicated adding this afterwards.
Yes, the entire point of this proposed solution is to cut corners versus a solution involving frames of reference, so it SHOULD come across that way, as that is exactly the goal of this sort of implementation - If all that is desynced between client and server is the player's position and this gets resynced to the server the moment that sync is again required, and if the client already gracefully (ignoring the current bugs) handles these desyncs (it does as proven by the bug), then it's not a dangerous sort of desync. - If no server, obviously then the feature would not make sense, so at worst it could just be skipped for that scenario, and we'd be back to where we already are today - Dealing with "parenting" is exactly what I want to avoid, which is why I explicitly said that there would not be frames of reference going on here, etc. What the client sees would not actually be happening on the server side, thus there would be no need for the server to calculate the player's position relative to the moving ship, as the only position it would be aware of is where the cockpit is. All you are doing is allowing code that already exists in the client which gracefully handles desyncs of player position without entirely crashing the game to be used to allow the user to have the illusion that they are walking inside their moving ship, when in reality the server still has them positioned in the cockpit. A player walking inside a docked ship would be no different than walking in the parent ship, because the docked ship is inside the parent ship and so is the player, the docked ship is not allowed to move or undock while the parent ship is moving, so all that would be processed is the existing collision logic of the player bouncing off solid objects, etc.
Except that the devs already said they're not going to do it "properly", because it would be way too hard. But if you can get 80% of the gain with 5% of the effort, as my proposed solution provides, suddenly what was out of reach is once again within reach
You can't build a skyscraper in a day, particularly if you're an "indie" construction crew. 80/20 rule exists for a reason.
I disagree that your solution would be easy to implement or even work. With something like walking in ships, you either do it right or you don't do it at all. Cutting corners won't work.
This seems like a dangerous ball of yarn to start trying to tug at. Not to mention, it doesn't do what is honestly the biggest reasons that I want to be able to move around a moving ship: Either modifying the ship that I'm on, or modifying a ship that is in it's hangar. Not to mention, a proper implementation could also allow things like ships moving around inside of ships. No. If my options are this weird desync bug trying to be a feature, or no moving around in ships at all... I'd rather have none.
I really do not see this working at all in a true multiplayer environment, where others should be able to see you moving while they are in movement too, what about relative movement, when you want to see a ship through your windows, in movement, and maybe even see the people inside this ship in movement too through both windows, the one in your ship and the one in the other ship. Even I think that basing the feature in decoupling information between server and client is overcomplicating all, being honest, even I thing that it is way more easy doing this properly instead a fake approach that, probably will fail miserably in many situations (more easy in the sense that doing properly would avoid dealing with rare side effects very complicated to overcome). The provided theoretical solution not working at all in single player is disheartening at least. I tell, do it properly or do not do it at all. Sorry being skeptical over this, and thank you for your thoughts and proposal, but being honest, I think that this does not work or would cause more harm than good.
Devs have said a proper implementation will not be attempted, too difficult. However, this implementation actually does not preclude the possibility of modifying the ship or docked ships, it simply does not add it on its own. If this implementation of moving on ships were added, they could then add code which would allow players to make ship modifications, but currently such code is undoubtedly not in place, because you cannot alter blocks while seated. But yes, a ship moving within a moving ship would absolutely not be possible, though why you'd want to is beyond me; for example no one would do this in real life as it would be unsafe.
Actually my suggestion would be undercomplicating it, precisely because doing it the "proper" way would be far too complicated, which is why the devs have said many times that they will never do it the "proper" way. I know it would be vastly simpler than a "proper" implementation, because bugs in the game have accidentally revealed that it is already possible. My suggestion is a vastly more lightweight way for players to be able to gain the added immersion of walking around in a moving ship without the order of magnitude increase in complication and perhaps order of magnitude increase in server-side computation required to handle a proper implementation of movement relative to arbitrary frames of reference natively. Because this sort of implementation would be vastly more simplistic than a "proper" one, it has limitations, the main ones being that it would not work in single player, and that a theoretical outside observer would not be able to see where the player is within the ship, but it also has the advantage of being potentially simple enough to happen.
The easiest way to let players move freely in ships already exists, the only problem is to have a reasonable degree of collision accuracy. Trying to "cheat" physics by managing players as if they could simply walk while the ship is maneuvering instead of the ship throwing players everywhere "inside" against walls/ floors/ ceilings is one step further, but still requires the main problem to be solved, which is "proper collision inside the ship".
True, proper handling of collision with parts of the ship would still be an obstacle, however in this implementation, as the player being able to move around a moving ship would have zero consequences for the server (until the ship is destroyed or the player hops out of the ship's dimensions, at which point the server would have to force them out of the seat), this means it could be completely offloaded to the client. If it can be completely offloaded to the client, it alleviates any burden from the server, but the client would still have to track the player's position relative to something; but in this case it could be a replica of the ship that's sitting still and which does not need to have its own position calculated relative to the playfield (perhaps relative to the primary cockpit).
Well the main problem I see is that in order for the interior of the ship to be represented with minimum accuracy, the use of a Mesh" collider would need to be used, as ships are made by players vs pre-compiled models with pre-defined colliders adjusted to the shape. And the problem is that mesh colliders do not collide with other mesh colliders, and collisions are required as triggered "events" to be properly treated by the physics engine. The alternative would be to use "convex" colliders (similar to mesh colliders) but these, when generated, eliminate all "undercuts" (or "concave" shapes) and I can see how the game engine would have a hard time making such a complex collider for the whole interior of a ships without blocking corridors / filling spaces with "invisible walls". Colliders like this would also need to be re-generated when ships lose blocks during combat, for example. Here's an overview of how colliders work in Unity : https://docs.unity3d.com/Manual/CollidersOverview.html Edit : another useful bit here, to understand the relation between physics and render loops in a game : https://gafferongames.com/post/fix_your_timestep/
I do not agree, you are simplifying in the implementation and complicating the outcome. By cutting corners this way, you would be creating a very unstable scenario (at the technical side of things) that would lead to undesired effects very difficult to fix / debug. It is the typical case of not invest many time in the solution designing phase and lament yourself afterwards when you get a not fully working system, plagued of undesired effects and nearly impossible to fix. My advice: Plan beforehand, invest the time in the design phase, make all match on the paper, and implement afterwards a solid solution. Even doing this you will find unforeseen problems, Imagine these problems if you do not invest enough time at the design phase.
