KSP 2 Multiplayer Discussion Thread

[Pthigrivi]

4 minutes ago, DwightLee said:

I am going to have to think about that, exactly what that would require. You are saying never resync. If you want me to meet you on Duna if you are already there, then you will have to advance your timeline to the point where I arrive there. That everyone is playing in the same universe at different times ( unless they intentionally timewarp to when another player is also there ). I was about to dismiss it out of hand... but... you have me thinking, that might resolve all issues. All my issues anyway.

Yeah I mean you can synch with another player to be in the same real time if you want to, you just both need to move vessels into the same place and time. Then you can race rovers on the Mun or fly around Laythe or whatever you want. 

Edited April 11, 2022 by Pthigrivi

[DwightLee]

12 minutes ago, Pthigrivi said:

I guess what Im saying is why are we disconnecting these space-time realities to begin with? Just have one consistent timeline no matter where you are and then you don't have any of these problems. It's also the way to prevent seeing people warp away or gaining a competitive advantage in space races. You all exist in the same in-game calendar all the time. If Im synched in orbit with another player and they time warp I don't see their vessel zoom away. I see it gently drift away exactly as would normally, because Im seeing their vessel as it was in my timeline. They see the same vessel as it is in my future. 

Ok here is the problem, I might be in your future ( that you have not advanced to yet ) you have a base on the moon. You decide in your timeline to modify the base, but I am already in your future and cannot see the change you made.

[t_v]

Just now, DwightLee said:

Ok here is the problem, I might be in your future ( that you have not advanced to yet ) you have a base on the moon. You decide in your timeline to modify the base, but I am already in your future and cannot see the change you made.

So here the person in the last wouldn’t be able to interact with the base as it has been interacted with in the future. By the way, this solution is the same thing that LMP uses, when you re-sync the “jump” occurs because you have moved forwards in time and so have the planets and spaceships. 

[Pthigrivi]

16 minutes ago, DwightLee said:

Ok here is the problem, I might be in your future ( that you have not advanced to yet ) you have a base on the moon. You decide in your timeline to modify the base, but I am already in your future and cannot see the change you made.

Right, but you'd need to warp ahead of my last change before you could alter the base anyway in order to preserve causality. Otherwise you run into problems with multiple vessels attached to the same docking port and resource value paradoxes and everything else. As noted on a previous page that doesn't mean I have to warp ahead of you, just ahead of the last time a given vessel was altered. You also probably need to ghost future bases on the surface just so I don't build a base in your past in the same place. Thats only on the surface though. In space the chance of a collision is crazy small just like it is in KSP1.

Edited April 11, 2022 by Pthigrivi

[darthgently]

39 minutes ago, Pthigrivi said:

You also probably need to ghost future bases on the surface just so I don't build a base in your past in the same place.

Ha.  I just had an image that instead of a ghosted base, there could be stakes in the ground in a rectangle around the extent of where the future base will be and a sign that reads:

FUTURE SITE OF <name of craft> BASE. 

CONSTRUCTION TO COMMENCE <kerbin date/time when base is started>

ALL TRESPASSERS WILL BE TARRED AND FEATHERED BY <name of player>

Edited April 11, 2022 by darthgently

[DwightLee]

1 hour ago, Pthigrivi said:

Right, but you'd need to warp ahead of my last change before you could alter the base anyway in order to preserve causality. Otherwise you run into problems with multiple vessels attached to the same docking port and resource value paradoxes and everything else. As noted on a previous page that doesn't mean I have to warp ahead of you, just ahead of the last time a given vessel was altered. You also probably need to ghost future bases on the surface just so I don't build a base in your past in the same place. Thats only on the surface though. In space the chance of a collision is crazy small just like it is in KSP1.

 

51 minutes ago, darthgently said:

Ha.  I just had an image that instead of a ghosted base, there could be stakes in the ground in a rectangle around the extent of where the future base will be and a sign that reads:

FUTURE SITE OF <name of craft> BASE. 

CONSTRUCTION TO COMMENCE <kerbin date/time when base is started>

ALL TRESPASSERS WILL BE TARRED AND FEATHERED BY <name of player>

That is an interesting possibility, that could actually work. The biggest problem I see with all this is the ammount of data the multi-player game would have to hold, not only current position, but a careful record of all past positions on every single thing in the game. That is a whole lot of overhead. On the positive side however, that solution solves the issues that bothered me the most.

 

Edited April 11, 2022 by DwightLee

[darthgently]

18 minutes ago, DwightLee said:

