Possible Solution to the Multiplayer Issue

[razark]

5 hours ago, TheKSPBeginner said:

Say player #1 time warps.

Their presence in the past can be saved.

Once player #2 does a rendezvous, they can "sync" up to each other.

So Player 1 timewarps to the future.

In Player 1's past, Player 2 docks with Player 1's ship.

How does that affect whatever Player 1 has done in the time between the docking and the current time in Player 1's timeline?  Their vessel has become more massive than it was before, so how do you account for any maneuvers they have done?

 

Or Player 2 rams into Player1's ship.  Say it knocks off the solar panels.  How does that affect Player 1?

 

What if Player 3 docks with Player 1's ship before Player 2 tries to dock at the same docking port?  The way you describe it, Player 2 can dock before Player 3, even though Player 3 is already docked, but the game hasn't resolved all the timelines yet.

 

It leads to paradox.

[Warzouz]

On 04/05/2017 at 2:08 AM, Veeltch said:

Exactly this is something I don't think many people requesting MP realise. A realistic(ish) space game will leave you wanting if all you care about is interaction between you and others. Unless there are FTL/jump gates, a clearly set goal like "let's build Copernicus and fly it somewhere!" or purely atmospheric flight and dogfights, there will be just points in map view changing their trajectories from time to time.

I agree with you. If KSP is not designed to be a multiplayer game, like Minecraft (where any one can go any where doing its own business).

Having a multiplayer game where player one goes to Eeloo, and Player 2 Dres will be a hassle, not for the time warps, but when ships arrive on destination. When player 2 will start exploring, player 1 will be in flight.

BUT, maybe there can be another type of multiplayer : building joint missions to the same place ! (building a 12 part space station to Jool). As for dogfights, there are much better game to do that...

In the end, I still believe that KSP is 99% a solo game. All game don't have to be multiplayer. The KSP multiplayer would be cool, but that's not a decisive feature. There are other more important (better graphics, better sound design, more sol-like planets...)

[pandaman]

I know I, and several others, have said this before, but the only viabie STOCk solution to multiplayer that i can see is that all players always stay on the same time.  Any time warp/acceleration is applied to all players.  This would mean (shock horror) players actually cooperating and communicating with each other- true multiplayer, not several players each playing solo in the same game and crossing paths occasionally.

KSP is just not suited to the MMO format.  Think more (in FPS terms) of 'co-op' missions.  The actual nimber of players at any one time wouldn't be huge, but sufficient for a group of friends to do joint missions or engage in combat should they wish.

If mods want to deal with time warp differently then thats great.  But for 'stock' it has to be stable and robust.

[mattinoz]

15 hours ago, pandaman said:

I know I, and several others, have said this before, but the only viabie STOCk solution to multiplayer that i can see is that all players always stay on the same time.  Any time warp/acceleration is applied to all players.  This would mean (shock horror) players actually cooperating and communicating with each other- true multiplayer, not several players each playing solo in the same game and crossing paths occasionally.

KSP is just not suited to the MMO format.  Think more (in FPS terms) of 'co-op' missions.  The actual nimber of players at any one time wouldn't be huge, but sufficient for a group of friends to do joint missions or engage in combat should they wish.

If mods want to deal with time warp differently then thats great.  But for 'stock' it has to be stable and robust.

There is also going to be several other groups including one which will point out that multi-player universe like KSP could easily be full of recoverable paradoxes that just sort themselves out using the vast scale of time and space involved. This could even be stretched by other means that puts the onus on the player who creates the paradox to takes steps to resolve it (or get flipped back in time to before the paradox).

Also this creates multi-player value in that one simple way to resolve would be to get other players to help out. Not dissimilar to mission builder the parameters to resolve could be a bundled together and issued as a contract offered up by the server. Once you have a means to address the pardox then you can set limits on how much one player can warp away from the time line. 

[Mignear]

Why not just make the desynching part of the multiplayer?
When one player timewarps, the craft he is controlling "disappears" from other people's view, and when he ends the timewarp, he reappears at wherever he is(on his side) on everyone else's view.

Desynch for that specific timewarping craft, then resynch once timewarp is done.

[SnailsAttack]

I don't think there's really any possible way to make time warping work. Every option is going to result in one player waiting for another or spacecraft teleporting all over the damn place. KSP is a fantastic single-player only game.

[PhysicsBoy]

Or, the time won't change unless both have warped to same time, so you first change to x10000 and it won't come into effect unless the other person does it too. Or maybe something like, votes by which both (or more players) can vote to choose time warp (quite the same) and the server does it. Is it not possible to do so?

Edited February 12, 2018 by PhysicsBoy

[SnailsAttack]

