KSP 2 Multiplayer Discussion Thread

[Vl3d]

I think I'll buy KSP2 EA, I'll subscribe to KSP2 multiplayer and also buy all the DLCs.

[pandaman]

Disclaimer...  I have never used any multiplayer mods so can’t  comment on specific issues at all.   But from what I have read on here, no solution is perfect.

When ever I see the kind of statements that say 'But (this mod) does it fine' I get the feeling 'except  for...' is always omitted.

 

[Talavar]

5 hours ago, pandaman said:

Disclaimer...  I have never used any multiplayer mods so can’t  comment on specific issues at all.   But from what I have read on here, no solution is perfect.

When ever I see the kind of statements that say 'But (this mod) does it fine' I get the feeling 'except  for...' is always omitted.

 

 Ghosting was the main problem, due to how it was slapped over top of the original game code, and not in the normal cycle. So for instance, Luna would detect your orientation, coords, vector, etc, then send it to the server. It would do it again very quickly, and would basically delete the old copy of your ship, then create it again instantly. It worked very well, and felt smooth. however it seems that sometimes it would miss an execution loop on loading a new ship that's already on the ground in the world somewhere, or loading in another player in your loading zone, and cause a ghost ship to be placed in the same location as your ship, causing an explosion.. basically it made 2 ships simultaneously in the same position, so the game would detect a collision... boom.  It happend roughly 5% of the time for us, so we'd have to quickload every so often. But when it was working well, it was really fun.

Edited November 5, 2022 by Talavar

[Rutabaga22]

7 hours ago, Vl3d said:

I'll subscribe to KSP2 multiplayer and also buy all the DLCs.

Subscribe to multiplayer?

Buy DLCs?
 

I didn't see that in the EA roadmap.

[Talavar]

7 hours ago, t_v said:

I am guilty of this. 
 

But on the topic of who hosts the servers, I hope that it is a dual solution: independent parties can run the server software on their computers, but Intercept also does first-party hosting as a subscription service. Server hosting is a good way to make a bit of money, and the benefit of a first party service is that for the user, they get good integration and ease of use, and a standardized stable connected host machine. The developers should develop their multiplayer software to work well on many devices, but there will always be specific configurations that run that specific software better than others. Most independent parties will not invest in machines just to run KSP 2 servers, and so the way to get high-performance stable servers are to pay for hosting. Intercept can provide that with the additional benefit of good integration, and making money this way will keep the game afloat for longer. I personally will use old machines to run servers whenever I can, but for a large portion of the target audience, this would be a good option to use, and this would generate a fair amount of revenue. What do you think?

 Honestly,  it shouldn't take too much to run a server, since it will only deal with pre-calculated numbers by other peoples systems. For instance, your client computer will simply report DV, orientation, vector, etc, and the server will recieve precalculated movement info.. the only time things might get rough is during a collision. Which still may be handled by client computers, making the server just a relay of numbers from client to client. If that's the case it might not take much to run it at all.

[t_v]

1 hour ago, Talavar said:

 Honestly,  it shouldn't take too much to run a server, since it will only deal with pre-calculated numbers by other peoples systems. For instance, your client computer will simply report DV, orientation, vector, etc, and the server will recieve precalculated movement info.. the only time things might get rough is during a collision. Which still may be handled by client computers, making the server just a relay of numbers from client to client. If that's the case it might not take much to run it at all.

I think that the performance depends on how multiplayer is implemented. I detailed this in another thread but for one example, doing the calculations on the client versus the server makes a huge impact on performance, and you might want to do calculations on the server when there are lots of background missions or someone is trying to use a modified client. And no matter how performant the system is, people will try to push it. At that point, you either own a server or rent one, and renting one from the first party has a few benefits like keeping the game funded for longer. Not as many people will rent servers if they don’t reach meaningful limits on their machine and network, but having that service would still benefit some people and the devs. 

[Guest]

[Removed]

Edited September 16, 2023 by Guest

[jjansen]

Best breakdown of this topic I've seen so far.

Option 3 can only work for single conics though, unless you're snapping to new worlds whenever SoI changes.

[Guest]

[Removed]

Edited September 16, 2023 by Guest

[Ryaja]

