Possible Solution to the Multiplayer Issue

[sevenperforce]

4 hours ago, Spricigo said:

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."

Yes, you can abuse the warp function.

But that's no different from single-player gameplay. If I launch a capsule to rendezvous with a space station and end up being out of phase, I can just jump over to the tracking center and warp for six months until my capsule is perfectly lined up with the space station, no dV required. If I lose a launch window, I can just warp 3 or 7 or 15 years until the next perfect one comes along. Granted, the "position warp" function would make such abuse slightly easier, but it's the same sort of thing. 

And if you have a satellite constellation that is perfectly in-phase, more power to you. There's a reason geosats need station-keeping propellant.

Quote

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?

The difference is delta-V, which is the most fundamental thing in the game. Picking your deorbit point is not a question of dV, but of timing. Picking a transfer and rendezvous with Duna has everything to do with dV. You want a warp solution which allows free warp in cases of timing, but preserves the experience of calculating an optimal transfer window.

Quote

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.

Warp within a single SOI can ignore the positions of other objects. Warp that crosses SOIs cannot. That is simple.

[Spricigo]

 

4 hours ago, sevenperforce said:

Yes, you can abuse the warp function.

So it need to be addressed.  Even if just to conclude it's not a problem. (Personally, I think it is something the devs should be concerned. But that is besides the point)

4 hours ago, sevenperforce said:

But that's no different from single-player gameplay.

There's a big and evident difference.  In the single-player game when I warp time pass. For everything,  including my craft, position will be a continuous function of time. Your idea breaks that continuity.u

4 hours ago, sevenperforce said:

The difference is delta-V, which is the most fundamental thing in the game.

Jedi mind trick? You can't just handwave and say "Is all about deltaV".

Not,  by any means,  fundamental enough to disregard the other elements of rocket science. Just a tile in the foundation of KSP. 

4 hours ago, sevenperforce said:

Picking your deorbit point is not a question of dV, but of timing. Picking a transfer and rendezvous with Duna has everything to do with dV.

Picking a transfer window is nothing more, nothing less than picking a time. If a particular time results in lower deltaV requiriment, that's just a fortuitous consequence. Exactly in the same way that being able to land in the runaway is a fortuitous consequence of picking a favourable time for deorbit. (Notice that I said time, because position is a function of time )

You can make a transfer in a different moments and use more deltaV. Or you can deorbit in a different moment and land in the badlands.

4 hours ago, sevenperforce said:

You want a warp solution which allows free warp in cases of timing, but preserves the experience of calculating an optimal transfer window.

I can imagine:

 1.Calculating the optimal transfer windows

2.Finding is several months away.

3.Logging out. (Since warping to the transfer window results in a lower deltaV requirements, thus not allowed )

Engaging,  just NOT!

4 hours ago, sevenperforce said:

Warp within a single SOI can ignore the positions of other objects. Warp that crosses SOIs cannot. That is simple.

That makes no sense. You can't claim to ignore the other objects (e.g. KSC ) position when your objective is to interact (e.g. land at) with such objects.  

Ignoring the other objects woul be doing the deorbit burn regardless of the position of KSC instead of when KSC is exactly on your path.

[sevenperforce]

10 hours ago, Spricigo said:

14 hours ago, sevenperforce said:

Yes, you can abuse the warp function.

But that's no different from single-player gameplay.

So it need to be addressed.  Even if just to conclude it's not a problem. (Personally, I think it is something the devs should be concerned. But that is besides the point)

There's a big and evident difference.  In the single-player game when I warp time pass. For everything,  including my craft, position will be a continuous function of time. Your idea breaks that continuity.

The passing of time is of no consequence in singleplayer warp, because if you miss a transfer, you can literally just warp longer until it comes around again. In singleplayer, if you want to warp to when the KSC will be exactly opposite your deorbit burn, you select a point that trails KSC by about 0.8pi radians. In the "position warp" for multiplayer, you select a point that trails KSC by 1.0pi radians. What's the difference? "Well, in singleplayer I would have caught up with my deorbit point 0.2pi radians later!" It makes literally no difference in gameplay.

Same with a rendezvous to another ship. In singleplayer, if you are in roughly the same orbit as your target, you can jump over to the tracking center and warp for a day or a week or a year until your phases cancel and you're close together. "Position warp" makes this slightly easier, but there's no meaningful difference in gameplay.

10 hours ago, Spricigo said:

Picking a transfer window is nothing more, nothing less than picking a time. If a particular time results in lower deltaV requiriment, that's just a fortuitous consequence. Exactly in the same way that being able to land in the runaway is a fortuitous consequence of picking a favourable time for deorbit. (Notice that I said time, because position is a function of time )

You can make a transfer in a different moments and use more deltaV. Or you can deorbit in a different moment and land in the badlands.

"Just a fortuitous consequence"? I don't know about you, but every single time I've done an interplanetary mission, I've based it on what will have the lowest dV, within a certain range. 

Choosing a specific time to deorbit does not change the dV required for the maneuver. Choosing a transfer burn time does. Position warping within a single SOI has little effect on gameplay and can be handled "simply", but position warping across SOIs involves multibody dynamics and cannot be handled by simply teleporting to a different point in the orbit.

10 hours ago, Spricigo said:

I can imagine:

 1.Calculating the optimal transfer windows

2.Finding is several months away.

3.Logging out. (Since warping to the transfer window results in a lower deltaV requirements, thus not allowed )

You've got it upside-down.

It's not about trying to force certain dV requirements. Nothing remotely like that. It's about preserving the ability to perform transfers, period.