4 hours ago, PhysicsBoy said:

Or, the time won't change unless both have warped to same time, so you first change to x10000 and it won't come into effect unless the other person does it too. Or maybe something like, votes by which both (or more players) can vote to choose time warp (quite the same) and the server does it. Is it not possible to do so?

...no, it isn't. I jump in and out of time warp pretty much every 5 seconds whether it's from getting from one place to another or the right spot to start a maneuver burn or even just speeding up the burn with the physics warp.

[sevenperforce]

I think there's a solution.

There are three different use cases for non-physics timewarp; three reasons it is done. 

• The first reason to warp is something we'll call position warp. Position warp is used when you simply want to change where you are in your current orbit, irrespective of any other objects. For example, your shuttle is in LKO and you want to deorbit at the right location so you can make a gliding approach to the KSC runway, so you warp around to some specific point relative to KSC. Or perhaps you're in low Duna orbit and you want to warp around to the preferred injection burn point for a Hohmann transfer to Ike. Position warp is also used on ascent; if I only need 20 m/s to circularize but I'm still 6 minutes away from my apoapse at 100 km, I'm going to warp around to my apoapse, then fire my engines. Finally, position warp can be used if you are trying to rendezvous with another vehicle but need 4 or 5 orbits to pass before you reach closest approach; you can warp around to rendezvous. Position warp can be measured in radians, because you're just changing your position along a fixed orbit.
• The second reason is what we will call true warp. You've just completed the first leg of your Hohmann transfer to a distant destination, and you don't want to wait hours or days or years to get there, so you warp. The trouble is, it's not the same as position warp, because you're aiming for a destination, and you rather need that destination to be there when you arrive. This is the more challenging use case.
• The final reason is what we will call dynamics warp. You're waiting for an ideal transfer window, so you jump over to the Tracking Center and wait until the planets align. If you're lazy, like me, you probably already flew your vehicle's ascent, so your poor Kerbal spends three years whipping around Kerbin in LKO while you wait for the perfect moment. In dynamics warp, it doesn't matter where vehicles are located; you're only concerned with where the planets (or moons) are located.

To deal properly with warping, you need to handle the use cases differently. 

Position warp can be dealt with easily, as discussed upthread. Right now, if I want to move to a specific point in my orbit around a single body, I simply click where I want to go, select "Warp Here", and it happens. In multiplayer, the same thing would take place, but instead of warping there, I jump there as if I had used HyperEdit or the debug menu. Nothing else shifts. There is a slight potential for abuse, in that you can jump directly to closest approach with another vehicle instead of waiting for an intercept, making launch windows less important, but that is not an unreasonable tradeoff for multiplayer. There is no free energy; your orbit remains the same before and after the jump, you're just in a different place along that orbit.

True warp and dynamics warp are the problem. If you're warping toward a specific destination, moving your vehicle faster along your orbit (as with position warp) doesn't help, because then you'll miss your destination when it arrives. So the solution here is a little more complex.

In order to deal with true warp and dynamics warp, each player's warp experience has to be segregated. What is shared across multiplayer is not the entire solar system, but each individual SOI. Suppose Bill wants to go to Duna, but Alice is already on Duna. No problem; Bill does the usual ascent, warp-to-window, trans-Dunian injection, and warp to SOI entry, with all the planet and moon positions stored locally. Once Bill enters Duna's SOI, he suddenly "pops up" on Alice's map view. They share only the SOI, not the whole solar system.

This solution does mean that Bill and Alice will see Ike at different locations in its orbit, but that's fine. There may be a moment of confusion if they both do simultaneous trans-Ike injection burns from different points in low Duna orbit, but once they both arrive in Ike's SOI, they share it anyway.

I think it can be done.

[razark]

1 hour ago, SnailsAttack said:

...no, it isn't. I jump in and out of time warp pretty much every 5 seconds whether it's from getting from one place to another or the right spot to start a maneuver burn or even just speeding up the burn with the physics warp.

That doesn't mean it isn't possible.  Just that it's going to annoy at least one of the players.

 

KSP multiplayer just doesn't make much sense unless everyone is doing pretty much the same thing at the same time.

[Spricigo]

7 hours ago, sevenperforce said:

There are three different use cases for non-physics timewarp; three reasons it is done. 

I see no difference. You don't want to wait for an event, so you warp.

[sevenperforce]

47 minutes ago, Spricigo said:

I see no difference. You don't want to wait for an event, so you warp.

Simplistically, yes. But that's a little like thinking that a telephone only needs one transducer because hey, all it does is transmit sound, right?

Use case evaluation is critical whenever you are trying to combine different standards, which is essentially what you're doing when you're trying to integrate warp from multiple players.

