Multiplayer & graphical update?

[SchweinAero]

39 minutes ago, Red Iron Crown said:

(sync-warp) most certainly does not (conclusively solve the multiplayer timewarp problem), it rewards aggressive use of time warp in any race situation as real time is more important than in game time. It may be the "least bad" solution though. With multiplayer timewarp it is waiting or sync issues, choose one.

Could you elaborate? It may be that I just haven't taken part in the right kind of races. We always either use in-game time or forbid warp by our own honour system.

[Red Iron Crown]

7 minutes ago, SchweinAero said:

Could you elaborate? It may be that I just haven't taken part in the right kind of races. We always either use in-game time or forbid warp by our own honour system.

Sure. Imagine two players decide to race to catch a particular asteroid. Player 1 quickly plots a modestly fast intercept, burns, and cranks up the warp. Player 2 more carefully plots a faster intercept, burns, but warps less aggressively. In game time terms, Player 2's intercept happens sooner, but Player 1 arrives sooner in real time due to more aggressive timewarping and claws and moves it. Under DMP's timewarp scheme, the asteroid will not be there when Player 2 gets there, because Player 1 has already interacted with it and Player 2 will need to sync up with that subspace. So, even though Player 2 plotted the better intercept and would have gotten there faster in game time terms, Player 1 wins the race through more aggressive timewarping which allowed him to get there faster in real time.

[SchweinAero]

1 hour ago, Red Iron Crown said:

Sure. Imagine two players decide to race to catch a particular asteroid. Player 1 quickly plots a modestly fast intercept, burns, and cranks up the warp. Player 2 more carefully plots a faster intercept, burns, but warps less aggressively. In game time terms, Player 2's intercept happens sooner, but Player 1 arrives sooner in real time due to more aggressive timewarping and claws and moves it. Under DMP's timewarp scheme, the asteroid will not be there when Player 2 gets there, because Player 1 has already interacted with it and Player 2 will need to sync up with that subspace. So, even though Player 2 plotted the better intercept and would have gotten there faster in game time terms, Player 1 wins the race through more aggressive timewarping which allowed him to get there faster in real time.

True. Let's scratch the "conclusively". This is definitely a shortcoming of the warp system. Then again it doesn't seem to come up all that often in normal gameplay.

[Red Iron Crown]

Just now, SchweinAero said:

True. Let's scratch the "conclusively". This is definitely a shortcoming of the warp system. Then again it doesn't seem to come up all that often in normal gameplay.

Depends on how one plays, I guess. It doesn't have to be an explicit race, either. Imagine this scenario:

Player 1 and Player 2 are playing with spaceplanes supported by an orbiting fuel depot. Player 1 quickly ascends to orbit and decides to do a Mun flyby (using timewarp), and when returning to Kerbin docks with the depot and drains the fuel from it. Player 2 plays around sightseeing in the atmosphere before ascending to orbit, taking more real time but less game time than Player 1's flyby and docking. He then attempts to dock to the propellant depot. Is fuel available for Player 2 there? Should there be?

These sorts of issues are inherent to asynchronous warp, there's not a technical solution for it. Synchronous warp means waiting, most of the time. So we're back to my statement: Sync issues or waiting, pick one.  

[T-Bouw]

Red Iron Crown, your explainations for time warp in multiplayer are enlighting!

I always thought that asynchronous warp was brilliant, but the way you're telling it, it has some flaws that're not insignificant.

[Madscientist16180]

I see it as if vote-warp would be the only viable option.

The number of paradoxal situation like Red Iron Crown just described is countless if each player have it's own timeline and only synch with other when desired. 

Warping player dock to something only docking port. Latter in realtime, but sooner in gametime, a second player dock to the same port. What happens if they sync as they both will be occupying the exact same spot in space?