"Position warp" can let you do things within a single SOI in a very simple and straightforward way, but if your plan is to leave your SOI, "position warp" does you no good whatsoever. I can "position warp" around Kerbin 10,000 times, but it won't get me any closer to my Duna transfer window. Once I've done my burn to Duna, I could "position warp" forward along that Hohmann, but then I would beat Duna to the rendezvous, which wrecks my transfer completely. For warp in multiplayer to work, you need to still be able to plan a transfer, execute the transfer, and complete the transfer as in singleplayer, without the transfer taking six months of play time.

This has nothing to do with some artificial enforcement of dV requirements. It's about replicating the singleplayer experience, as far as is possible, in a multiplayer setting.

"Position warp" can be used to replicate the warping within SOIs, but you need a different solution when you are transferring between SOIs. The different solution is that timewarp undertaken by a singleplayer warps objects that are on rails, for them only, without changing anything within the SOIs. Each SOI becomes, in essence, a warp-protected bubble. 

10 hours ago, Spricigo said:

15 hours ago, sevenperforce said:

Warp within a single SOI can ignore the positions of other objects. Warp that crosses SOIs cannot. That is simple.

That makes no sense. You can't claim to ignore the other objects (e.g. KSC ) position when your objective is to interact (e.g. land at) with such objects.  

Ignoring the other objects woul be doing the deorbit burn regardless of the position of KSC instead of when KSC is exactly on your path.

If you are trying to warp only within an SOI, you can do so without worry about the relative positions of other SOIs. Warping to apoapse on ascent or warping to a rendezvous or warping to a deorbit point can be done instantly, without needing to keep track of the positions of the Mun or Minmus or Duna or Eeloo. But if you are warping across SOIs, you need a different solution.

You seem hung up on the idea that there's some inherent problem with treating different warp situations differently. There isn't, but let's set that aside for the time being. What, exactly, is the problem with the timewarp solution of having each player's solar system progress on its own timeline and merely insulating each on-rails SOI from that timewarp?

[Spricigo]

1 hour ago, sevenperforce said:

The passing of time is of no consequence in singleplayer warp,

Of course there is consequences: ore get mined, data get processed, contract deadlines approaches, transfer windows come and go, the position of your craft changes.

Time need to pass for events to happens. Time warp exist because some events requires quite a long time to happen. The result is that the player don't need to wait for such events, but no event happens at a different time . If you take away the possibility to accelerate time the player is forced to wait for weeks, mouth or years.

Bluntly put: if the player is forced to not play, he will not even bother to log in the game. A feature that cause that effect is a failure.

 

2 hours ago, sevenperforce said:

Same with a rendezvous to another ship. In singleplayer, if...

if

The conclusions for this argument are only applicable for that limited conditions.

In any case the difference remains, it takes time to happens. In the same time other events will happen. If the  crafts will meet instantaneous and nothing else changes that is a paradox. Even worse if the rendezvous would not happen under normal time flow (e.g. because the object you want to intercept is in a scape trajectory)

2 hours ago, sevenperforce said:

"Just a fortuitous consequence"?

yes,, that is what I said. A fortuitous consequence, like 100% recovery ratting is a fortuitous consequence of landing in the runaway.

2 hours ago, sevenperforce said:

I don't know about you, but every single time I've done an interplanetary mission, I've based it on what will have the lowest dV, within a certain range. 

i suppose that is the idea. To pick the time that is better for you instead of waiting for years until it happen.

3 hours ago, sevenperforce said:

Choosing a specific time to deorbit does not change the dV required for the maneuver.

But does change where you will land.

3 hours ago, sevenperforce said:

Choosing a transfer burn time does

Not, it don't change. Make the same maneuver with at the same position and the orbit will be the same. The difference is if you will land in the intended SoI or not.

3 hours ago, sevenperforce said:

Position warping within a single SOI has little effect on gameplay and can be handled "simply", but position warping across SOIs involves multibody dynamics and cannot be handled by simply teleporting to a different point in the orbit.

In that case is not a solution for the issue at hand. We need something that handles multiple bodies dynamics.

 

3 hours ago, sevenperforce said:

You've got it upside-down.

It's not about trying to force certain dV requirements. Nothing remotely like that. It's about preserving the ability to perform transfers, period.

Oh yes...is preserved...I just need to log back in a few mouths to do it.

3 hours ago, sevenperforce said:

if your plan is to leave your SOI, "position warp" does you no good whatsoever. I can "position warp" around Kerbin 10,000 times, but it won't get me any closer to my Duna transfer window.

 Ok, that is My plan. I have my ship in LKO ready to depart to Duna, my issue is that The transfer window is three months away( notice that is a timing problem). What I need to do? As you say, teleport don't help me at all. 

Why bother in implementing a game-breaking mechanics, that don't helps when needed? We already have other alternatives, while those have their own issue at least they work for all situations.

3 hours ago, sevenperforce said:

For warp in multiplayer to work, you need to still be able to plan a transfer, execute the transfer, and complete the transfer as in singleplayer, without the transfer taking six months of play time.

Moot point. Waiting for the transfer window already takes months. Without time acceleration KSP become essentially doing nothing.

3 hours ago, sevenperforce said:

"Position warp" can be used to replicate the warping within SOIs, but you need a different solution when you are transferring between SOIs.

No we don't need a different solution for this. We just teleport to the edge of the SoI, wait a moment for the transition to occur and teleport again to the next SoI edge or destination. What we need is a solution for the changes that are not happening because is not within our current SoI.