I have another idea, what if the player timewarping disappeared to all the other players, unless they were at the time when they stopped timewarping so if someone timewarped really far into the future they would only see other players colonies not vessels, unless a vessel was timewarped so essentially vessel specific warp(With a universal time that never timewarps that you cannot control a vessel from before then.)

[mcwaffles2003]

47 minutes ago, Sprocket Creations said:

Yes. Option 3-4 take advantage of KSP's conics system, and would not be practical in an n-body simulation. For Rask and Rusk, I assume they share a single conic/SOI.

The Rask and Rusk system has a SOI around it but it is N-body inside.

An option not explored is similar to 2, but instead of 1 person controlling timewarp have timwarp go as fast as the slowest persons requested time warp. In general the game would move slower but everyone would remain synced, and since the point of multiplayer is to interact with other people I think staying in sync is important.

[Guest]

[Removed]

Edited September 16, 2023 by Guest

[mcwaffles2003]

4 hours ago, Sprocket Creations said:

That is a great suggestion. It has a minor flaw that an afk/evaing/bad actor player would prevent time warp entirely, but I'm sure there are solutions to that.

I agree that players should stay "temporally" in-sync, as otherwise it's just single player with a chat.

That's why moderators/administrators exist. Or just make it so servers can detect afk people

[Vl3d]

First of all, my proposed solution is missing from the list, so I will link it:

All versions in OP break causality, only 3/ 4 are kind of functional but introduce FTL or arbitrarily powerful engines (completely unacceptable). The idea of 1 is good only if the server controls resyncing.

I really don't get why everyone wants to force time zoom to work in a multiplayer setting. Just separate the two - you only get to warp when not synced to multiplayer. You always play multiplayer in real-time. Problem solved.

15 hours ago, Sprocket Creations said:

A warping vehicle may miss its destination planet due to arriving too early (see solution below)

If you can time warp only when desynced from multiplayer, everything you do while warping is basically single player and is in accordance to the rules of physics, you do not use FTL because you are traveling as a single player.

The main idea is that players can control either speed of time or speed of movement. Both of these are unacceptable in a multiplayer setting. So in the real time bubbles all gameplay time should be controlled by the server. Period.

So, of course, the main issue is: how do you explain the universal time jump when syncing to the multiplayer real time bubbles for all observers without using crutches like FTL? Easy, do not show Universal Time, instead focus on mission time, syncing star system configuration (everything on rails is cyclic). Time becomes an ordered sequence of actions and milestones players have reached.

The most fundamental problem is the refusal of players to give up on controlling time zoom in multiplayer. These concepts are absolutely incompatible because of paradoxes. Separate them with a journey planner and desyncing from MP when going to (deep) space and all problems are solved.

Edited November 13, 2022 by Vl3d

[Bej Kerman]

1 hour ago, Vl3d said:

First of all, my proposed solution is missing from the list, so I will link it:

It's not missing, it just wasn't added.

1 hour ago, Vl3d said:

All versions in OP break causality, only 3/ 4 are kind of functional but introduce FTL or arbitrarily powerful engines (completely unacceptable). The idea of 1 is good only if the server controls resyncing.

I really don't get why everyone wants to force time zoom to work in a multiplayer setting. Just separate the two - you only get to warp when not synced to multiplayer. You always play multiplayer in real-time. Problem solved.

You don't explain where the problem is with the solutions in the OP, you just imply that breaking causality is bad without explaining.

1 hour ago, Vl3d said:

The main idea is that players can control either speed of time or speed of movement. Both of these are unacceptable in a multiplayer setting. So in the real time bubbles all gameplay time should be controlled by the server. Period.

It's not "period", again you never explain yourself, you just assert that your given solution is the best without explaining why timewarp should be taken from players in certain scenarios.

1 hour ago, Vl3d said:

So, of course, the main issue is: how do you explain the universal time jump when syncing to the multiplayer real time bubbles for all observers without using crutches like FTL?

You ignore it. It doesn't need explaining. The only thing that matters is that players have agency over how they spend their time. If two people want to play together, they sync and stay at 1x warp. If player B decides they no longer want to be with player A or has tasks to do elsewhere, they timewarp off. It shouldn't be restricted just for the same of making things slightly more immersive.

[Ashandalar]

1 hour ago, Vl3d said:

I really don't get why everyone wants to force time zoom to work in a multiplayer setting. Just separate the two - you only get to warp when not synced to multiplayer. You always play multiplayer in real-time. Problem solved.

Because we want to do more in multiplayer than racing rovers.

[Vl3d]

38 minutes ago, Ashandalar said:

Because we want to do more in multiplayer than racing rovers.

And what exactly are you saying you can't do?

[Rutabaga22]

30 minutes ago, Vl3d said:

And what exactly are you saying you can't do?

Without warp you can't do a normal interplanetary mission in multiplayer. There are some games I play with friends where we share a world or something, but are doing different things. The joy comes from being in a game with friends and seeing their accomplishments. I play minecraft with my father and while he builds a prison, I might be building a secret base, but we both will show each other our builds.

I think the easiest way to do timewarp is to have it so if you are playing in real time, you see other players' missions in real time. Under warp? You see other players' missions going faster. If the server controller wants, they can sync the global time.

[Vl3d]

49 minutes ago, Rutabaga22 said:

Without warp you can't do a normal interplanetary mission in multiplayer. There are some games I play with friends where we share a world or something, but are doing different things. The joy comes from being in a game with friends and seeing their accomplishments. I play minecraft with my father and while he builds a prison, I might be building a secret base, but we both will show each other our builds.

I think the easiest way to do timewarp is to have it so if you are playing in real time, you see other players' missions in real time. Under warp? You see other players' missions going faster. If the server controller wants, they can sync the global time.

It's a hybrid system. Keep in mind that there would be 2 types of real-time multiplayer bubbles that can be exited at any time through time-warp and re-entered at will (choosing to sync to server):

• celestial body + atmosphere / low orbit
• custom sized (for space stations)

Let me give you a proper example. Let's say players A and B are doing a race to the Mun.

• Phase 1 - Kerbin multiplayer bubble:
  • both players set the Mun as the target.
• Phase 2 - exiting real-time multiplayer and going into enhanced single-player mode while in Kerbin SOI
  • players time zoom while on the pads to the appropriate launch window (or whenever they want)
  • players launch the rockets (each one sees the star system configuration that is correct for them - it is generally different for each player if they do not launch simultaneously)
  • players use time zoom whenever they want (because they desynced from multiplayer)