In this instance, the different use cases mean that you cannot integrate warp in just one way. If you're waiting to reach a certain point in an orbit, irrespective of the positions of other objects, then you can do so by changing the radial position of your vehicle, irrespective of anyone else's vehicles. If you are waiting for a launch window or an intercept, you need to handle warp in a different way. That is all.

[Spricigo]

10 hours ago, sevenperforce said:

Simplistically, yes. But that's a little like thinking that a telephone only needs one transducer because hey, all it does is transmit sound, right?

Wrong analogy. I don't see any problem with the parts or function of the phone. What I don't get is why you think is fine to call KSC or Mun but not fine to call Duna.

 

 

 

Also, seems like you are missing an important scenario. What if another player is planning a rendezvous and you  position warp?

 

[sevenperforce]

6 hours ago, Spricigo said:

Also, seems like you are missing an important scenario. What if another player is planning a rendezvous and you  position warp?

If another player is trying to rendezvous to you and you warp, then yes, that breaks their flow. But then all they have to do is warp to match you. Obviously, if you don't want them to catch up to you then that's another issue altogether.

Position warps would be essentially instantaneous, so the chance of such "warp collision" is very low. Let's say that you're in control of a space station and someone is sending a crew capsule up. They set up their ascent, wait until you're virtually overhead, then say "Hey, I'm sending up some crew; make sure you don't move your ship."

You could also establish a corollary to the "target" function, where if you target a vessel not currently targeted by or controlled by another player, then position warp, both vehicles warp together. If you attempt to target another vehicle for rendezvous while another player is actively controlling it, it would give you a "Warning: Target Vehicle Controlled By Player 2." You'd want this anyway, after all, because people can change the trajectory of their ships the old-fashioned way, with dV.

[EnderKid2]

I like the true cooperation idea, where there is one timeline, and everyone has to agree to warp.

[Not Sure]

I swear.. people, please don’t talk about time warp until you have used DMP. Time warping isn’t an issue.

[razark]

31 minutes ago, Not Sure said:

I swear.. people, please don’t talk about time warp until you have used DMP.

I don't have to use something to know I disagree with it.

 

32 minutes ago, Not Sure said:

Time warping isn’t an issue.

From what I've heard, it is an issue.  The way one person solves it is not going to agree with the way another person desires to see it.

There's a lot of ways to implement it, and every method has people that agree and disagree with it.

[Spricigo]

23 hours ago, sevenperforce said:

If another player is trying to rendezvous to you and you warp, then yes, that breaks their flow. But then all they have to do is warp to match you. Obviously, if you don't want them to catch up to you then that's another issue altogether.

IOW in that situation is up to the players to cooperate or not. In that case why not simple "everyone need to agree to warp" ?  Solves the issue  (if there is player cooperation) and don't introduce exploitable game mechanics.

23 hours ago, sevenperforce said:

Position warps would be essentially instantaneous, so the chance of such "warp collision" is very low. Let's say that you're in control of a space station and someone is sending a crew capsule up. They set up their ascent, wait until you're virtually overhead, then say "Hey, I'm sending up some crew; make sure you don't move your ship."

The issue is exactly the possibility the player have to "not move", or instantly move to place that he would not reach at that time. Instead of sending a capsule  at the right moment, just send it at any time and teleport to the encounter. If I'm about to lose a launch window just teleport ahead in my orbit. If I'm about to lose a contract deadline just teleport ahead. If I have a satellite out of phase with the constellation just teleport it.

You may say that the player is not supposed to use teleport in this case but the game has no way to know why are you using it. You are only saying "I'm this orbit, which pass to that position. Move my vessel to that position."

 

Still, the main point is: why   teleport for landing should be fair game while teleport to Duna is out of limits?  Why Duna position is important but KSC position can be disregarded?

 

Notice, the idea itself may be as good as any other solution. What I'm questioning is your apparent assumption that it will not have it's own issues and, in particular, your idea that some events can be disregarded while other need to be taken in  consideration.

 

1 hour ago, Not Sure said:

I swear.. people, please don’t talk about time warp until you have used DMP. Time warping isn’t an issue.

1st: How DMP handles time warp was already described and issues with this method already pointed. If you think  there was a mistake or misperception about it feel free to point out and why you think using DMP will change peoples view. This is supposed to be a discussion (where we share our opinion to try to reach some conclusion) not an argument (where we claim to be right and everyone that disagree with us we tell to shut up).

2nd: Assuming that DMP methods are the ideal immediately brings the "no need to do in stock, there is a mod for it" argument. It may not be enough to shoot down the idea, but something that need to be addressed nonetheless .