That is an interesting possibility, that could actually work. The biggest problem I see with all this is the ammount of data the multi-player game would have to hold, not only current position, but a careful record of all past positions on every single thing in the game. That is a whole lot of overhead. On the positive side however, that solution solves the issues that bothered me the most.

I hear ya.  Truthfully, I will probably always prefer single player games, but it is challenging from a programming design angle to follow all this about making KSP multiplayer and still be able to warp.  I will definitely check out KSP 2 multiplayer, but I doubt I'll stick with it

[DwightLee]

23 minutes ago, darthgently said:

I hear ya.  Truthfully, I will probably always prefer single player games, but it is challenging from a programming design angle to follow all this about making KSP multiplayer and still be able to warp.  I will definitely check out KSP 2 multiplayer, but I doubt I'll stick with it

Me as well, I see KSP as a single player game and that is what I will be doing with KSP2 as well, but as a part of a larger gaming community I know they are going to want me to host a multiplayer version, so I am interested in what they come up with.

[Lettuce]

22 minutes ago, DwightLee said:

Me as well, I see KSP as a single player game and that is what I will be doing with KSP2 as well, but as a part of a larger gaming community I know they are going to want me to host a multiplayer version, so I am interested in what they come up with.

A multiplayer game would probably be able to do away with holding onto data from before whoever is earliest on the timeline such as taking the time from the earliest quick save and deleting all position data from before that time. The only sacrifice a player would have to make on multiplayer is probably that quicksaves will only be valid in the play session they were created in so once you disconnect from a server all of your quick saves are deleted and the server can discard position data from before the earliest still existing quick save. Anything built by a disconnected player could be placed in a frozen state upon disconnect not consuming resources while the owner is offline but still moving in its stable orbit. When the owner reconnects their builds would start consuming resources again and their time is synced to the future most player's present. Might lead to some weird super far future dates on servers but nothing that would affect gameplay and would definitely save storage on servers. I don't know how this system would handle ships on trajectories between SOI's but I'm thinking you could calculate where it would be in the server's future most player until either the owner of the ship reconnects and syncs to that time and/or the ship is in its final orbit. This is me just spit balling solutions to optimizing storage of positions of craft so I'm sure there are flaws with my idea but it shouldn't be infeasible to implement it that way.

[Vl3d]

8 hours ago, Pthigrivi said:

As soon as you hit the local SOI all the planets and moons around you would shift

No you would not. You only shift when reaching a journey destination and syncing, not during the execution of maneuver nodes.

9 hours ago, DunaManiac said:

So what you're describing is a system where each vessel has its own bubble, and you are synced to its time whenever you enter its physics range.

Only on-rails craft that are defined as targets have bubbles and only when in orbit, outside of planet-side visual range. On the ground, in the atmosphere and in very low orbit we would all play real-time.

[Vl3d]

4 hours ago, Lettuce said:

The only sacrifice a player would have to make on multiplayer is probably that quicksaves will only be valid in the play session they were created in so once you disconnect from a server all of your quick saves are deleted

Quicksaves in multiplayer? No, you just get one chance, prepare your abort sequences.

This discussion has made me hate time travel with flaming passion. :))

[DwightLee]

5 hours ago, Lettuce said:

A multiplayer game would probably be able to do away with holding onto data from before whoever is earliest on the timeline such as taking the time from the earliest quick save and deleting all position data from before that time. The only sacrifice a player would have to make on multiplayer is probably that quicksaves will only be valid in the play session they were created in so once you disconnect from a server all of your quick saves are deleted and the server can discard position data from before the earliest still existing quick save. Anything built by a disconnected player could be placed in a frozen state upon disconnect not consuming resources while the owner is offline but still moving in its stable orbit. When the owner reconnects their builds would start consuming resources again and their time is synced to the future most player's present. Might lead to some weird super far future dates on servers but nothing that would affect gameplay and would definitely save storage on servers. I don't know how this system would handle ships on trajectories between SOI's but I'm thinking you could calculate where it would be in the server's future most player until either the owner of the ship reconnects and syncs to that time and/or the ship is in its final orbit. This is me just spit balling solutions to optimizing storage of positions of craft so I'm sure there are flaws with my idea but it shouldn't be infeasible to implement it that way.

Yep there might be ways to help, if this was possible, it is by far the best solution I have heard of. ( to me )

No resyncing, shadow parts for future. There might have to be a rule that you cannot dock with someone elses craft if you are not in the same time, as you could change somethings past.

[Vl3d]

38 minutes ago, DwightLee said:

shadow parts for future