4 hours ago, sevenperforce said:

You seem hung up on the idea that there's some inherent problem with treating different warp situations differently.

I said it in my first answer to your idea: Those are not different warp situation.  In all the cases something will happen in the future and the player want to go to the time when it will happen.

4 hours ago, sevenperforce said:

What, exactly, is the problem with the timewarp solution of having each player's solar system progress on its own timeline and merely insulating each on-rails SOI from that timewarp?

1st. Your idea, as you described, is not timewarp, is teleport. Under normal single player game is not possible to teleport.

2nd. Paradoxes. The idea make event that would happen simultaneous under the normal flow off time happen at different moment (and vice-versa).

3rd. The idea simple don't work in several situation. (In any case I want something happening outside my current SoI)

4th Is up to you to back up the proposal with convincing arguments that it is actually a good idea.  So far you only tried to dismiss my arguments without addressing anything. From what you explained both sync to interact and agree to warp are IMHO more effective and less troublesome.

 

 

 

 

 

[sevenperforce]

5 minutes ago, Spricigo said:

4 hours ago, sevenperforce said:

You've got it upside-down.

It's not about trying to force certain dV requirements. Nothing remotely like that. It's about preserving the ability to perform transfers, period.

Oh yes...is preserved...I just need to log back in a few mouths to do it.

 Ok, that is My plan. I have my ship in LKO ready to depart to Duna, my issue is that The transfer window is three months away( notice that is a timing problem). What I need to do? As you say, teleport don't help me at all. 

Again, you've got it upside-down. Please take a second to actually understand the proposal.

Your ship is in LKO, ready to depart to Duna, but the transfer window is three months away. In singleplayer, what do you do? You warp for three months, your ship completes half a zillion turns around Kerbin, the Mun and Minmus whip around Kerbin a corresponding number of times, the windows line up, and finally you reach your desired transfer window. You do your TDI burn, and then what happens? You warp ahead, as you leave Kerbin's SOI, enter Kerbolcentric orbit, and finally collide with Duna's SOI.

What's the difference in multiplayer? In my proposal, you do the exact same thing, except that time does not accelerate within individual SOIs. When you timewarp in multiplayer, bodies on rails (the Mun, Minmus, Duna, and so forth) all accelerate their positions, but manmade objects inside those SOIs do not accelerate. Your timeline is now different from everyone else's, and you see objects on rails in a different place than other players see them, but the timeline within each individual SOI is preserved.

That's how the paradox is avoided.

Each player is still playing, in essence, a single-player game. However, individual SOIs are shared. As long as your craft's trajectory does not cross SOIs, it can be interacted with normally. As soon as you're on an escape trajectory (or intercept trajectory), it is no longer available for targeting or docking or other interaction.

In the above example, another player wouldn't see anything special happening while you were warping to the transfer window. Of course, YOU see the positions of the moons and planets changing, in your own game, but they do not. They see your craft continuing along its usual trajectory normally. But then, once you start your TDI burn, they see your apoapse growing and growing (though, from their perspective, it may not actually appear to be heading in the correct direction), until suddenly you reach escape trajectory and your craft's trajectory suddenly goes grey. When you warp out of Kerbin's SOI, that trajectory disappears altogether.

If that other player happens to have a base on Duna, and they happen to pop over to Duna, what will they see? Nothing, at first. And then, as you warp forward, they suddenly see a grey trajectory pop up in their Duna map view. A few moments later, you start your injection burn, and suddenly your craft appears.

5 minutes ago, Spricigo said:

Waiting for the transfer window already takes months. Without time acceleration KSP become essentially doing nothing.

Which is exactly what needs to be solved.

5 minutes ago, Spricigo said:

3rd. The idea simple don't work in several situation. (In any case I want something happening outside my current SoI)

You think that, because you missed the fact that "position warp" is the exception.

[Spricigo]

14 hours ago, sevenperforce said:

Your ship is in LKO, ready to depart to Duna,...

What's the difference in multiplayer? In my proposal, you do the exact same thing, except that time does not accelerate within individual SOIs

If there is an exception than is not exact the same thing. Specially when that exception is what is being questioned.

 

14 hours ago, sevenperforce said:

When you timewarp in multiplayer, bodies on rails (the Mun, Minmus, Duna, and so forth) all accelerate their positions, but manmade objects inside those SOIs do not accelerate.

How about Ike? And my bud's craft at same orbital heigh around duna? Will the accelerated ike smash my bud's craft or will my craft miss the planned encounter with Ike upon arrival?

 

14 hours ago, sevenperforce said:

In my proposal, you do the exact same thing, except that time does not accelerate within individual SOIs. When you timewarp in multiplayer, bodies on rails (the Mun, Minmus, Duna, and so forth) all accelerate their positions, but manmade objects inside those SOIs do not accelerate.

That is the issue. It breaks the simultaneity between movement of celestial bodies and movement of craft. That is not good. 

 

 

14 hours ago, sevenperforce said:

You think that, because you missed the fact that "position warp" is the exception.

In that case, seems you forgot to present the general rule.

[sevenperforce]

1 hour ago, Spricigo said:

16 hours ago, sevenperforce said:

In my proposal, you do the exact same thing, except that time does not accelerate within individual SOIs. When you timewarp in multiplayer, bodies on rails (the Mun, Minmus, Duna, and so forth) all accelerate their positions, but manmade objects inside those SOIs do not accelerate.

How about Ike? And my bud's craft at same orbital heigh around duna? Will the accelerated ike smash my bud's craft or will my craft miss the planned encounter with Ike upon arrival?

