New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About AsherMaximum

  • Rank
  1. 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.