Player one get to Duna with aggressive warping, then spend a week of game time landing and assembling a ground base module. Player two send a craft to Duna too, but warping less agressively but launching sooner in his own time line. Get there let's assume 3 days before player 1. #2 set an orbit that have exactly the same parameters as #1, but retrograde. When player 1 enter his orbit around Duna, but craft should collide before completing an entire orbit. So what happens to the ground station the had been build "earlier" than the collision in realtime, but "after" the collision in gametime? The in-game space-time fabric get ruptured and Biff Tannen-Kerman rules over Kerbin?

Last one was a strectch, but those scenarios are truly countless.

Now i wanna try dark multiplayer just to try and create those paradox lol. Anyone of a mind to try this? Lol

[Red Iron Crown]

13 minutes ago, T-Bouw said:

I always thought that asynchronous warp was brilliant, but the way you're telling it, it has some flaws that're not insignificant.

I still think it's pretty brilliant, to be honest. The problem it's trying to solve has some pretty intractable inherent issues and it handles them admirably for most cases. I consider DMP's approach to be the "least bad" solution I've seen so far.

2 minutes ago, Madscientist16180 said:

I see it as if vote-warp would be the only viable option.

Choose one: Waiting [x]    Sync Issues [ ] 

Given the choice, I'd rather deal with the occasional temporal paradox than have to spend most of the time waiting, as is likely to be the case with synchronous warp.

[Madscientist16180]

Ya, i might be a strange beast when it comes to patience. I'd rather wait lol.

 

I can totally see having a game running and doing something else while i wait for my friends to do their stuffs.

[tater]

I'd have to vote for waiting, as I think every single object on the game should be in game-time lockstep. That functionally means little or no multiplayer in the traditional sense. If things can ever happen out of time sync at all ( @Red Iron Crown's examples) then embrace that, and add in FTL drives to take care of that since they are paradoxical anyway from a cause/effect standpoint. They might as well do this since any time mismatch is every bit as unrealistic as FTL drives.

2 hours ago, Red Iron Crown said:

Sure. Imagine two players decide to race to catch a particular asteroid. Player 1 quickly plots a modestly fast intercept, burns, and cranks up the warp. Player 2 more carefully plots a faster intercept, burns, but warps less aggressively. In game time terms, Player 2's intercept happens sooner, but Player 1 arrives sooner in real time due to more aggressive timewarping and claws and moves it. Under DMP's timewarp scheme, the asteroid will not be there when Player 2 gets there, because Player 1 has already interacted with it and Player 2 will need to sync up with that subspace. So, even though Player 2 plotted the better intercept and would have gotten there faster in game time terms, Player 1 wins the race through more aggressive timewarping which allowed him to get there faster in real time.

Player 1 was FTL as far as player 2, or any other player using less time warp is concerned.

In this sort of system, ships will be FTL much of the time to many observers. Embrace that, and add FTL and be done with it, as the "aggressive time warp" is not like FTL, it is FTL.

Edited October 8, 2016 by tater

[Red Iron Crown]

That sort of makes it a different game though, @tater.

[tater]

5 minutes ago, Red Iron Crown said:

That sort of makes it a different game though, @tater.

Multiplayer with "non-waiting" time warp IS a game with FTL, which is, as you say, a different game. No one can pretend that your example where the players arrive at the wrong times is anything except FTL. So anyone voting Sync Issues is voting for adding FTL.

[Red Iron Crown]

3 minutes ago, tater said:

Multiplayer with "non-waiting" time warp IS a game with FTL, which is, as you say, a different game. No one can pretend that your example where the players arrive at the wrong times is anything except FTL. So anyone voting Sync Issues is voting for adding FTL.

That's a bit extreme, honestly. Yes the sync issues can violate causality, but it's not like a player can, at will, cover a distance faster than would otherwise be possible with conventional propulsion. An occasional sync issue is less of a difference that FTL drives everywhere.

[tater]

Just now, Red Iron Crown said:

That's a bit extreme, honestly. Yes the sync issues can violate causality, but it's not like a player can, at will, cover a distance faster than would otherwise be possible with conventional propulsion. An occasional sync issue is less of a difference that FTL drives everywhere.