3rd: DMP remains as just one possible implementation for multiplayer. The fact it fail to appeal even for people otherwise interested interested in multiplayer is enough indicative that may be not the ideal solution for a broader part of the player-base.  it should be considered as a option as valid as any other, including the no multiplayer option.*

TL/DR: Go ahead and tell your opinion, just remember that is up to you to back up your claims with arguments/evidences.

 

*A different take on this is that the "no multiplayer" option is the baseline to compare how good/bad the different implementation are. The same way a new medicine is tested if it is better than placebo.

[Not Sure]

I would just like more people to acknowledge the way DMP handles warping. It doesn't seem like most people know that it's a possibility. 

Imo, waiting to warp? Some rando could go afk and now all your work is waiting on them to agree to warp, which they really don't have to. Trolling is easier than ever.

Edited February 14, 2018 by Not Sure

[razark]

27 minutes ago, Not Sure said:

I would just like more people to acknowledge the way DMP handles warping.

It does so in a way that not only invites paradox, but gives it a comfy chair and brews it a cup of tea.

I'd rather have timewarp that did not allow paradox.

 

29 minutes ago, Not Sure said:

Imo, waiting to warp? Some rando could go afk and now all your work is waiting on them to agree to warp, which they really don't have to. Trolling is easier than ever.

I would suggest not playing with such people, then.  If such a player is on the server, then the admin should kick the person from the session.  Problem solved.

[Not Sure]

3 minutes ago, razark said:

 

I would suggest not playing with such people, then.  If such a player is on the server, then the admin should kick the person from the session.  Problem solved.

What about F5 and F9? All I see when I think of the cooperation layout is the exact opposite. Over the internet, is anybody really cooperative? (Ironic isn't it)

[razark]

1 minute ago, Not Sure said:

What about F5 and F9?

What about them? 

Is that quicksave/quickload?  If so, of course they would be disabled for the purposes of multiplayer.

 

2 minutes ago, Not Sure said:

All I see when I think of the cooperation layout is the exact opposite.

Not parsing what you're saying here.

 

3 minutes ago, Not Sure said:

Over the internet, is anybody really cooperative?

Yes.  I've played games that used a shared timewarp system before.

[Not Sure]

Just now, razark said:

Yes.  I've played games that used a shared timewarp system before.

But consider the freedom of time frames. Also, a 2k part craft will slow down the time speed of your computer in order to not have as atrocious FPS. In the co-op system you would either be directed with worse FPS I'm general or slowing down every body else's already slow game.

I guess it's a matter of opinion, but a small paradox here and there isn't an issue for me. 

[Spricigo]

31 minutes ago, Not Sure said:

I would just like more people to acknowledge the way DMP handles warping. It doesn't seem like most people know that it's a possibility. 

Acknowledged. In fact I'm yet to see a discussion about multiplayer where DMP way was not mentioned.

Agreeing that it is the best (or even a good) solution is an entire other story. Just after DMP is mentioned people start to point issues with paradoxes.

 

I'm with razark in this one:

3 hours ago, razark said:

There's a lot of ways to implement it, and every method has people that agree and disagree with it.

 

 

4 minutes ago, Not Sure said:

What about F5 and F9? All I see when I think of the cooperation layout is the exact opposite. Over the internet, is anybody really cooperative? (Ironic isn't it)

Moot point. If the players don't want to cooperate the game cannot enforce it. Simple as that.

In any case, my more elaborated answer:

I played Eve Online for 5 years (then RL happened, not enough time for  it any more. But I digress..). Mind you, what in other games is called "griefer" in EVE is called "player". Ruining someone day was not worth a note,  we only start to congratulate when you ruin a bunch of people's months.   Yet, among those Tear-fueled Psychos, cooperation was the norm, no one archive something important without help.

KSP multiplayer will promote cooperative player if the devs decide to design in a way to encourage it, which i think would be the idea . The player will explore the toys that are given, people interested in different toys will not have it and lose interest.

Let me be blunt about it:  If you can't figure a way to be cooperative in KSP multiplayer, you don't deserve KSP multiplayer. If you are worried about trolls, stay safe in singleplayer.

 

 

[Not Sure]

1 hour ago, Spricigo said:

Let me be blunt about it:  If you can't figure a way to be cooperative in KSP multiplayer, you don't deserve KSP multiplayer. If you are worried about trolls, stay safe in singleplayer.

Well said. 

In a game sense, waiting for a consensus on a feature of the game that is supposed to save time sounds like an oxymoron. I find myself constantly warping here and there because floating through space isn't that interesting by itself. 

Just about every approach to this has some major downside. Perhaps the reason squad isn't very exited about implementing it is because of how the community would react. "Bah, it could have been done better.."