In the specific instance you cite, you would see an overlap between Ike's position and your friend's DSO craft. Might be slightly jarring, I admit, but if you're headed to a rendezvous with Ike, then your trajectory will drop out of phase with the shared Duna SOI the moment it intersects Ike's SOI, so it won't matter.

If you're planning a rendezvous with your friend's DSO craft, then you'd position-warp around to a good ejection point rather than timewarping, so Ike wouldn't move in the first place.

1 hour ago, Spricigo said:

That is the issue. It breaks the simultaneity between movement of celestial bodies and movement of craft. That is not good. 

"Good" is relative. It's not simple and straightforward, no. But that doesn't make it "not good".

The goal is to preserve standard gameplay, including mechanics like timewarp, while allowing multiple players to interact with each other, without producing paradoxes. So, yes, simultaneity between craft locations and celestial bodies will be broken. But that's not "not good"; it just needs a handling rule.

Insulating individual SOIs and spacecraft from timewarp, while allowing position warp for individual spacecraft, is a universal handling rule which solves that problem.

2 hours ago, Spricigo said:

17 hours ago, sevenperforce said:

You missed the fact that "position warp" is the exception.

In that case, seems you forgot to present the general rule.

Allow me to refer you back to my very first post:

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.

[Spricigo]

2 hours ago, sevenperforce said:

The goal is to preserve standard gameplay, including mechanics like timewarp, while allowing multiple players to interact with each other, without producing paradoxes. So, yes, simultaneity between craft locations and celestial bodies will be broken.

That don't avoid paradoxes. Breaking the simultaneity produces paradoxes.

2 hours ago, sevenperforce said:

Allow me to refer you back to my very first post:

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.

Ok, so how about we start by getting that well explained before we move to the exception?

Bill is in kerbin SoI and want to go to Duna, while Alice is in Duna SoI and want to go to Kerbin. So for each one one does the usual procedures, and they leave each planet SoI at the same moment (gamer time). Problem is: their window don't happen at the same time, Alices want year 1, day 155, Bill wants year 1, day 255, They cannot share the Sun's timeline because they want to enter the Sun's SoI at different times.

Nothing is so bad that can't be made worse... Charlie is in solar orbit the whole time, for he is year 1 day 55. Screw whatever plan Alice or Bill have, warp-to-window as much as you want and as soon as you enter Sun's Soi the planets will be out of alignment, since that is what is happening in that SoI timeline. Btw, Charlie is stubbornly refusing to warp time so the planets can reach the favourable alignment Alice and Bill want.

Edited February 16, 2018 by Spricigo

[sevenperforce]

38 minutes ago, Spricigo said:

Bill is in kerbin SoI and want to go to Duna, while Alice is in Duna SoI and want to go to Kerbin. So for each one one does the usual procedures, and they leave each planet SoI at the same moment (gamer time). Problem is: their window don't happen at the same time, Alices want year 1, day 155, Bill wants year 1, day 255, They cannot share the Sun's timeline because they want to enter the Sun's SoI at different times.

Doesn't matter.

As I've explained, the positions of other SOIs are not shared. The only things shared within SOIs is the rotation of the object and the positions of manmade vehicles within that SOI.

Bill and Alice both exit their respective SOIs at the same time, gamer time, and appear in Kerbol's SOI. Chances are, they will have each already burned for a rendezvous with their destinations, and so their orbits will be greyed-out with respect to each other. Bill will see Alice's orbit disappearing at a random point in space, probably nowhere near Kerbin, but that doesn't matter to him; Alice will see Bill's orbit disappearing at a random point in space, probably nowhere near Duna. Again, doesn't matter. 

If Bill and Alice end up in Kerbolcentric orbit, then they will both see each other's orbits as closed. They will see the various planets at different places, but that doesn't matter. They can rendezvous to each other, if they like. If they then decide to head to the same destination, they will each have to warp to a good transfer window individually, which will probably take them way out of sync with each other, but they'll arrive at the same time so it's not an issue.

38 minutes ago, Spricigo said:

Nothing is so bad that can't be made worse... Charlie is in solar orbit the whole time, for he is year 1 day 55. Screw whatever plan Alice or Bill have, warp-to-window as much as you want and as soon as you enter Sun's Soi the planets will be out of alignment, since that is what is happening in that SoI timeline. Btw, Charlie is stubbornly refusing to warp time so the planets can reach the favourable alignment Alice and Bill want.

Nothing Charlie does can affect Bill or Alice.

[Spricigo]

31 minutes ago, sevenperforce said:

Doesn't matter.

As I've explained, the positions of other SOIs are not shared. The only things shared within SOIs is the rotation of the object and the positions of manmade vehicles within that SOI.

Why not? The planets SoI are objects within the Sun's SoI. Maybe a more important point: The Sun's SoI end where the planet SoI start. If the SoI limits are not the same for all the player, they are not all in the same SoI.

Your proposal just change from don't agree about when is now' to don't agree about where is here.  And we still have paradoxes.

45 minutes ago, sevenperforce said:

If Bill and Alice end up in Kerbolcentric orbit, then they will both see each other's orbits as closed. They will see the various planets at different places, but that doesn't matter. They can rendezvous to each other, if they like. If they then decide to head to the same destination, they will each have to warp to a good transfer window individually, which will probably take them way out of sync with each other, but they'll arrive at the same time so it's not an issue.

Bill and Alice dock their vessels...then they reach a SoI transition that is only there for Bill. ...?

 