• Phase 3 - orbital maneuvering:
  • let's say the players achieve orbit and they want to do a rendezvous for any reason (get so close that they enter each other's real-time bubble)
  • keep in mind that each of them see a different star system configuration on their local PC, meaning that also the orbital position of each player is desynced (but can be shown on-rails with orbits visible in map view of each player according to server updated orbital parameters, each player craft moving as in a locally controlled Master Warp solution where speeds are proportional to the player controlled time zoom factor as shown in OP))
  • each of them set the other players vessel as target, perform appropriate maneuvers (they are still in single-player, although they see the other person's craft in map view, it is a local rendition of the on-rails parameters, calculated according to each players local time and updated if another player changes orbit)
  • when they get sufficiently close to each other they enter their respective small real-time multiplayer bubble, at which point the star system configuration would ideally resync to one version for both players (so it's not daytime for one and nighttime for another - meaning the dependent resources like electricity sync to server controlled values)
  • players do whatever they want in multi-player (like dock or fly together)
• Phase 4 - burning for the Mun and coasting:
  • player A decides to leave, sets the correct target, departs the real-time multiplayer bubble
  • player B sees this in real-time, player A moves at normal speed because he is rendered on player B's PC using the on-rails values of player A's current orbit
  • B decides to leave also, but burn more to get to the Mun faster
  • B sets the Mun as target, plots the maneuver nodes to arrive faster than A, burns
  • remember, A and B are now in single-player mode on their journey to the Mun, each controls time zoom as they wish
• Phase 5 - arriving in Mun orbit:
  • Desynced in the real world - player A arrives at the Mun in 10 minutes of real gameplay time, player B goes AFK for 2 days and comes back to the game:
    • of course, in the real world, each player arrives whenever they want - this presents us with a paradox - if A arrives first in the real world, he should see in map that B was actually first in-game, but there is no one there to do the actual orbital insertion burn because B is AFK. So the game should know how to automatically perform the burn and insert B into a stable orbit as B planned before exiting the game.
    • A arrives and syncs to the Mun real-time multiplayer bubble, sees B is already in orbit
    • A does the landing
    • when B comes back to the game after 2 days, he sees he stayed in orbit while A landed.
  • Synced in the real world - players continue playing in the real-world, arrive at roughly the same time
    • both players sync to the Mun real-time multiplayer bubble, do a race to see who lands first

As you can see, there are problems with:

1. syncing the solar system configuration for all players when they enter a multiplayer bubble (can be hidden / playtested / maybe ignored)
2. correctly updating other players craft orbital positions in the map view rendered on the local PC when in single-player mode (but this should be calculated locally depending on the on-rails parameters for their crafts (that would be updated by the server), but is a source of trouble even if time zoom accelerates movement for all players, as AFK players should be held in a cyclic state like in orbit or landed and their crafts ghosted (unable to interact with))
3. syncing resources (should a player be able to warp to accelerate resource extraction or maybe extraction should be a continuous real-time action instead)

All these can be managed. The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

Edited November 13, 2022 by Vl3d

[Bej Kerman]

7 minutes ago, Vl3d said:

The most important thing is that time travel paradoxes are avoided at all costs.

Why?

[Vl3d]

32 minutes ago, Bej Kerman said:

40 minutes ago, Vl3d said:

The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

Why?

"The law of unintended consequences pushes us ceaselessly through the years, permitting no pause for perspective." - Richard Schickel

"Without reflection, we go blindly on our way, creating more unintended consequences, and failing to achieve anything useful." - Margaret J. Wheatley

[Bej Kerman]

18 minutes ago, Vl3d said:

54 minutes ago, Bej Kerman said:

1 hour ago, Vl3d said:

The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

Why?

"The law of unintended consequences pushes us ceaselessly through the years, permitting no pause for perspective." - Richard Schickel

"Without reflection, we go blindly on our way, creating more unintended consequences, and failing to achieve anything useful." - Margaret J. Wheatley

Please explain how these quotes are relevant.

[Gargamel]

Overlapping threads have been merged. 

[Pthigrivi]

18 hours ago, Sprocket Creations said:

I agree that players should stay "temporally" in-sync, as otherwise it's just single player with a chat.

Nice breakdown, Sprocket. There are some missing ones but of course there are dozens in this thread already. The above is I think the biggest misconception about multiplayer in a game like KSP. Its understandable given our intuitions from playing other games that aren’t built on orbital mechanics and timewarp. Most people think they want to be synced to the same timeframe, but 99% of time you actually don’t want that. For basically any maneuver that involves docking, landing, intercepting, transferring, etc you don’t need other players in the same timeframe. In fact except for rover racing and synchronized flying you would actually prefer other players were not synched and actively moving because tasks like orbital interception and docking are much more difficult if the target is changing course or popping in and out of existence. So long as players can synch when they want to its not a problem for them to exist in their own separate times and warp at will. 

Edited November 13, 2022 by Pthigrivi

[t_v]

2 hours ago, Vl3d said:

All these can be managed. The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

The issue is that paradoxes are not really avoidable, as far as we have seen. In your solution, when players re-sync, they are either traveling forwards or backwards through time to do so, until they reach a certain point on the cycle. This means that either ships from the past are interacting with the future in the present, or a ship from the future just went backwards through time and is now changing events in the past. Textbook paradoxes, although it doesn’t matter because from the player perspective, IRL causality is preserved (as it kind of has to be). Even the leapfrog model has its paradoxes:

14 minutes ago, Pthigrivi said:

orbital interception and docking are much more difficult if the target is changing course or popping in and out of existence.

Right, but in the leapfrog model, the target does pop out of existence. You are trying to rendezvous, and then you suddenly see the other ship has been greyed out and you can no longer dock. The alternative that I was proposing is that you see how the orbit is changing, or if they exit the SOI, you see that the ship is no longer there. Docking in the first case is impossible when another player is interfering, because you can’t interact or know where to go to find that ship again, whereas under the second solution it is made much harder, but you have the information to know where that ship’s new location is if you still want to dock with it. In either scenario, another player doing things with the ship you are rendezvousing will make things a lot harder; leapfrog doesn’t fix that, unfortunately.