KSP 2 Multiplayer Discussion Thread

[brain__washed]

On 5/11/2020 at 4:02 PM, Metallic_Hydrogen said:

Im a griefer myself and in some scenarios the room master absolutely cannot know which player's jealous of your Jool shipyard and is designing an interseller missile to destroy it.

Launching an interplanetary mission from Kerbin to grief another player. I wouldn't even be mad, that's some hardcore dedication there.

On a more serious note, things like this will allow for some awesome roleplaying.

Additionally, I'm really looking forward to playing with my brother again. I really enjoyed just building communication/resource infrastructure networks together using DMP. The idea of being able to do something similar in stock KSP2 just brings a smile to my face.

"Hey bro, I wanna fly a mission to Jool with this sweet spaceplane I just made, anything I should know?"
- "I just brought a ton of fuel from Minmus to my LKO gas station I built last week, just stop by for some juice and to clean the cockpit windows, you should be good to go!"

[adhkl518]

Kerbal space program 2 -NO

Kerbal Star Wars program 2 -YES(Be sure

[Lewie]

On 5/21/2020 at 6:01 AM, adhkl518 said:

Kerbal Star Wars program

Or perhaps the United Federation of kerbals...boldly waddling where where no Kerbal has waddled before!

[dnbattley]

A healthy debate seems to be raging in the community regarding how KSP2 is coming along. I share some of the concerns, while at the same time being far more relaxed than others. I am sure the developers are seeing these debates too, and I hope there is some discussion around how best to update the community regarding their progress.

However, there is one really important question that I am keen to know, and that is have the developers determined the UX question of multi-play vs time warp? If they have, then I'd love to know how, and if they have not then I'd have serious fears as to effectiveness of the design process, as this question gets to the heart of some pretty fundamental areas within the philosophy of KSP, and by extension will heavily influence the design parameters of the underlying physics engine.

I'd like to explore these with this forum, and invite thoughts and comments to see if the collective brainpower of this forum can help in any way.

So what is the problem?

Well in a nutshell, we take it for granted that KSP uses "real" physics. That means that, absent the cheat menu (or equivalent mods), you cannot instantaneously move from point A to point B: to do so takes time, design (i.e. dV) and skill (manoeuvring). Time spent traversing the vast interplanetary void can be compressed into a human-enjoyable span through time acceleration. This puts the a god-like power of time compression into the hand of the player/observer and, for KSP1, just works.

Well what happens when there are two observers?

Well if one is strictly an observer, and one is a player, then we have the situation of watching a Brad Whistance or Matt Lowne YouTube video: one observer entirely devolves authority to time compress into the hands the player, who uses that power as they see fit for their enjoyment/control and for the benefit of their audience. Similar authority could be envisaged where players are cooperating on a single vessel/goal and one player is assigned a role of "captaincy", but the crucial point is that role has the responsibility, and would typically be trusted not to want to time warp their vessel into a planet at max speed - deliberately or otherwise. This would be possible as a multiplayer solution, but how roles would be shared and defined would significantly determine the viability and enjoyment of the players.

What if other people don't want to hand over all time-compression authority to another player?

If two people are simultaneously and actively playing on different vessels, then their flight characteristics, and hence time-compression wants, will be different. For two players a compromise should be straightforward: player 1 could highlight that they want to accelerate time, player 2 could either agree or disagree. Where they agree time can then accelerate to the lowest accelerated speed they both accept; where they disagree time remains in the lowest speed needed by either of them (which is probably, but not necessarily always, single speed). Given minute changes in dV can adjust the time it takes to intercept with a planet from seconds to weeks apart, this could cause some challenges on a multiplayer mission.

This already causes some problems for both players, making the experience slower and potentially less enjoyable, but what happens when there are 3, 4, or more active players in a single game reference, each of whom are making active or passive choices to change game speeds. Very quickly the likelihood of all players finding unanimity drops to zero, and that's before you consider the possibility of AFK or "trolling" influencing the situation. In that situation, envisaging a "large scale" form of play, one spanning any significant distance, becomes difficult at anything other than "real time" speed.

Ok: so each player chooses their own speed: problem solved?

Not really: that solves the single player experience but makes the multiplayer interaction little more than the ability to see "ghosted images" of where players would have been or will be. Meaningful/physically accurate interaction between vessels in space becomes near impossible, and the multiplayer experience is reduced to short-term flights around one or more agreed "rendezvous" points. And even then, within those points the interaction can only be between players consenting to a single time reference, so you would not see, for example, a player screaming in from inter-planetary space to seamlessly join in with multiplayer action, unless that person was willing to accept some for of "time-slippage" where they move from control over their time reference, to not controlling it. These "bubbles of unreality" would partially solve a multiplayer requirement, but arguably run counter to the ethos of KSP, where reality is, broadly, a "firm" concept.

So multiplayer in a "realistic game" is impossible?

It's hard to answer that: certainly you cannot require that people give up their lives to "feed the tamagotchi" of a mission that happens to need to require all participants converge on a single point in real-time over missions that might last weeks or even years of in-game time if they do not have any control over that reference time, but equally you cannot easily compress time universally to the enjoyment of all players, without giving them individual control. Flight simulators have certainly found solutions whereby voluntary "bubbles" allow single-reference interaction if a player so chooses, but those are arguably quite specialised games and may not appeal to all of the KSP demographic, and (going back to the original point of this post) almost certainly needs to be coded in from deep within the game engine.

A multiplayer mission to the Mun, for example, would be fundamentally different to a multiplayer experience of players flying planes around the KSC. And also incompatible with each other. Could a multiplayer approach accommodate both? Possibly, but you may need to decide which "version" you were playing prior to launch, and would easily become quite confusing for players.

So what do you think? Am I over-stating this problem? Are there other solutions? This is where your comment below can help...

[Geonovast]

Overlapping threads have been merged.

[dnbattley]

1 minute ago, Geonovast said:

Overlapping threads have been merged.

Thank you: I had just finished writing a mea culpa about that...

[Bej Kerman]

On 5/4/2020 at 8:17 PM, Lewie said:

I just had a great idea-

Formation flying. I’m going to build f-18 super hornets and hopefully, with the new paint mechanic I can paint ‘em blue and gold. Me and some friends will do formation flying...cus why not?

Don't forget the 400 knot hot air balloons

[Lewie]

2 hours ago, Bej Kerman said:

Don't forget the 400 knot hot air balloons

Phfft. 400 knots? That’s rookie style....it should be an orion drive powered ballon...

[Pthigrivi]

Im also deeply skeptical that multiplayer can really work well with ksp. Following on the paradox problem discussion, it seems like the only way to do this would be if the player who is farthest in future sets the ‘present’ and other players can only interact with other craft while synched to that ‘present’. The biggest problem with that is if you’re coming in to dock with a station and another player time-warps ahead of you the station would become non-interactive and the rendezvous would be wasted. You’d have to zoom into the lead and put in a “don't warp ahead of me” request. This seems like the least annoying way to let players progress at their own pace and avoid paradoxes. 

Edited June 8, 2020 by Pthigrivi

[Nev Reno]

i think multiplayer would be similar to Elite Dangerous where the galaxy is there and anyone can go anywhere they pleased, or something like a 5 to 10 player limit on a server that a host created and can be seen from a list of servers similar to paradox's Stellaris multi.

[Doc]

On 6/8/2020 at 4:42 AM, Pthigrivi said:

Im also deeply skeptical that multiplayer can really work well with ksp. Following on the paradox problem discussion, it seems like the only way to do this would be if the player who is farthest in future sets the ‘present’ and other players can only interact with other craft while synched to that ‘present’. The biggest problem with that is if you’re coming in to dock with a station and another player time-warps ahead of you the station would become non-interactive and the rendezvous would be wasted. You’d have to zoom into the lead and put in a “don't warp ahead of me” request. This seems like the least annoying way to let players progress at their own pace and avoid paradoxes. 

Seems like there is a half-option in there, where things 'owned' by other people are 'on rails' in terms of your ability to manipulate them. An easy way to deal with this would be to load Other Peoples Ships (OPS) as a single unified object. You can dock with them, etc, but you can't change their orbit / orientation etc unless that's been somehow flagged by the owner. 

Can use this with timewarping as well; if someone is 'in the future' any craft they have interacted with gets locked onto rails until that point. 

That'd actually open up some pretty neat opportunities for you to interact with your own ships

 

 

[Pthigrivi]

22 hours ago, Doc said:

Seems like there is a half-option in there, where things 'owned' by other people are 'on rails' in terms of your ability to manipulate them. An easy way to deal with this would be to load Other Peoples Ships (OPS) as a single unified object. You can dock with them, etc, but you can't change their orbit / orientation etc unless that's been somehow flagged by the owner. 

Can use this with timewarping as well; if someone is 'in the future' any craft they have interacted with gets locked onto rails until that point. 

That'd actually open up some pretty neat opportunities for you to interact with your own ships

 

 

I want to agree to this but usually the reason you’re interacting with stations and bases is to add modules or to add or pull resources. Even if a vessel’s orbit doesn’t change those changes to its state will result in paradoxes unless all of them happen at the furthest forward point on the timeline. 
 

I don’t necessarily think this is would be a game killing restriction either. It would encourage players to stick together time-wise without locking them to the same warp and making the game essentially turn based. Its just that only the lead player or players can interact with communal projects. Everyone else can still build, launch, explore, and position their vessels before joining or requesting to take the lead as they move in to dock. 

Edited June 13, 2020 by Pthigrivi

[mattinoz]

On 6/14/2020 at 12:28 AM, Pthigrivi said:

want to agree to this but usually the reason you’re interacting with stations and bases is to add modules or to add or pull resources. Even if a vessel’s orbit doesn’t change those changes to its state will result in paradoxes unless all of them happen at the furthest forward point on the timeline.

Recent comments suggest funds are being de-emphasised in the game maybe but could actually be used to umm.. resolve such a paradox . Price resources based on the paradox they cause. Supply vs known demand. Selling a resource like this would generate a contract for a player to pick up and complete before the allotted time but they can jump back to anywhere they want in the timeline to start on it. . 

to me a modded multiplayer to create a system like that would be great. Embrace paxadox us it as a way of generating mission ideas for other players on your server   
 

you could even use it single player to play a mission backwards. 

 

[Barrackar]

On 5/24/2020 at 6:53 PM, dnbattley said:

Ok: so each player chooses their own speed: problem solved?

Not really: that solves the single player experience but makes the multiplayer interaction little more than the ability to see "ghosted images" of where players would have been or will be. Meaningful/physically accurate interaction between vessels in space becomes near impossible, and the multiplayer experience is reduced to short-term flights around one or more agreed "rendezvous" points. And even then, within those points the interaction can only be between players consenting to a single time reference, so you would not see, for example, a player screaming in from inter-planetary space to seamlessly join in with multiplayer action, unless that person was willing to accept some for of "time-slippage" where they move from control over their time reference, to not controlling it. These "bubbles of unreality" would partially solve a multiplayer requirement, but arguably run counter to the ethos of KSP, where reality is, broadly, a "firm" concept.

So what do you think? Am I over-stating this problem? Are there other solutions? This is where your comment below can help...

There are other forms of interaction which will be available in KSP2 rather than direct ship to ship formation flying/docking/interaction. KSP2 has indicated, for example, supply routes being an important mechanic for establishing permanent colonies. In multiplayer you can coordinate so one player builds the station, another player establishes a supply route for say liquid fuel, and another establishes a supply route for water or what-have-you. Simple tools like ability to mark a location/waypoint for the intended base/station to coordinate these efforts and the option to spectate the status of each other's mission involves more interaction than passively watching ghosted images. Each player would see the results of the efforts combined in the final colony/station etc. and whatever further mechanics KSP2 operates.

[Doc]

On 6/17/2020 at 1:28 PM, mattinoz said:

Recent comments suggest funds are being de-emphasised in the game maybe but could actually be used to umm.. resolve such a paradox . Price resources based on the paradox they cause. Supply vs known demand. Selling a resource like this would generate a contract for a player to pick up and complete before the allotted time but they can jump back to anywhere they want in the timeline to start on it. . 

to me a modded multiplayer to create a system like that would be great. Embrace paxadox us it as a way of generating mission ideas for other players on your server   
 

you could even use it single player to play a mission backwards. 

 

That seems rather clever, and a good way to handle the issue of resource-raiding OPS - you can't load stuff from OPS unless they have flagged it as 'available' and put some sort of price on it. 

 

Would also provide a neat dynamic to encourage building of multiplayer stations, with extra capacity etc. Also, finally a reason to figure out how to extract resources cost effectively. I can see some people getting totally in to designing & operating an out-system giant mining ship...

[minerbat]

When i heard that we would get multiplayer, for some reason the FIRST thing that came into my head was not something like "cool!" or "icantwaittoblowmylittlebrotherup!" but the first thing my brain came up with was "but how would timewarp work?" anyone any answer?

[razark]

1 hour ago, minerbat said:

but how would timewarp work?

Badly.  There's multiple ways to handle it, and some disagreement on what is best.

See here:

 

[Gargamel]

Overlapping threads have been merged. 

[PlutoISaPlanet]

They should have a "space race" mode were you choose a celestial body, and you have a miniature space race to get their. EX. First to mun wins.

[MacAphon]

18 hours ago, PlutoISaPlanet said:

They should have a "space race" mode were you choose a celestial body, and you have a miniature space race to get their. EX. First to mun wins.

Actually I don't think, that there would have to be a seperate mode for this. You could just agree to a destination and when you got there you can just show them your ingame time to them and determine the fastest player that way.

[PlutoISaPlanet]

1 hour ago, MacAphon said:

Actually I don't think, that there would have to be a seperate mode for this. You could just agree to a destination and when you got there you can just show them your ingame time to them and determine the fastest player that way.

BIG BRAIN TIME. Seriously you are right. I do want a pvp mode in the game, along with co-OP. 

[Soda Popinski]

Here's another idea inspired by Elite: Dangerous.  In that game, at 6:00 am UTC every day, the servers shut down for 15 or 30 minutes and the galaxy updates based on the actions of the player base.

I could see a small player run server with 2 to 4 players on it running a similar mechanic, where you play at real-time most of the time, then every 6, or 12, or 24 hours or whatever the game time-warps to the next "alarm" point or maneuver-node.  Optionally, the player who's alarm went off can let time-warp continue when they're done, so the next player can take their turn.  This would let a few people play with interplanetary or even interstellar travel.

[Square365]

Does anyone know if there will be a player limit? 

and has there been any server specs aproximations? Like 1gb per 50players

I really wanna know if its going to support 80 players+ like to run a whole space program team, i would love it!

[razark]

33 minutes ago, Square365 said:

Does anyone know...

The only thing that we know is that they have announced it will have multiplayer.

[AsherMaximum]

I've written up a posting of how multiplayer could work on Reddit, which I've posted here below as well. Been playing KSP for years, but haven't interacted with people online, so I'm not sure which is the place that more people use to discuss KSP.

----------------------
 

With KSP 2 coming soon, I've been thinking about how multiplayer could work in a way that would add something to the game and prevent griefing. To do that, there needs to be the ability to share spacecraft, without making it so that someone else can come along and de-orbit the mission you were in the middle of when you logged out. Also, timewarp has to be handled.

Here's what I've been thinking of. In the below, "craft" means any probe core, command module, or Kerbal. A "vessel" can have multiple craft on it.

So, for example, the Apollo missions, the command module that stayed in orbit would be one craft, and the lander would be another, and when docked together, they would be a single vessel. An astronaut on EVA would be it's own craft and vessel.

Permissions

First, every craft has an owner, which is the player who launched it. All craft on the launch vessel will have their owner set at launch.

Second, every craft has a permissions rating, which can be changed at any time by the owner.

Three levels:

• - Private
• - Shared
• - Global

Private craft can only be interacted with by the owner. If other craft come within physics range while the owner is not controlling it, it is turned into a ghost, and other craft will fly right through it. If the owner of a ghost craft logs in while the other craft is intersecting it, the craft stays in ghost mode until the craft owner flies it out of collision range.

Shared craft can be interacted with by anyone, but flight control is not allowed (thrusters, RCS, SAS). For interaction, the craft must have a probe core, as other players cannot control someone else's Kerbal. If a manned craft with no probe core is docked with by another craft, the owner of that craft (or anyone if it is a shared craft with a probe core) can now interact with the craft. Fuel can be transferred, science experiments run, and other modules activated. Undocking is not allowed while controlling a shared craft, to prevent players from undocking modules they cannot control. To undock, you must do so from the craft you are trying to undock, which must be owned by you or set to Global permissions. When docked with a shared craft, your flight control is disabled until you undock. If a shared craft owned by another player docks with your shared craft, you still need to be able to have flight control over your craft. See Priority below for how this is resolved.

Global craft follow the same rules rules for interaction, but also allow for flight control and undocking of the craft. Only probe cores can be set to global.

Science and funds are not shared. When you run science experiments on a shared craft, you get the science. There could be an option for the craft owner to require you to share a certain percentage of it with them.

If a global craft is landed and recovered, the funds for recovery go to the owner, and any science is split equally between the owner and the player who recovered it.

If the owner of a Private or Shared craft logs out or is disconnected while the vessel is on a sub-orbital trajectory, the vessel is frozen in place and set to ghost mode until the owner logs back in & controls the vessel.

A craft owner has the ability to transfer ownership of a craft to another player, which cannot be reversed. An explicit dialog window warning of this should be displayed when transferring ownership. The original owner is not retained, once transfer is complete it is the same as if the new owner launched the craft. Kerbals cannot have their ownership changed, and permissions are always set to Private.

Priority

For shared and global craft, only one player can control a craft at a time. If multiple players are controlling global craft on the same vessel, this could cause a problem. To solve this, a priority must be established to give only one craft flight control over the vessel. I'll call this craft the vessel leader.

If a vessel is built with multiple craft on it, the vessel leader can be set during assembly. For vessel leader determination during docking, the vessel being docked with remains the vessel leader. The vessel leader can be transferred during flight, but only by the owner of the craft that is the vessel leader.

So, if a shared refueling station is in orbit that is not owned by you, you can dock with it, transfer fuel with it, but you cannot use flight controls while docked. If the vessel leader owner starts controlling the vessel, they can use flight controls.

If you dock with a vessel whose vessel leader is set to global, your flight controls remain active, unless someone else is controlling the vessel leader craft.

Time Warp

The big, complicated monster of multiplayer timewarp.

I think the goal should be to have everyone at the same point in time as much as possible. There is of course a need for players to control the current time while they are controlling a ship, but time warping should be forced at the earliest opportunity.

Uncontrolled orbital vessels warp along with the furthest ahead timeline. If a vessel that is orbital becomes sub-orbital due to changing spheres of influence during warping, it is immediately frozen & ghosted, not becoming active again until the owner takes control of the vessel. If the vessel leader is set to Global permissions, any player can take control of the vessel (or already be controlling it) to make it active. If a vessel whose vessel leader is set to Shared becomes sub-orbital, the entire vessel is frozen and ghosted until the owner takes control of it. This means that if you are docked with a shared vessel that becomes sub-orbital, you will not be able to undock your craft until the vessel leader owner takes control of the vessel.

Uncontrolled vessels on an escape trajectory are also frozen in place until controlled when entering the new sphere of influence, but only if that trajectory is also an escape trajectory. They are kept on the furthest ahead timeline. This is to prevent someone else's time warp while you are offline causing your craft to just fly by the orbital body you are heading for.

Sub-orbital vessels that are not controlled by a player are frozen in place and ghosted when time is warped, staying with the furthest ahead timeline.

For online players, any players controlling craft within a single physics simulation area must warp together. The warp controller is set randomly as soon as the craft two players are controlling come within physics distance. The warp controller can transfer warp control to other players in the area if they want.

If an additional player come within physics distance of the craft those two players are controlling, the warp controller stays with the current player.

If the two physics areas that both have multiple players, the warp controller of the larger group is the one who stays as controller. In the case of groups of the same size, the warp controller is picked randomly from the two current warp controllers.If there are any uncontrolled vessels in the area, if the vessel leader permissions are set to Shared or Global permissions, they follow the timeline of the controlled craft. If uncontrolled vessels leave the physics area, they are immediately warped to the furthest ahead timeline.

To allow for docking, when a vessel is targeted, it's timeline stays with the targeting vessel, as if it was still within the physics distance.

If a craft that is targeted is controlled by another player or becomes controlled by another player, the rules for selecting a warp controller apply. However, the controller of the targeted vessel is given the option of not accepting the target request. If they don't accept, the vessel is unable to be targeted and kept in the same timeline.

For craft that are not within physics distances, warping is done separately. When a vessel is behind the furthest ahead timeline, the player can choose to warp ahead to the furthest ahead timeline at any time. Any craft that are not on the furthest ahead timeline can only interact with vessels were part of the timeline when they first fell behind; all other vessels are shown as ghosts until they are both are on the furthest ahead timeline. If a vessel is intersecting a ghost vessel when it catches up with the furthest ahead timeline, the vessel becomes ghosted until it is no longer intersecting with the previously ghosted vessel.

Any controlled craft that fall behind in time due to another player warping are kept on the same timeline as each other, unless one of the controlled craft is warped. At that point another new timeline is created, with all craft in physics distance or targeted kept in that timeline.

Timelines that are behind the furthest ahead vessel are all separate, even if one of them catches up to another that is not the leading timeline.

When a player stops controlling a vessel, it and all vessels on the same timeline, whether due to physics influence or targeting influence, are immediately warped to the furthest ahead timeline. Switching between vessels in the same timeline does not cause warping to happen, nor does going to the tracking station, but as soon as the player switches to a vessel that is not in the same timeline, or goes to the Space Center, warping to the furthest ahead timeline happens. A player should be warned of this before stopping controlling a sub-orbital vessel by leaving the tracking station or switching to another vessel from the tracking station.

Special handling is needed for when a player is disconnected while not on the furthest ahead timeline. If that happens, when the player logs back in, they should be given the option of switching to one of the vessels on that timeline, or warping to the furthest ahead timeline. This could be done by taking them to the tracking station when they log in instead of the KSC.

Reverting Launch

Reverting a launch would remove the craft from flight, return the funds to you, and return the Kerbals to your Astronaut Complex. Time progression would be retained. Once a craft comes within physics range of another craft, reverting the launch is no longer possible.

Quicksaves

When quick loading from the leading timeline, a new older timeline is created. If the controlled vessel was targeting another vessel or within the same physics sphere as another vessel, those vessels are reverted to the new older timeline as well. If other players are now controlling those vessels, they are given the option to go to the new older timeline, or stay where they are at. If any players chose to follow the timeline of the quickload, the player who initiated the quickload is designated as warp controller for the new timeline.

For older timelines, only the warp controller can quickload. Anyone can quicksave, and when quickloading, the warp controller chooses whose quick save to revert to.

Shared Science and Funds

As mentioned above, science and funds are separate, but what if players want to work together on those too?

In that case, players can join the same company. Then, in all of the above, "owner" is not a player, but a company.

A mechanism for sharing science points and funds could also be enabled on a per server basis, with a configurable percentage deducted for doing so.

For sharing science on joint missions between companies, an option could exist on the craft to set a science split, which could be set and changed at any time by the craft owner.

Miscellaneous

Not covered in other sections:

Science from Mobile Processing Lab (and anything similar in KSP 2) - Science is done by the Kerbals, so if a mobile lab has Kerbals in it that have a different owner than the vessel owner, that owner gets the science. This means that one lab can generate science for two owners. Data for science processing is shared evenly between the two in that case. It also means a player can place data for processing into a lab containing Kerbals they don't own, generating science for their owner instead of themselves.

Ground stations (Breaking Ground expansion style science) - They are treated as a craft, but can only be set to private.

Simultaneous launches - only one player can use the launchpad at a time. If there is a vessel currently waiting to be launched that contains shared or global craft with empty seats, a player can add their own Kerbals to it before it is launched. Only the owner of the Kerbals can EVA or transfer the Kerbals to another craft.

To allow for larger servers, multiple launchpads should be available at the KSC, oriented north-south, so that the vessels will not run into each other when launching at 90/270 degrees.

Same rules apply to the runway. It would probably be a good idea to have two of those, with one running north-south and one running east-west.

Collisions

A server option should be available that makes shared and global vessels indestructible, to prevent players from intentionally or accidentally destroying other players vessels. This could be granular, and either apply to all shared and global vessels, or only ones not owned by the player (to keep the realism of difficult docking when docking with your own shared/global vessel). An option could also be added to only make them indestructible when the relative speed of the vessels is above a certain threshold, in an attempt to allow for the realism of true accidental damage, while still preventing intentional damage. An option to make indestructible vessels also be immovable should also exist, to prevent de-orbiting vessels by pushing them without docking.

Asteroids - Once grabbed with an arm, the asteroid becomes part of the grabbing vessel. If the vessel leader is Private, the asteroid is ghosted along with the rest of the vessel when the owner is not controlling it. No other vessels can use a grabbing arm to connect if the vessel leader is Private.

If the vessel leader is set to shared, the same rules apply as for other craft - other craft can dock with grabbing arms, but they cannot use flight controls once docked.

Ground vehicles - While not technically "flight", the rules for flight apply to those too - shared ground vehicles cannot be driven by anyone but the vessel owner, and if you dock to them, your movement controls are disabled.

Performance - To minimize impact to other players due to larger ships, processing for each physics sphere of influence should be on a separate processor core.

What does "frozen" mean?

When a sub-orbital vessel is frozen, it follows the furthest ahead timeline, but does not move from it's current location in relation to the orbital body. Only sub-orbital vessels are ever frozen.

Frozen vessels sphere of influence change

A frozen vessel could potentially end up in the influence of a moon of the current planet it is orbiting, or the influence of a planet if it's sub-orbital path is relative to Kerbol.

If this happens, upon controlling the vessel, the player is warned of this before the vessel is unfrozen, and given the opportunity to accept the new sphere of influence, or warp ahead until the sphere of influence returns to the original orbital body. If the vehicle's position is inside the new orbital body, accepting the new sphere of influence should be grayed out. Otherwise, the distance from the new orbital body should be displayed.