41 minutes ago, sevenperforce said:

Nothing Charlie does can affect Bill or Alice.

Why not. They are all in the same SoI. ...or not?

 

[sevenperforce]

22 hours ago, Spricigo said:

Why not? The planets SoI are objects within the Sun's SoI. Maybe a more important point: The Sun's SoI end where the planet SoI start. If the SoI limits are not the same for all the player, they are not all in the same SoI.

Your proposal just change from don't agree about when is now' to don't agree about where is here.  And we still have paradoxes.

Nothing about the proposal changed; you're just understanding a little more about it.

Coding timewarp interactions in multiplayer would be straightforward enough, but it would not be entirely simple. In order to implement a timewarp-handling system which does not cause paradoxes, you do have to do a bit of work.

The multiplayer game would need a variable or two to define each craft's interactions with the multiplayer overlay. Probably InSOI and IsOrbitClosed. InSOI would have 17 possible values; IsOrbitClosed would be a boolean. Players would only see the orbits of craft controlled by other players if the InSOI variable of their craft matched the other craft, and they would only see the other craft as targetable if both their craft's IsOrbitClosed and the other craft's IsOrbitClosed were both true. 

IsOrbitClosed would be defined for each player with respect to their own universe. If your orbit crosses an SOI boundary within the next full orbit, IsOrbitClosed = false. If your craft will make one full orbit without crossing any SOI boundary, IsOrbitClosed = true. This is only defined with respect to your own universe.

Does this make sense? Two vehicles controlled by different players would only able to interact when they are both inside the same SOI with closed orbits. Granted, this would preclude a very small subset of possible interactions (e.g., two players both burning from Kerbin to Duna simultaneously and then docking), but we have to accept that multiplayer is going to involve some tradeoffs.

No paradoxes.

22 hours ago, Spricigo said:

Bill and Alice dock their vessels...then they reach a SoI transition that is only there for Bill. ...?

Why not. They are all in the same SoI. ...or not?

Obviously, you're also going to have to figure out rules for collisions when two vehicles dock, but that's already going to have to be figured out for multiplayer anyway.

To start with, Bill and Alice will not be able to dock in the first place if Bill's orbit crosses an SOI in the future, because Bill's IsOrbitClosed variable would be false. If Bill is on a Hohmann transfer from Eve to Jool, and Alice is in ordinary closed Kerbolcentric orbit, Alice will not see Bill's vehicle as targetable. She'll see the orbit, of course, but it will be greyed out and she'll see it ending at a random point in space.

If both Bill and Alice are in ordinary closed Kerbolcentric orbits, then they can rendezvous and dock. Docking in multiplayer will have to have collision rules to start with, though, because you don't want two different people controlling the same vessel at the same time. Vessels probably need a tweakable that turns "open for docking" on or off, and you have a male-female interaction where one player has to actually initiate the docking and then assumes control of the target vessel, while the other player loses vessel control after docking.

If Alice was the one to initiate the docking procedure, then she takes control of the combined vessel, and the part of the ship that formerly belonged to Bill is now part of Alice's universe. Bill can see it, of course, but Bill is not actively controlling it. If they swap positions, then the combined vessel switches over to Bill's universe. 

This might lead to some interesting gameplay, where Bill says "Hold on; I've got a transfer window in just a few weeks; let me take control and I'll get us there," or vice versa. But total dV is still conserved, so it doesn't break anything.

[Spricigo]

3 hours ago, sevenperforce said:

Nothing about the proposal changed; you're just understanding a little more about it.

What? Why are you saying that?

NO. MY UNDERTANDING OF THE PROPOASAL DIDN'T CHANGED AT ALL!!!

If you are not willing to accept we have different opinions about this subject them this conversation is a waste of our time. Bye.

[razark]

11 hours ago, sevenperforce said:

In order to implement a timewarp-handling system which does not cause paradoxes, you do have to do a bit of work.

Simple:

max_timewarp = player[0].timewarp_request;
for (i= 1; i < number_of_players; i++)
{
  if (player[i].timewarp_request < max_timewarp)
    max_timewarp = player[i].timewarp_request;
}
timewarp = max_timewarp;

 

Paradox free and simple.

[DualDesertEagle]

As I've said before, if it was me who had to implement multiplayer I would limit that to playing with friends. Everyone would be independent from what's happening outside the VAB or SPH while building their stuff but as soon as they take their stuff to the launchpad or runway they're part of the following system:

 

Time Warp can only be used when everyone has reached a stable situation or until the next event.

So let's say Player 1 has finished his ship really quickly and launches before anyone else has built half their ship. He puts it into orbit and starts setting up a maneuver to leave the Kerbin System and head to the Jool System. Meanwhile player 2 has his craft on the launchpad and hits space. from this moment onwards time warp is locked until player 2 has reached a stable orbit and player 1 has finished his burn. But player 2 hasn't set up his maneuver to Minmus yet, so he does that real quick and both can now enter Time Warp until player 2 reaches his maneuver node. He executes his burn and Time Warp can go on. Meanwhile Player 3 has finally finished his ship and goes to the launchpad. Time Warp is interrupted with player 2 being half-way to Minmus and player 1 a little over half the height of Kerbin's SOI. Player 3 launches, starts orbiting and sets up his maneuver to follow player 1. He executes and Time Warp can go on until Player 2 has reached his Minmus encounter. Since Players 1 and 3 can't do anything useful now they're free to watch Player 2 do his thing, which would in this example be landing on Minmus' flats and extending solar panels to start mining, which, as we all know, is a time consuming process, so time warp can go on again, while the 3 are talking about the recent events in their respective areas. Then, after several changes of mind and lots of tweaking, player 4 is finally done building his ship and launches. Time Warp is of course interrupted again until he's made orbit and set up a maneuver. Time Warp goes on until said maneuver, maneuver is executed, player 4 is on his way to Eeloo, Time Warp goes on until Player 1 reaches the Jool System. Player 2 does a quick check on his miner, starts producing fuel and then joins the other idle ones watching player 1 making orbit around tylo to wait for player 3 to catch up. 

 