Just imagine living in a world where every building to ever exist would have overlapping ghosted projections. Could you land on the projections, walk through them? Could you see them from orbit? How could you decide from orbit where to land to build your colony? How would you distinguish between real and ghost from a distance? Which tech-level buildings would you see?

If the actions of a player from the past impact a player from the future, and also the actions of a player from the future impact a player from the past - why on earth don't you just play real-time!? Why the obsession with time travel?

Edited April 11, 2022 by Vl3d

[DwightLee]

41 minutes ago, Vl3d said:

Just imagine living in a world where every building to ever exist would have overlapping ghosted projections. Could you land on the projections, walk through them? Could you see them from orbit? How could you decide from orbit where to land to build your colony? How would you distinguish between real and ghost from a distance? Which tech-level buildings would you see?

If the actions of a player from the past impact a player from the future, and also the actions of a player from the future impact a player from the past - why on earth don't you just play real-time!? Why the obsession with time travel?

That is the problem, but I like that more than the problem of re-syncing and all the planets and stations shift in their orbits to an unexpected position. Dont worry though, this is all conjecture, none of us know how they plan to do it... yet

Edited April 11, 2022 by DwightLee

[DunaManiac]

2 hours ago, Vl3d said:

Only on-rails craft that are defined as targets have bubbles and only when in orbit, outside of planet-side visual range. On the ground, in the atmosphere and in very low orbit we would all play real-time.

But how do we prevent the visual shift? It would be even more pronounced than the planetary bubbles, as you could literally have a night-to-day transition.

[Vl3d]

35 minutes ago, DunaManiac said:

But how do we prevent the visual shift?

In my mind i see a few possibilities to hide temporal / target configuration positional jumps.

For space stations when I get to the close encounter point / for celestial bodies after I circularize my orbit around the destination / for direct suborbital trajectories...

When I want to enter multiplayer I get synced by either:

(a) in map view: getting spinned around in orbit (like a reverse warp-to-transfer window)

(b) in map view: zooming in close to my craft and then zooming out

(c) normal view: see an arrival-at-target cutscene

(d) normal view: after pressing warp-to-destination seeing my craft third person and before I arrive in visual of the target range the sun / moons get positioned correctly (warp effect). This one would be useful for warping to space stations.

(e) map or normal view: if I directly enter suborbital trajectory (atmosphere or landing) the server calculates if I arrive during the day or at night and syncs the ground below me to be correct for the real-time bubble. This way the transition is seemless for me but also for people on the ground (because I appeared from somewhere in orbit).

You could say: "ok but what about the moons positions, you just did a gravity assist before arriving, you see the moon in a position X, but after landing it's in position Y or not visible" .. well this is a tricky one. Except what if you sync  to multiplayer real-time after landing? You (and only you) see an animation of some day / night cycles and that's it.

Depends on preference, but the idea is that when you arrive the server sets the configuration you play in and politely hides it from you using the places where time is flexible: while in orbit, while on approach, while landed.

 

Edited April 11, 2022 by Vl3d

[Vl3d]

Also keep in mind what @t_v said earlier. Orbits / approaches / being landed are cyclic events and have flexible time. It doesn't really matter during which orbit you arrive, be it real-time or by warping. It doesn't matter if you stop and wait 100 years on approach. It doesn't matter how much time passes after landing and before getting out. Causality is preserved by positional relativity to the target, not by time. In the game time is an illusion. What are 100 years for you could be 1 second for another player because they cannot see your internal state and timers.

That's the scariest thing about AI, insects and reptiles, by the way. You can't grasp their internal clock, only their physical speed. But I digress...

Edited April 11, 2022 by Vl3d

[t_v]

4 minutes ago, Vl3d said:

Also keep in mind what @t_v said earlier. Orbits / approaches / being landed are cyclic events and have flexible time. It doesn't really matter during which orbit you arrive, be it real-time or by warping. It doesn't matter if you stop and wait 100 years on approach. It doesn't matter how much time passes after landing and before getting out. Causality is preserved by positional relativity to the target, not by time. In the game time is an illusion. What are 100 years for you could be 1 second for another player because they cannot see your internal state and timers.

While that is technically true, it mostly applies to two different players rather than one player. Sure the position of Jool won’t make the Mun’s orbit any different, but that just means that two players who have Jool at different positions can still treat the Kerbin-Mun system as being in the same time. But, each player should be able to count on their position of Jool when they decide to launch from the Mun to Jool, and if that position jumps for them, even though it didn’t impact their Mun mission, it impacts their Jool mission. 

[Guest]

2 hours ago, Vl3d said:

Why the obsession with time travel?

