Is this something that has been implemented ? I'm sorry if this has been already discussed, but Time Jumping could be another solution :
The bubble concept is already implemented on the server side. What is missing is the UI on the client side. Your jumping-idea is a client-side decision IMHO, i.e., the user has to decide if he wants to jump the gap between his current time and the destination bubble's time via:
* the automatic MJD sync algorithm (basically a confined time-acc up to max. x2),
* manual time-acc or
* a ScnEditor method like you proposed.
As I see it, this would have less problems than trying to sync all the players at high timewarp speed, a player set a time jump in seconds, others validate, the server send the time jumping command to clients with the new wanted MJD and all clients execute it and stay in sync.
"Stay in sync" is already the general term here, so offsetting the "common" time to the client's time by more than a few seconds is just a special case of it.
Choosing a bubble is a simpler task than a complex voting system, both in implementation and user experience, if you ask me. Especially since the "stay in sync" part is already implemented.
A similar experience is possible right now, you just need to convince the server admin to run "mjd reset <date><time>y" from an admin shell. The server would then immediately switch the time of the global bubble (which is the only one right now due to the lack of a client-side bubble-switcher) to the set value. Of course the clients will start to speed up their time-acc to x2 (or x0.1) immediately, but every client is free to use ScnEditor to time-jump instead of time-acc to the specific point in time.
So just to clarify, in the future the bubble system will be like user groups? Are you saying that for example players 1,2,3 want to make their own bubble, and assign 1 to lead the bubble?
In a sense, yes. Right from start, a user is in the global bubble (just a bubble that is always there). He can then decide to create a bubble (becoming the leader of this bubble) and join it. Others can join this bubble, too. As soon as you are in a bubble, your Orbiter session needs to be synced to the time there. The time there is provided by the leader of the bubble. So following your example:
1. 2 and 3 say to 1: "hey, let's go to Mars! you are the fleet commander!".
2. 1 creates the bubble labelled "1/MarsFleet" and joins it. So do 2 and 3.
3. 1 makes orbital ejection, 2 and 3 follow.
4. Once in coasting phase, 2 and 3 tell 1 that they are ready for acceleration to MCC, so 1 speeds up until he sees MCC point coming up, then slows to x1 again. In the meantime, 2 and 3 were synced to this time-acc, too. So in the end, they are all at MCC.
5. If now 3 decides to speed even further up, because 1 is a crappy leader (or whatever), he can create his own bubble and join it, becoming leader there and being able to speed time up even until he reaches Mars faster than 1 and 2.
6. Now 1 and 2 reach Mars, too, just some 5 real-time minutes later. 3 is hanging there in Orbiter, but feels lonely, so he joins the fleet bubble again.
7. His client slows him done immediately, because 1 and 2 are like 2 sim-weeks earlier at Mars due to the optimized course. So 3 can now either wait 2 weeks in x0.1 acceleration until the default algorithm synced him, or he can just use the ScnEditor to time-skip him back with orbit propagation.
Also how do bubbles interact with other bubbles if one ship of bubble 1 enters bubble 2, and is there a certain distance the players must be from/with the leader?
It is really simple: if clients are in sync in a space-time bubble, they see each other.
So you have 2 parts: space and time.
Sync in space is at the moment defined by the server-wide "sub-visual distance" parameter. This parameter defines the meaning of "being in visual range". A value of e.g. 1000 of the parameter means, that something of the size of 1 m is only visible to you, if it is less than 1 km away. Of course you can set this value very high (like with the ORL setups), so "sync in space" basically means "orbiting the same celestial object".
Sync in time is defined by the bubble you are in AND a client-side epsilon parameter. This parameter specifies the max. deviation of your simulation's MJD from the bubble's MJD. If your deviation is small AND you are in the right bubble (simple ID check), your are "synced in time".
If you are synced in space and in the right bubble, the server already starts to broadcast neighbour information to you. If a client receives neighbour information, it sends state-infos to the neighbours. If you receive state-infos from neighbours and you are synced in time, the appropriate neighbours are displayed. That's it.
I like the bubble system because it allows for the server owner to decide if they want a universal time or if they will allow players to set their own times. Will there be a voting system like stated earlier with the time warp requests?
ATM I don't plan to restrict the amount of bubbles a user can create. Maybe I'll add a permission system later, but this is far in the future. As for the voting system: I don't see the need for a voting system with the bubble concept. If you are not happy with the current bubble leader, create your own. If you are not happy with the loneliness in your bubble, convince others to join it, thereby accepting you as leader. If you can't convince 'em... tough luck.
regards,
Face