I could go on, but by now everyone should get the picture.

 

This is how I would implement it. Seems to be the most sensible way to me.

[sevenperforce]

14 hours ago, razark said:

Simple:

max_timewarp = player[0].timewarp_request;
for (i= 1; i < number_of_players; i++)
{
  if (player[i].timewarp_request < max_timewarp)
    max_timewarp = player[i].timewarp_request;
}
timewarp = max_timewarp;

 

Paradox free and simple.

If I understand your pseudocode correctly, this merely says that warp is limited to the lowest warp currently being requested by all other players...so unless everyone requests at least a warp of x2, there's no warp at all?

I don't think this is a good solution. Players 3 and 5 should be able to execute a docking maneuver above Laythe while Player 2 warps from Eve to Duna and Player 4 warps around Kerbin to get a good Mun transfer point and Player 1 is afk.

10 hours ago, DualDesertEagle said:

As I've said before, if it was me who had to implement multiplayer I would limit that to playing with friends. Everyone would be independent from what's happening outside the VAB or SPH while building their stuff but as soon as they take their stuff to the launchpad or runway they're part of the following system:

Time Warp can only be used when everyone has reached a stable situation or until the next event.

So let's say Player 1 has finished his ship really quickly and launches before anyone else has built half their ship. He puts it into orbit and starts setting up a maneuver to leave the Kerbin System and head to the Jool System. Meanwhile player 2 has his craft on the launchpad and hits space. from this moment onwards time warp is locked until player 2 has reached a stable orbit and player 1 has finished his burn. But player 2 hasn't set up his maneuver to Minmus yet, so he does that real quick and both can now enter Time Warp until player 2 reaches his maneuver node. He executes his burn and Time Warp can go on. Meanwhile Player 3 has finally finished his ship and goes to the launchpad. Time Warp is interrupted with player 2 being half-way to Minmus and player 1 a little over half the height of Kerbin's SOI. Player 3 launches, starts orbiting and sets up his maneuver to follow player 1. He executes and Time Warp can go on until Player 2 has reached his Minmus encounter. Since Players 1 and 3 can't do anything useful now they're free to watch Player 2 do his thing, which would in this example be landing on Minmus' flats and extending solar panels to start mining, which, as we all know, is a time consuming process, so time warp can go on again, while the 3 are talking about the recent events in their respective areas. Then, after several changes of mind and lots of tweaking, player 4 is finally done building his ship and launches. Time Warp is of course interrupted again until he's made orbit and set up a maneuver. Time Warp goes on until said maneuver, maneuver is executed, player 4 is on his way to Eeloo, Time Warp goes on until Player 1 reaches the Jool System. Player 2 does a quick check on his miner, starts producing fuel and then joins the other idle ones watching player 1 making orbit around tylo to wait for player 3 to catch up. 

The trouble arises in defining "stable situation". What if Player 2 has timed his ascent to rendezvous with a previously-launched craft in LKO? He reaches orbit and turns off his engines, ready to coast to the rendezvous, and suddenly warp kicks on, and he whips past the rendezvous before he can say "wait".

[pandaman]

The way i see it, ANY instances where one player is not on the same game time as any other can lead to potential paradox problems.

In a system where all players must always remain on the same game time the only potential timing issue i can see is with construction...

Players A and B are in orbit docking their respective modules to the station.  Player C is in the VAB constructing another module.  In solo play game time freezes whilst in the VAB/SPH, but in this case it MUST continue to advance at the same pace as A and B otherwise A and B can't continue.  When C is ready to launch it slots into the same timeline so 'in effect' the construction took time equivalent to that elapsed for A and B.

So it would be important to have a 'game time' clock visible in the VAB/SPH so that players constructing whilst other stuff is happening can keep track.  Also it would make sense for players constructing to be included in any decision about timewarp so they can ensure they don't miss a launch window, stock Alarm Clock also very useful here..

[razark]

1 hour ago, sevenperforce said:

If I understand your pseudocode correctly, this merely says that warp is limited to the lowest warp currently being requested by all other players...so unless everyone requests at least a warp of x2, there's no warp at all?

Exactly.  It's the only paradox-free method, and it's pretty simple to do.

 

1 hour ago, sevenperforce said:

I don't think this is a good solution. Players 3 and 5 should be able to execute a docking maneuver above Laythe while Player 2 warps from Eve to Duna and Player 4 warps around Kerbin to get a good Mun transfer point and Player 1 is afk.

And I question why people are playing "together" if one is at Laythe, one's at Duna, and one's at Kerbin.  In you example, 3 and 5 should be playing on a multiplayer-KSP.  2 and 4 can get the same experience by playing single-player KSP and using a chat server outside the game.

The AFK guy can be kicked by the server admin.

[Spricigo]

9 hours ago, pandaman said:

In a system where all players must always remain on the same game time the only potential timing issue i can see is with construction...

As you point out in that system everyone always stay in the same time, that includes 'at the editor'. So, that's not really an issue.