With this page is 10 pages you're arguing about your special flavour of timewarp, and you're doing it because you said you didn't want to argue about timewarp.

Only because you can't understand that "press space for skip the cutscene" or playing Stellaris at 4x is not time travel.

If you tried to build that space station at an inclined orbit before starting to intervene here this thread would be 10 pages shorter, 10 pages of the kind of discussion you said you hated.

[Lettuce]

3 hours ago, Vl3d said:

Quicksaves in multiplayer? No, you just get one chance, prepare your abort sequences.

This would pretty much destroy any fun that could be had in multiplayer, you would be shoehorning everyone into playing the way that you personally play the game. Some people don't want to over engineer a lander, sure that's fun for a lot of people on this forum even myself at times but its definitely not for everyone. Playing without reverting is terrible with the original KSP and I assume for the most part some of those issues are going to carry over into KSP 2 for example accidentally staging while in orbit which under your proposed system would be after almost 10 min of work wasted.  Having your rocket tip on the launchpad and being out those resources/funds used to build it, kerbals dying on the launchpad because your rocket tipped and you then have to wait for their respawn timer. Doing away with quick saves would make everyone overly cautious which IMO would harm the fun that is supposed to be had in KSP.

Edited April 11, 2022 by Lettuce
Extra word left in

[Vl3d]

17 minutes ago, Lettuce said:

accidentally staging while in orbit which under your proposed system would be after almost 10 min of work wasted.  Having your rocket tip on the launchpad and being out those resources/funds used to build it, kerbals dying on the launchpad because your rocket tipped

I guess that's why, during an interview, Nate said he hadn't heard people laugh so hard in his life before seeing KSP2 multiplayer. I know I would be all over the floor.

Anyway to fix your problem just launch again. It's competitive space-race DRM multiplayer, what do you expect?

25 minutes ago, t_v said:

But, each player should be able to count on their position of Jool when they decide to launch from the Mun to Jool, and if that position jumps for them, even though it didn’t impact their Mun mission, it impacts their Jool mission. 

They have the same Jool position if they both leave from the Mun. If they start journeys from different origins it doesn't matter how they get to Jool - they each solve their own maneuver nodes puzzle separately. They sync to the Jool real-time bubble when they arrive.

Edited April 11, 2022 by Vl3d

[Lettuce]

3 minutes ago, Vl3d said:

Anyway to fix your problem just launch again. It's competitive space-race DRM multiplayer, what do you expect?

I expect to be able to play the game with the same basic functionality as the original KSP singleplayer but with friends. The expectation of an MMO to come out of this game is by far more baffling than my pretty simple expectations.

[Vl3d]

26 minutes ago, Master39 said:

 

If you tried to build that space station at an inclined orbit before starting to intervene here this thread would be 10 pages shorter, 10 pages of the kind of discussion you said you hated.

Master, you get to orbit with the same inclination, set it as destination target and prepare the maneuver nodes, press Go, auto-exit multiplayer,  auto-warp to the correct encounter window for that inclination, burn and warp to the station, enter it's bubble, dock, done. It takes 10 minutes max.

Edited April 11, 2022 by Vl3d

[Guest]

Just now, Vl3d said:

Master, you get to orbit with the same inclination, set it as destination target and prepare the maneuver nodes, press Go, auto-exit multiplayer,  auto-warp to the correct encounter window for that inclination, burn and warp to the station, enter it's bubble, dock, done. It takes 10 minutes max.

If you don't launch at the right window you spend way more DV doing the rendezvous, not talking about something like 10 degrees of inclination, I talked about a ISS replica, 51 degrees of inclination.

Forced-autopilot aside (why the craziest proposals always end up forcing an autopilot upon the player?) I don't want my shuttle replica to have to include a torch drive only because otherwise I would have a window to launch every 2 and a half hours or so.

[Vl3d]

24 minutes ago, Master39 said:

Forced-autopilot aside

Fine, then set your journey maneuver nodes and target while you're on the launch pad. Auto-warp to the correct time window while on the ground - but outside of multiplayer. Launch for a direct encounter. You can cancel (revert to launch) to return to multiplayer.

The thing is.. real-time players can just see you launch in real-time, because they don't know where you're going. There is no sharing of your internal state. Causality is preserved even though let's say you launch at night and other players see you launching during the day.

There is no forced auto-pilot, you just don't get to control warp inside the multiplayer real-time bubble while moving. You can control it while stationary or in orbit to wait for a time window, only after you've committed to a journey and thus desynced from interactions.

Edited April 11, 2022 by Vl3d