.

[StarMcBound]

.

Edited August 27, 2016 by StarMcBound

[cantab]

The challenge is how to deal with people getting out of sync. Let's say I send a ship to Duna and timewarp until it gets there, but then you send a ship to Duna that arrives later in real time but earlier in the game because you used a quicker transfer.

The KMP mod has a way of dealing with, but it's certainly non-trivial.

[StarMcBound]

.

Edited August 27, 2016 by StarMcBound

[The Destroyer]

Chances are, on a large server you would go out of sync a lot=paused a lot=boring.

[boxman]

Chances are, on a large server you would go out of sync a lot=paused a lot=boring.

Multiplayer would never work on large scale with a game like KSP anyways. The best we can expect is servers with a few players on each.

[KasperVld]

Why not make timewarp client side instead? And if a crash course is detected, time warp is disabled for the period.

Well, that would mean the planets and moons are in different locations for different players after timewarping. That would present issues if you're, say, building a space station around Mun. You'd see someone else orbiting 'Mun' on the opposite side of Kerbin from where you are.

That's just one of the many problems this would cause

[technicalfool]

Would it not be possible to unify the motion of the celestial bodies, while allowing individual players to warp?

Admittedly, having not tried KMP yet, this may already be how it works.

[KvickFlygarn87]

The challenge is how to deal with people getting out of sync. Let's say I send a ship to Duna and timewarp until it gets there, but then you send a ship to Duna that arrives later in real time but earlier in the game because you used a quicker transfer.

The KMP mod has a way of dealing with, but it's certainly non-trivial.

Em, for the player it is trivial. All you need to do is push a button to catch up to a player.

[cantab]

I meant non-trivial in terms of choosing and implementing the solution to the problem. Indeed with a well-designed system it can be easy to use.

[Bilfr3d]

How about no timewarp for multiplayer?? No that would be insane. What if someone asked the server admin (which means a server admin would always have to be on), then the server admin gives a one minute warning to all players, then timewarps forward say 50x. There would be a button on every players UI so that if they need to do something they press the button, then bam back down to 1x.

[CaptRobau]

How does KMP handle this?

[Superfluous J]

This is (I believe) the primary reason Squad wasn't going to implement multiplayer. KMP's solution is both novel and simple (as the best solutions always are): Almost never care.

No, it's not quite that simple, but it is almost. People can do whatever they want, time warp however much they want, and go anywhere they want. They can meet up with whomever they are interested in working with (or fighting, whatever) and they see them on their screen where they are in Earth time. Then, whomever is farther back in time can click a "jump forward" button to sync with the person who is more forward in time. Snap, they're together.

Is it realistic? No. Does it solve every time-related problem? I haven't thought it through fully but I think so.

(Note: I've never played KMP so may have some specifics wrong but that's the gist of it)

[coolitic]

Multiplayer would probably be most effective with a different set of rules/different gamemodes.

Most effective if confined to kerbin and surrounding moons.

[Red Iron Crown]

Most effective if confined to kerbin and surrounding moons.

Even then timewarp is an issue, orbits can take hours or days in the Kerbin SOI.

[Dodgey]

I don't see the problem with just doing what KMP does. It works well enough. No need to reinvent the wheel.

[vexx32]

Would it not be possible to unify the motion of the celestial bodies, while allowing individual players to warp?

Admittedly, having not tried KMP yet, this may already be how it works.

Nope. On-rails orbits would then be a fixed speed. If you try to warp over a transfer to the Mun (or anything else), then you'd suddenly find the Mun stops moving as you expected, and you'd arrive where it ought to be only to have found it barely moved in the interval.

[technicalfool]

Nope. On-rails orbits would then be a fixed speed. If you try to warp over a transfer to the Mun (or anything else), then you'd suddenly find the Mun stops moving as you expected, and you'd arrive where it ought to be only to have found it barely moved in the interval.

This is what I get for posting without quite thinking about it.

[Red Iron Crown]

Asynchronous timewarp has some problems.

Imagine two players are racing to intercept an asteroid. Player 1 plots his intercept, does his burn and goes full timewarp and intercepts. Player 2 plots a little more carefully and finds an earlier intercept, does his burn, but only warps at half the rate. Player 1 arrives first in real time and thinks he's won the race, Player 2 arrives later in real time and earlier in game time. If Player 2 adjusts the course of the asteroid, how does the game reconcile the play that Player 1 has already performed?

Or imagine two players are messing around with spaceplanes supported by a orbiting fuel depot with 1000 units of fuel. Player 1 launches, transfers to the Mun under timewarp, then returns under timewarp, and docks with the station and takes on 600 units of fuel. Player 2 spends some time flying around Kerbin, using more real time but less game time since he isn't warping. He then ascends to rendezvous with the station and attempts to take on 600 units of fuel. Should he be able to? If yes, does Player 1 lose fuel?