The issue in that system may be players not agreeing on when and/or how fast to warp.

 

 

[DualDesertEagle]

23 hours ago, sevenperforce said:

The trouble arises in defining "stable situation". What if Player 2 has timed his ascent to rendezvous with a previously-launched craft in LKO? He reaches orbit and turns off his engines, ready to coast to the rendezvous, and suddenly warp kicks on, and he whips past the rendezvous before he can say "wait".

Not if 2 ships approaching each other to less than 3 kilometers is counted as an event and the ships being so close together is counted as an unstable situation.

 

Or everyone must agree on Time Warp for it to happen.

[pandaman]

14 hours ago, Spricigo said:

 

The issue in that system may be players not agreeing on when and/or how fast to warp.

 

 

True, but if it's an 'all click to agree' or no timewarp happens situation then at least no player gets their ship demolished because another player  was being 'a bit selfish' and didn't bother to check.

Yes of course there will be times when one player wants to warp and another isn't ready yet.  And that will get more common with more players, but if players aren't prepared to communicate and cooperate then why are they playing together anyway?

I don't imagine KSP multiplayer having large numbers in any one 'session' anyway, certainly if using the 'all warp together' method. So reaching agreement, especially if they are doing joint missions, shouldn't be a big problem.

[Greenfire32]

On 2/14/2018 at 10:03 AM, Not Sure said:

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

THIS ^

On 2/14/2018 at 10:37 AM, razark said:

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

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.

Time warp is not an issue in DMP. What is an issue in DMP is the fact that it's a bit of a buggy mess. That has nothing to do with time warp, however, it's more to do with the fact that KSP is not inherently a multiplayer game and isn't really built for it. There are some bugs regarding time warp, specifically, but it's mostly because in its current state DMP does not clean up "paradoxes" (versions of "you" that still exist in other player's universes when you've already time warped away from them). All DMP really needs is some kind of cleanup function that removes any version of "you" that isn't actually "you" at your current time.

But seriously, DMP has long since solved the issue of how to handle time warp and multiplayer within KSP. It honestly boggles my mind that we still see debates about "butt hao whill teh tiems wharp werk?!" Basically it works as thus: the server has a "master universe." This is what allows players to exist in the first place. If a player uses time warp, they leave the master universe and enter what is essentially their own pocket universe. They will forever remain in this pocket universe unless they just so happen to be the "furthest" in the future, in which case that specific player's universe becomes the master universe (the server only uses this information to keep the game-clock "up-to-date," it doesn't use this to limit what players can and cant do). No other players can interact with them until they "sync" up to their universe. Players can only sync forward in time and never backwards.

Ultimately, this removes general trolling and loveery by forcing players into their own bubbles and if they want to interact with other bubbles, they have to merge bubbles. Players can sync and desync at will, so it's not a one-time-deal. You want to go to the moon? Me too. I'll meet you there. Only my rocket isn't as good as yours, so while you will arrive sooner than I will, once I get there I can sync to you and now we can dock and interact again. The trip only took your craft 1 day, but it took mine 3 and yet in IRL time we both get there within seconds of each other. You hang out in Munar orbit, I sync to you and rendezvous. Boom. Docked and playing together.

Time warp's solved. 100%. Literally all that needs doing now is bug fixing, performance stabilizing, and maybe a slight tweak to time warp to make it better (like paradox cleanup) for multiplayer. All of which Luna Multiplayer is looking to fix.

----EDIT----
And by "paradoxes" I don't mean that players can influence your current craft in your past. The way it works currently in DMP is that a copy of your craft is retained in their present (your past) so if they destroy your craft in your past, you don't suddenly explode in your present. All that is destroyed is a copy of you. You will continue on as if nothing happened.

The only time another player can directly affect you is if they are in the same space-time as you.

Edited February 19, 2018 by Greenfire32

[razark]

2 hours ago, Greenfire32 said:

Time warp is not an issue in DMP.

How did they solve the paradox issue?

 

2 hours ago, Greenfire32 said:

The way it works currently in DMP is that a copy of your craft is retained in their present (your past) so if they destroy your craft in your past, you don't suddenly explode in your present. All that is destroyed is a copy of you. You will continue on as if nothing happened.

Oh, I see.  They didn't.

In that case, " Time warp's solved. 100%." is wrong.  What you meant to say was: "DMP handles timewarp in a manner that I approve of."

But I'll play, too:  I already posted the single, solitary, correct way to do it, so everyone must now agree that it's correct and the discussion is closed! 

How's that?

 

Look, you value not waiting.  I value no paradoxes.  Any multiplayer is going to have (at least) one of those.

There is a fundamental issue with timewarp in multiplayer.  Until you solve that issue, you can't ever say it's "solved. 100%."  Not even close.

 

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

[pandaman]

Ok. I haven't used DMP, but I can see that it uses a workaround for the timewarp/paradox issue that is perfectly good enough for many people.  Nothing wrong with that and it appears to do it's job well enough for them.

So, out of curiosity, may I ask all those who do use DMP a few questoons...

1. How often do you actally interact with other players?

2. Are the players you interact with either known to you personally or fellow DMP players you encounter regularly.

3. If and when you do interact is it planned? Have you arranged in advance to cooperate on joint ventures or mutual hostilities.

4. How common is it to encounter other players at random?

5. Do you engage in joint ventures with players that you come across at random?

 

I could very easily be wrong here, but I get the impression that some players see KSP as fitting into the multiplayer/online format that they are accustomed to with games such as Minecraft, Eve, CoD etc, which, by it's very nature KSP doesn't do very well.  And the idea of a single player offline game is a little alien to them.