To the other player in your example, the player DID cover the distance faster. Just as in relativistic flight, the apparent time for the person on the fast moving craft seems entirely normal, but it is not to outside observers.

This is no different. Player 1 covered the distance vastly faster than they should have. Player 2 would see their craft moving up to LKO in real time, and during that same few minutes would see player 1 zip to the Mun and back. They might not be FTL, but still insanely fast. So either he was moving insanely fast, or he traveled in time. One or the other (or an admixture).

[Red Iron Crown]

3 minutes ago, tater said:

To the other player in your example, the player DID cover the distance faster. Just as in relativistic flight, the apparent time for the person on the fast moving craft seems entirely normal, but it is not to outside observers.

This is no different. Player 1 covered the distance vastly faster than they should have. Player 2 would see their craft moving up to LKO in real time, and during that same few minutes would see player 1 zip to the Mun and back. They might not be FTL, but still insanely fast. So either he was moving insanely fast, or he traveled in time. One or the other (or an admixture).

Not exactly. Player 1 doesn't arrive any faster in game time than would otherwise be possible. As DMP handles it, Player 2 would have to warp ahead to Player 1's timeframe to interact with the station or Player 1's craft. The only causality violation is restriction of Player 2's actions before syncing up.

[LameLefty]

Okay, all this multiplayer stuff is fascinating for those who care about such things. How 'bout the other half of this topic, for the rest of us who don't give a rat's behind about MP and just want KSP to keep on the path Porkjet started with his part overhauls? Is *THAT* still on the development roadmap, even if Porkjet isn't leading the charge? And will his work be the standard to which the rest is held? (Please say "Yes" to this last).

[Alshain]

The Synchronous or Subspace decision isn't something that necessarily has to be decided by the developers.  To me that is a decision that a server operator would make, the game should give either choice.

[tater]

6 minutes ago, Red Iron Crown said:

Not exactly. Player 1 doesn't arrive any faster in game time than would otherwise be possible. As DMP handles it, Player 2 would have to warp ahead to Player 1's timeframe to interact with the station or Player 1's craft. The only causality violation is restriction of Player 2's actions before syncing up.

What would player 2 see in map view while P1 was warping? I've read stuff on DMP, and I'm singularly uninterested in it, frankly. Think of how often we use time compression. Warp ahead a few minutes to a maneuver, warp to an encounter. Burn, then warp a little, then repeat. Every one of those throws you out of sync with everyone. Yuck. That makes any complaints about balance, Isp, or any other minutiae you could think of that people are concerned about pretty silly, as the time warp thing is worse. 

[Red Iron Crown]

1 minute ago, tater said:

What would player 2 see in map view while P1 was warping? I've read stuff on DMP, and I'm singularly uninterested in it, frankly. Think of how often we use time compression. Warp ahead a few minutes to a maneuver, warp to an encounter. Burn, then warp a little, then repeat. Every one of those throws you out of sync with everyone. Yuck. That makes any complaints about balance, Isp, or any other minutiae you could think of that people are concerned about pretty silly, as the time warp thing is worse. 

I agree it's not perfect, just the lesser of the evils. Synchronous warp is just dull while waiting for the other players to opt in and get substantially worse as player count increases, "Everyone must wait ten minutes while Player 1 lands on the Mun." Getting rid of timewarp altogether and providing propulsion to get places in a reasonable time without it makes it a different game altogether, at least to my mind.

Can't say I'm familiar with how DMP handles map view, if it were my call I'd leave them in place and indicate somehow that they're out of sync.

[tater]

I'd say that dumping the idea of multiplayer (aside from LAN play where the host controls all warp) is the lesser evil.

Warping craft are warping craft, doesn't matter if they have a warp engine or if they use time warp dissimilarly, same thing.

[Temeter]

On 5.10.2016 at 6:56 AM, fireblade274 said:

I've been under the impression of a lot of things in this game, which I've logged over 2.7k hours into over a few years. Though I have no burning desire to use multiplayer atm, was multiplayer not promised as a feature to be added with later updates, in addition to a graphical update?

Since the mass exodus of devs, this leaves a lot of questions with the community. I'm wondering what everyone's thoughts are in regards to multiplayer, and what the loss of major game devs means for the game. Thoughts?

Game didn't really have a major exodus: Nestor said Squad has still more dev now than they had in the beginning of 2016, and that was when they were working hard on the Unity 5 upgrade. So they should have a lot of inhouse devs we might not know about it (if I'm not missing anything). More inhouse than contracted devs also implies more working hours than before? Not sure if they included tiger devs into the numbers, but they afaik were already working on the game before 2016.

I certainly hope there are talented artists that will add some nice, clean lighting and models based on the part overhaul.

Multiplayer is still supposed to come, nothing new about that from squad. Was delayed tho, since it had less priority because of the lukewarm reception.

Edited October 8, 2016 by Temeter

[CodatheSpaceFox]

The real time VS server time issues of vote vs sync warping is an obstacle to consider, but maybe the idea shouldn't be to control the timeline instead of the vehicles themselves.

It's only a consideration, but what if docking and other vehicle to vehicle "server canon" interactions were voted on in real time? All of this discussion on multiplayer seems to come from the idea that multiplayer was envisioned to be open hosted servers like in Minecraft or something, so I don't hear a lot of talk about people simply wanting to share isolated experiences with friends, and therefore have a good idea of what each other is doing, but in the case of a more wild kerbal landscape for a multiplayer experience, it could make sense for vehicles to be controlled instead of time itself, by using some sort of player decided permission system.

If I were to elaborate on one of @Red Iron Crown's earlier paradoxes, imagine two players racing to an asteroid and the situation comes up that one player arrives faster via warp while the other would arrive faster via plotting. The former of the two clamps his claw onto the asteroid and in that case, the still physically behind player gets a prompt that states "Player X is wanting to dock to Asteroid Y in Z amount of time ahead of you" And you're given an option to literally accept or deny that interaction with consideration of your own plotting, and in the case of denying it, the claw will simply undock (or time will step back a few seconds) and the asteroid will remain sterile of that interaction.

With the idea of player permissions, say that in a public setting you didn't want some random player stealing the fuel from your depot in LKO because you need it for a mission you're planning, so you'd simply revoke permissions for other players to dock to it or interact with it outside of passing by it, and any interactions done to it including crashing or damaging it are totally ignored unless both vehicles share permission to interact, which is a decision both players make with each other, keeping the interactions limited to what you expect. While objects like asteroids are considered world owned objects and to interact with them, a vote can be placed on the player grabbing and taking ownership of that particular asteroid for themselves (Which also prevents it from being used as a vessel destroying projectile from that point on.)

[Alshain]

1 hour ago, tater said:

I'd say that dumping the idea of multiplayer (aside from LAN play where the host controls all warp) is the lesser evil.

Warping craft are warping craft, doesn't matter if they have a warp engine or if they use time warp dissimilarly, same thing.

There isn't going enough demand for LAN-only play.  Very few people would actually use it.

[tater]

1 hour ago, Alshain said:

There isn't going enough demand for LAN-only play.  Very few people would actually use it.

True. Still, either everything runs in lockstep in time, or add warp drives, because asynchronous time = warp drive anyway.

[Alshain]

1 hour ago, tater said:

True. Still, either everything runs in lockstep in time, or add warp drives, because asynchronous time = warp drive anyway.

Well I disagree with that, I think the DMP-style play works just fine, but I think it should be server operator's choice.  There is no reason not to have 2 time warp modes to choose from.

Edited October 8, 2016 by Alshain

[basic.syntax]

4 hours ago, LameLefty said:

...How 'bout the other half of this topic, for the rest of us who don't give a rat's behind about MP and just want KSP to keep on the path Porkjet started with his part overhauls? ....

Click here, this topic is devoted to your question.