[Dodgey]

Simple. Well for the fuel depo anyway. It is in its own time zone like any ship. In order to dock with it you sync with it. Bringing it forward or you forward in time. You need to match game time with it to use it. This solves the paradox issue. Not good for races but it still works. As for the asteroid I guess you could bring it forward in time when you sync. Again not good for races but I don't know how to fix that.

[Keymaster89]

I think the problem could be solved by adding something similar to allarm clock. All player go at the same game speed, when they need to time warp they have to set an alarm that specify an amount of time or a particular event from the actual start of time warp and then activate time warp, then the player will wait at normal speed until all online players request a time warp... Only then the time warp start for all players until one of the allarms set by the players trigger, reverting them to normal speed. Obviously a player doesn't have to wait all night for other player time warp, so the ship that wait for warp can be left and joined later, leaving the player the opportunity to manage other ships.

[DiscoLizard]

KMP already accomplished the time warp problem. When a player warps they go into a different phase from the other players. Then when they leave the ship other players can sync to that position, and because there are no multi-gravitational objects in KSP it is all very accurate and easy.

[Red Iron Crown]

KMP already accomplished the time warp problem. When a player warps they go into a different phase from the other players. Then when they leave the ship other players can sync to that position, and because there are no multi-gravitational objects in KSP it is all very accurate and easy.

How does it deal with issues like the ones I raised?

Edit: Since we're on a new page:

Asynchronous timewarp has some problems.

Imagine two players are racing to intercept an asteroid. Player 1 plots his intercept, does his burn and goes full timewarp and intercepts. Player 2 plots a little more carefully and finds an earlier intercept, does his burn, but only warps at half the rate. Player 1 arrives first in real time and thinks he's won the race, Player 2 arrives later in real time and earlier in game time. If Player 2 adjusts the course of the asteroid, how does the game reconcile the play that Player 1 has already performed?

Or imagine two players are messing around with spaceplanes supported by a orbiting fuel depot with 1000 units of fuel. Player 1 launches, transfers to the Mun under timewarp, then returns under timewarp, and docks with the station and takes on 600 units of fuel. Player 2 spends some time flying around Kerbin, using more real time but less game time since he isn't warping. He then ascends to rendezvous with the station and attempts to take on 600 units of fuel. Should he be able to? If yes, does Player 1 lose fuel?

[Dedjal]

Screw timewarp. Make it function like the Alcubierre drive. There is a mod containing such a device. All works in real time. No warp time needed.

Sure, it takes away those 20 mins of setting up nodes, timewarping, adjust the node a bit, timewarp some more and so on. But you do that in singleplayer, why would you have the same in multiplayer? What depth does it add to MP?

Is not MP about doing things together instead?

Edited May 26, 2014 by Dedjal

[vexx32]

How does it deal with issues like the ones I raised?

Edit: Since we're on a new page:

It can't, AFAIK. I would surmise that it simply hasn't been raised as an issue yet. It couldn't have been muhc of an issue prior to ARM, after all

[LethalDose]

Asynchronous timewarp has some problems.

Imagine two players are racing to intercept an asteroid. Player 1 plots his intercept, does his burn and goes full timewarp and intercepts. Player 2 plots a little more carefully and finds an earlier intercept, does his burn, but only warps at half the rate. Player 1 arrives first in real time and thinks he's won the race, Player 2 arrives later in real time and earlier in game time. If Player 2 adjusts the course of the asteroid, how does the game reconcile the play that Player 1 has already performed?

Or imagine two players are messing around with spaceplanes supported by a orbiting fuel depot with 1000 units of fuel. Player 1 launches, transfers to the Mun under timewarp, then returns under timewarp, and docks with the station and takes on 600 units of fuel. Player 2 spends some time flying around Kerbin, using more real time but less game time since he isn't warping. He then ascends to rendezvous with the station and attempts to take on 600 units of fuel. Should he be able to? If yes, does Player 1 lose fuel?

A thought on the first point: Different players may see different "unknown objects" (Proto-asteroids, I guess? This is how they show up in your tracking center before you track them). When they start tracking them, they're the only ones that can track them until they become "real things". It's kind of weird, but asteroids aren't "owned" until certain criteria are met, and you can't interact with something that isn't "owned". So what will probably happen is the player that is tracking an asteroid is the only one who really knows where it is, and the asteroid may not even exist for other players until that first player that discovered it interacts with it first. So, it seems unlikely that there would be a "race" for that asteroid in the first place, or at least until the asteroid becomes "real" after it loads for physics when the discovering player reaches it that first time.

On the second point... maybe the the fuel that is taken out in later game time is retroactively "allocated", or just removed in real time.

The whole concept of MP in the game is just bizarre. There are going to have to be massive abstractions to make it work, and I really don't get how it's supposed to be fun.