I get that they may like to know they have other people around to make it seem 'normal', even if they never encounter them, but what i have trouble grasping is that unless you are actually setting out to play and interact with others why bother with multiplayer?  And if you are then surely you need to be in the same time bubble or else you aren't actually playing together anyway.

If player A and B are in orbit together around Kerbin and A decides to go to Duna and timewarps, leaving a 'copy' of his ship in B's timeline, then  B can no longer interact with A as a 'player' (because he's not there), but only with the empty uncontrolled vessel. And A can't interact with B because he doesn't exist in his timeline.  They are no longer in a miltiplayer game, but two simultaneous single player games.  Yes, presumably, B can decide to fast forward to the same time as A, but B's time has the copy of A's vessel in Kerbin orbit in it so what happens to that?

I'm not saying that DMP players are 'wrong'.  If it works for them and they enjoy playing with that system then that's what really matters.  I just don't think that it is a suitable option for the stock game.

[Talavar]

The timewarp problem was already addressed in DMP. It's really simple. I suggest trying it out. It works fine as far as the timewarp problem goes.. it's just how DMP handles the movement that is the problem... if MP was incorporated into the game itself instead of being pasted on top of it with a mod, it would already have been successful.

6 hours ago, pandaman said:

Ok. I haven't used DMP, but I can see that it uses a workaround for the timewarp/paradox issue that is perfectly good enough for many people.  Nothing wrong with that and it appears to do it's job well enough for them.

So, out of curiosity, may I ask all those who do use DMP a few questoons...

1. How often do you actally interact with other players?

2. Are the players you interact with either known to you personally or fellow DMP players you encounter regularly.

3. If and when you do interact is it planned? Have you arranged in advance to cooperate on joint ventures or mutual hostilities.

4. How common is it to encounter other players at random?

5. Do you engage in joint ventures with players that you come across at random?

 

I could very easily be wrong here, but I get the impression that some players see KSP as fitting into the multiplayer/online format that they are accustomed to with games such as Minecraft, Eve, CoD etc, which, by it's very nature KSP doesn't do very well.  And the idea of a single player offline game is a little alien to them.

I get that they may like to know they have other people around to make it seem 'normal', even if they never encounter them, but what i have trouble grasping is that unless you are actually setting out to play and interact with others why bother with multiplayer?  And if you are then surely you need to be in the same time bubble or else you aren't actually playing together anyway.

If player A and B are in orbit together around Kerbin and A decides to go to Duna and timewarps, leaving a 'copy' of his ship in B's timeline, then  B can no longer interact with A as a 'player' (because he's not there), but only with the empty uncontrolled vessel. And A can't interact with B because he doesn't exist in his timeline.  They are no longer in a miltiplayer game, but two simultaneous single player games.  Yes, presumably, B can decide to fast forward to the same time as A, but B's time has the copy of A's vessel in Kerbin orbit in it so what happens to that?

I'm not saying that DMP players are 'wrong'.  If it works for them and they enjoy playing with that system then that's what really matters.  I just don't think that it is a suitable option for the stock game.

  1 frequently.
2 only people who you invite to your server are on it.
3 generally yes, or we land at a space station on another planet near each other.
4 not that common (randomly) (unless you are around KSC, or a moonbase or something) however you are usually building something together (like an orbital station), so you see each other frequently.
5 As stated previously, you're with people who were invited to yourserver, so you don't usually encounter them at random points.. Rather, you're working together to get something accomplished.
    As for your timeline question, you're forgetting that player A has to throttle up his ship, and do all his maneuvers before he time accelerates... This causes his ship to leave your area.. Hence there is no ship left behind in player B's area. When he time accelerates, your version of the game would have his last known burn coordinates. so it's showing his travel in real time, until you time link with him. which jumps all elements in your game to his current time.. this updates your orbit to where it would be around the planet, and where the planet you are orbiting would be in his timeline. It works very well.
  The only problems you can encounter is if you're docking to something that someone is docked to in the future, then try to time jump to their timeline.. however, this is easily fixed by one line of code stating "This node is currently occupied in the future, timewarp will be unavailable until you undock again"
   The other version of this is if you are docking with something that was destroyed in teh future... Which you would get a similar message stating that it was destroyed in the future, and you cannot time warp until you undock from it.
  The other problem is the reverse.. If something is destroyed in the past while you are docked to it in the future... Which in this case, as soon as you undock from it, it simply vanishes in your future timeline.
  Over all though, these problem RARELY come into being. because people would generally have to time accellerate as much as you did just to get to the same point as you. Hence their past selves are still headed to where you are at.
 I seriously suggest Trying DMP. It will answer ALL of your questions just through experience.   Honestly, the problem with DMP is how things move. As people move around each other, there is no movement easing, it updates in increments, basically destroying your character in its last known location, then rebuilding it in its new location.. this makes it look... well.. wonky.. and it really jacks up when doing things like climbing ladders. If therewas actual movement easing where the chracters actually move from point a1 to point a2 instead of disappearing and reappearing really fast, it would work much better. It can only be implemented by placing it into the actual game code.. the work is pretty much already done, all it needs is to be placed into the game engine itself, rather than being pasted over top of it, which causes alot of the problems.

Edited February 20, 2018 by Talavar

[KOCOUR]

2-5 player coop, only admin can timewarp, timewarp aplies to all.  Then ill buy a new copy of KSP for my wife, and we´ll play together. Happines ensured.