Squad should adopt DMP (to satisfy the multiplayer hunger)

[Not Sure]

Every time I browse the suggestions thread I see a multiplayer thread and decide to check it out to see if anybody has even played the already existing multiplayer mod. 

Timewarp timewarp timewarp...

If you don’t know how DMP handles timewarp, it’s a little tricky at first and isn’t very orthodox. But it works. Basically. Every person gets their own time reference frame. You can warp just like in single player, but you disappear to everybody else not in that time frame. When you get out of warp, people will be behind you in time. Don’t think about it too much, just as long as you can’t travel backwards in time (wich you cant) there won’t be any huge paradoxes. Other people can view the multiplayer menu and “sync” to your time frame. Now you can see each other again. They get pulled very rapidly into the future and everything is dandy as long as you aren’t sub-orbital. If they warp ahead, they can no longer see you, you have to warp to them. You cannot sync to people in a past time frame, they have to sync to you.

mods? Mods are easy to handle. Have stock servers and modded servers. Have a mod list for each server (only part mods matter). 

What’s wrong with DMP then? It’s biggest issue is that it’s a mod, it’s not stock. (It’s got framerate issues and teleportation bugs and whatnot) The games code could easily be optimised and tweaked to work well with multiplayer, but you can’t tweak base code from a mod. All squad has to do is adopt the mod like they did for so many others, and all will be happy. 

Imagine it though.. building a base with your bud on pol.. or maybe a rival space administration.. The KSP system is too big to explore it all alone.

[Gargamel]

How is this post different from the already existing thread (s) on this?  What makes your suggestion deserve it's own thread?  It's a fairly well written post, so I ask for clarity (not a MP'er), not snarkiness, even though the existing thread is currently on the (top of the) first page.

 

[SnailsAttack]

Wouldn't this have like... colossal issues with planets and their orbits? 

[pandaman]

DMP obviously works well enough for you, and how you want to play.

But that doesn't neccesarily make it 'right' for an official 'stock' solution.  For a whole variety of reasons discussed in detail in the existing thread(s).

[OHara]

6 hours ago, Gargamel said:

How is this post different from the already existing thread (s) on this?  

 

This thread, "Adopt DMP," suggests that the approach taken by DarkMultiPlayer --- where we must time-warp to synchronize with another player in order to see or interact with any vessel he controls or has touched --- should be considered for inclusion in KSP.    The downsides of requiring synchronization to interact have been discussed (link to an example in an old thread). This thread suggest that the downsides might acceptable in exchange for an implementation in KSP of a demonstrated design.

The thread "Possible Solution to the Multiplayer Issue" suggests a few ways of changing the meaning of time-warp (generally having the effect of teleporting ships without advancing the orbits of celestial bodies and non-warping craft) so that players can interact after time-warp without synchronizing to the same 'time' as defined by the celestial bodies' locations.  That thread is more about brainstorming designs.

[Spricigo]

For me the "multiplayer" of stock KSP are the challenges, save sharing and craft sharing. With some new possibilities in the horizon (Making History DLC).

If that is not enough for you, mods are there to increase your options. 

 

In my opinion, DMP is a reasonable mod option.  And don't need to get past it.

[razark]

20 hours ago, Not Sure said:

...as long as you can’t travel backwards in time there won’t be any huge paradoxes.

There is a station in orbit.  A launches a ship and docks to the docking port.  B, in an earlier timestream, but later in realtime, launches a ship and goes to the station.  Can B dock to the unoccupied docking port?  If so, what happens to A, who is already docked to it in the future?  If B cannot dock to the port, then the future is affecting the past.

Let's say you manage to resolve that.  B and A both find a way to dock in their own time streams.  A refuels, leaving the station empty.  B, in a time before A refuels, attempts to refuel.  Who gets the fuel?

B, now angry about having to argue with reality for a parking spot and not being able to refuel from the clearly available fuel, decides to destroy the station.  Ramming into it at high speed, the station is shattered into orbital debris.  What now happens to A, the station debris, and the fuel that A has taken?

 

I'd dispute that those are some pretty big paradoxes that result.

[Not Sure]

8 minutes ago, razark said:

There is a station in orbit.  A launches a ship and docks to the docking port.  B, in an earlier timestream, but later in realtime, launches a ship and goes to the station.  Can B dock to the unoccupied docking port?  If so, what happens to A, who is already docked to it in the future?  If B cannot dock to the port, then the future is affecting the past.

Let's say you manage to resolve that.  B and A both find a way to dock in their own time streams.  A refuels, leaving the station empty.  B, in a time before A refuels, attempts to refuel.  Who gets the fuel?

B, now angry about having to argue with reality for a parking spot and not being able to refuel from the clearly available fuel, decides to destroy the station.  Ramming into it at high speed, the station is shattered into orbital debris.  What now happens to A, the station debris, and the fuel that A has taken?

 

I'd dispute that those are some pretty big paradoxes that result.

If you've played DMP a reasonable amount you'll see the "this vessel has been changed in the future" message, which locks your controls until you are past the point that the vessel has changed. A little annoying, but simply syncing ahead before launch could stop the whole ordeal. Thankfully, every time you join a server you get synced to the person farthest ahead. 

 

What happens to A after the station is destroyed? Nothing. (If they have taken fuel and undocked) they continue on their way because in their time frame nothing happened. Say we go back. A docks with the station. B, a couple minutes behind, docks to the same port. B cannot take control so he warps ahead, but what happens to A? I don't see anything happening to A as the entire station is now his vessel. They may loose control, but they each kinda have their own craft now, and the one farthest in the future is synced to the server. I'd give room for freedom, if you want ultimate realism, you can talk to the other guy who is docking and dock to different ports. 

Edited February 15, 2018 by Not Sure

[pandaman]

I understand why two players playing together may want to travel to different planets, and time warping is neccesary to do that in an acceptable time IRL.  And the way DMP deals with timewarp is a work around that enables players to do that, and enjoy the game in a different way.

I just don't feel that that particular approach is the right one for stock.

[Darth C3P0]

Can I just say that although I aint opposing this suggestion, DMP has it's fair share of bugs and compatibility issues when it comes down to clients.

[OHara]

And I'll say, although I aint supporting this suggestion, reading the DMP thread gives the impression that many of its bugs are due to lack of control of  how the core of KSP adds/deletes crafts.