Overview

Currently the interactions that occur between two clients in different time subspaces are paradoxical and unintuitive. For the sake of discussion, I've constructed several examples with two clients:

Jo_Past will be piloting Rover_Past with the red lights, and Jo_Future will be piloting Rover_Future with the green lights.

Example 1: A past client crashes into the 'past' version of a future client

https://www.youtube.com/watch?v=_R9-Vtqct98

• Jo_Past is sitting in the middle of the runway with Jo_Future to the side.
• Jo_Future drives down the runway, a few hundred meters in front of Jo_Past, a small distance away, warps to the future by a few minutes, then moves to the side of the runway. Jo_Past, as expected, still sees Jo_Future as being in the middle of the runway.
• Jo_Past then proceeded to launch down the runway, crashing into the 'old' version of Jo_Future. On Jo_Future's screen it looks like Jo_Past just suddenly turned into a broken copy of the craft.

What's wrong here?

This one sort of makes sense. Jo_Past could see the other vessel and could have avoided crashing into it. However it's a paradox, since Jo_Future never experienced anything crashing into them. If you look closely, for a time Jo_Past sees an intact copy of Rover_Future roll by, and I feel that if that copy had crashed, it would have caused Jo_Past to add more debris, which would have been a paradox since Jo_Future was never actually in a crash.

Example 2: A future client is destroyed by a past client's future 'projection'

https://www.youtube.com/watch?v=ZjRsaQbfNYM

• Jo_Future and Jo_Past are sitting on the runway side by side.
• Jo_Future warps a few minutes into the future, then Drives down the runway and stops a few hundred meters in front of Jo_Past. At this point, as far as Jo_Past is concerned, the runway is completely clear, and they see Jo_Future as being next to them.
• Jo_Past then accelerates down the runway. Jo_Future sees Jo_Past crash into it and is destroyed by the 'Future' projection of Jo_Past.

What's wrong here?

This case is really unacceptable. Jo_Future is destroyed by Jo_Past, which hasn't even appeared in that time yet. Indeed Jo_Past had absolutely no way of knowing that it would crash into Jo_Future. This isn't even a paradox, it just flat out doesn't make sense. Jo_Future should not know where Jo_Past will be after several minutes pass, much less be able to be destroyed by the 'projection'.

What needs to be Changed:

I feel that there are several potential changes that could be made to help mitigate the issues described in the above examples:

1. Example 2, where a future client can be destroyed by the projection of a past client needs to be changed so that it is no longer possible:
   • Option A: An easy fix would be to remove the past vessels completely from a future client's simulation. that way no projections interact with them. This makes sense because you can't predict where a past client will be by the time they get to your time
   • Option B: A probably more complicated fix would be to modify the 'projections' of past vessels in a future client, so that they do not simulate physical interactions, and simply pass through the client's vessel.
2. Example 1, where a client in the past can run into the 'past' version of a future client should probably be modified as well.
   • Options A and B above apply here as well, though option B would be much preferable.
3. When viewing a vessel that, relative to you, is either in the future or in the past, it should be made more clear which of the two is going on:
   • The nameplate of a vessel can have [F] and [P] prepended to them, to indicate future or past.
   • Assuming that Option B above is possible, then any vessels that cannot be interacted with should be made transparent, similar to what KMP currently does while inside the bubble.
   • A vessel should be colored red (again using shader trickery similar to KMP's bubble transparency) if in the past and green if in the future.

There's also one hacky way to fix this bug. Just have all the clients on the "same place" synced, so you can't warp. That way all clients would be synced and Jo_Past would see Jo_Future on the side of the runway.

I think we should solve this problem with no-clip + transparency to indicate they can't be interacted with for case B.

I think I'd rather leave case A as is - As far as the timeline is concerned that vessel is there in that time - Although subspace mode definitely does bring out some weird paradox issues :P

EDIT: We'll have to look at docking and quickloading too. Docking to a vessel manipluted in the future is going to cause weirdness. For example - It may be possible to transfer to eve and duna at the same planetary "time", but at different real times.

Keep in mind that your examples involve driving/flying on a planet, where powered flight is the rule, but the majority of KSP operations take place in space where powered flight is the exception.

Scenario: Suppose Jo_Future docks with the non-player vessel KerbStation, while Jo_Past is in another vessel. Later (in real life) but in the past (in game subspaces) Jo_Past switches to KerbStation. Jo_Past could just sit there and do nothing, or operate some sciencey parts, or sync to Jo_Future, or could move the station around, which may cause future issues during or after docking.

With option A, as soon as Jo_Past switched to KerbStation, KerbStation would disappear from future subspaces even if Jo_Past had no intention of moving the station around. Even worse, KerbStation would disappear from the map, so Jo_Future could not even target it for rendezvous. This would make it impossible for two players to cooperative effectively unless they are in the same subspace. it also opens up much more trolling potential if there are any current or potential players (such as logged off players) in the past.

With option B, when Jo_Past switches to KerbStation, it becomes a ghost for Jo_Future, but that prevents him from docking, even if Jo_Past was a cooperating non-troll player.

I propose Option C: vessel is only ghosted when the vessel is currently (in real time) undergoing powered flight in a past subspace. That would include engines, reaction wheels, mods, some of which could be active even when a player is nearby but not in the vessel (like MechJeb.) A possible extension would be to continue ghosting the past vessel if it intersects the player vessel, until the intersection is resolved. (Avoids time-kraken.)

This solves example 2 without preventing player cooperation. Jo_Past can sit in the station in the past, but if he rotates it around, it is only ghosted during (in real time) that rotation, preventing accidental crashing for Jo_Future.

This isn't symmetrical, so example 1 would still be an issue, but time paradoxes are not easy to solve. ;)

I think in the end, no matter what you do you're going to get people who troll and grief. Its the law of the internet. Apparently humanity turns into idiots when there's no threat of a fist coming through the screen towards your nose.

The way KMP dealt with this is the only way I can see to handle this. If player A is not synced with player B, and they're controlling the vessel, it should be ghosted to player A. Vice versa. The ability to lock vessels will stop griefing, and being able to set player names who can access the vessel will ease co-operation.

Remember, keep it simple, stupid.

@MrFreake that works for me. Allows cooperation but prevents accidental time-krakens.