Latest subspace being updated by other players causes offline players' time to advance as well

[81ninja]

# sendPlayerToLatestSubspace - If true, sends the player to the latest subspace upon connecting. If false, sends the player to the previous subspace they were in.
# # NOTE: This may cause time-paradoxes, and will not work across server restarts.
sendPlayerToLatestSubspace=False

This is not always working as expected. If you leave the server and another client tries to connect but fails (because of mod validation, for example), when you connect again your subspace time will have advanced by quite a few hours, maybe days.

I think the client is being sent to the latest subspace regardless - one created for the failed connection attempt?

[81ninja]

I've reworded the title now that I have a little more insight into this.

What is actually happening is that, when the last player (Player1) on a server leaves, the subspace he was in is updated and saved to subspace.txt. When a new player (Player2) connects, he's sent to that same subspace (the last one created), and that subspace's time advances while Player2 plays.

When Player2 warps, or disconnects, the subspace gets updated and saved again. Then hours later when Player1 comes back, he's sent to his previous subspace, which has advanced by a factor of the real time delta since he left, spoiling maneuver nodes and contract deadlines that would have expired during that time (penalties may also apply).

In the case of a failed attempt (such as due to mod validation), the new client is still provided the latest subspace, After validation fails it disconnects, again updating the subspace to match the current server clock, mimicking the effect that setting keepTickingWhileOffline=True would have on planet time.

---

UPDATE: I'm currently testing a fix by sending new clients to either the previous subspace they were in (in case it's in memory) or a copy of the latest subspace instead of the actual latest one which may be another player's.

[81ninja]

A little clarification on what would (imho) the expected behavior of sendPlayerToLatestSubspace and keepTickingWhileOffline.

Yes, keeping the universe time the same for each and every player is what I want, i.e., each player would resume from where they left off. That is, if sendPlayerToLatestSubspace=false. Else they'd be sent to the latest time among all player subspaces, and new players would be sent to this as well.

Plus, each player's time would still be advanced in realtime - but not to the same time - in case keepTickingWhileOffline=true. Else, universe time would stop when the last player disconnected - as before.

The two options combined would give players four possibilities on how to advance time, which can be useful for shared careers vs sandbox and and open vs private servers.

[godarklight]

Jesus, talk about embarrasing. I've cherry-picked 8c5a96f028824f7f0cac0fc69910e5f0f58bae4e

Currently, the behaviour is "Send players to the latest subspace that keeps ticking", or "Send players from when they disconected" (EDIT: and I mean when they disconnected, time won't advance with the latter)

A restart still sends them to the latest, but that is only because we haven't made that persistent. I'm also curious if anyone actually uses these settings, I'm starting to wonder if they should be a client side thing...

[81ninja]

Maybe it could be a client option instead of server side? Allowing players to choose whether to connect to their previous subspace or just syncing to the latest one every time. It'd depend on how a player would choose to play. But servers would maybe want to enforce sending people to the latest subspace (or not) to avoid things like vessels being changed in the past.

Idk if it bothers anyone else but I for one have been using these settings. (latest=false, tick offline=false). It's because I play career on hard in a "space race" or "don't warp unless there isn't anything else that can be done" manner. (i.e. crazy amount of events going on and multiple maneuver nodes on everything)

I'm also thinking a little bit forward when we have shared careers either cooperative or competitive, and how this/these would work in relation to other game modes. In the same you way as you have other time modes (MCW), having more control over how subspaces work can be nice.

[81ninja]

godarklight provided a simpler/cleaner solution to this (2e5f597).