Time warp mechanic

[Pthigrivi]

22 minutes ago, The Aziz said:

The only solution to that I can think of is a message "Player B has already reserved the place on these coordinates".

I think this is true, but fortunately it only matters on the surface where space is fixed. And you're going to want to coordinate this because players are going to want to build near each other to collaborate on bases. I think what works is to have all saved base states appear on the surface, ghosted if it doesn't exist yet or if its last interaction is in your future.

5 minutes ago, shdwlrd said:

You know how this forum can be. If not explained, people will throw out ideas and try to justify them. If explained, people will complain that it's not how they invisioned it. 

I'd actually love someone to explain in more detail how DM works. We're all sort of speculating about something someone has already thought about a lot.

[shdwlrd]

9 minutes ago, Pthigrivi said:

I'd actually love someone to explain in more detail how DM works. We're all sort of speculating about something someone has already thought about a lot.

You could ask the creator or one of the maintainers to explain how it works. Or you can get a coder friend to look at the git to figure out the internals.

[Guest]

7 minutes ago, Pthigrivi said:

2 hours ago, Master39 said:

Every system would break apart if a player just wants to warp 10000 years in the future, a minimum of coordination is always required, that's why I used my example with the Duna rover and sample return, because that's 3 players that are playing together in a realistic way and it becomes a chore for all of them if they have to wait their turn to play instead of being able to only sync up when needed.

I think any official multiplayer has to be able to handle both. Whether its 10,000 years or a day doesn't really matter, you're going to have combinations of players in the future, in the past, and sharing physics bubbles at 1x. Im sure you will have people synched to each other from time to time, but if we don't want to force players to wait while other players do something most of the time players will be in their own slice of time interacting with their own creations and the creations of others. 
 

3 hours ago, Master39 said:

You don't have to have multiple save states of anything, just a single line with the timestamp of the last event happening to a craft to have the date the player has to warp after.

Exactly, not multiple save files, but multiple non-active vessels sharing the same world at different times. Say player 1 is at day 300 and player 2 is at day 200. If the last time player 1 interacted with a station was on day 250, player 2 should have to time warp to day 251, not day 300. Over time most of the stuff floating about will be in the state of that station, its last-altered state saved to the date of its last interaction. 

@The Aziz put it better before, the player farther ahead in time sets the server save, you just pick up the latest version of a craft and in its metadata you'll find the timestamp of the last edit telling the player 2 to warp at least to day 251.

 

11 minutes ago, Pthigrivi said:

I think you have to record the position, vector, and orientation of every vessel all the time anyway. If Im in the past relative to other players I should see their vessels in map mode as they existed in my present. You're going to have at a given time lots of vessels in transit that aren't in a stable orbit. There are times when you may even want to dock to one, say, as it buzzed by on a gravity assist. The only way to understand that vessel's position and path would be for it to appear as it did at your present time. 

You can if you want, all of this complexity doesn't get transferred to the players, the opposite it's true, you can make the system as complex as you want and it's only going to remove the need to deal with that complexity while playing.

 

15 minutes ago, Pthigrivi said:

Again because I suspect most players will be playing un-synched most of the time there's no particular reason why they couldn't pause. In fact I think you need to be able to. Same goes for quicksaves. It's often not as simple as replacing solar panels, someone could miss their landing and destroy half a base that took months to build. Im pretty good at landing precisely but every once in a while I biff it. Again if you spent hours building something and transporting it to Val it would be pretty frustrating to have to go all the way back because the lander tipped over. And any time that you're not synched this shouldn't be a problem. In fact even if you are synched a revert would just have your vessel disappear from the other players view. 

Yep, no reason not to, but remember that we accept limits in the timewarp system because "that's just how it works", I'm not going to argue that a timewarp system it's impossible just because you can't timewarp on rail 100x during atmospheric re-entry.

That's a bit the point here, accepting some limits "because that's how it works" it's infinitely better than not having the system at all.

 

I'm just throwing ideas around to show that an unsynced system is indeed possible and not that big of a deal, if I can think about some system and the people behind Dark or Luna MP can I'm pretty sure is not going to be a big deal for the "Multiplayer Engineer"  they were searching for, especially if you throw some hundred hours of playtesting different prototypes into the mix.

[Pthigrivi]

22 minutes ago, Master39 said:

Think about it, you have to be able to see future crafts, bases and stations, otherwise you wouldn't be able to catch up and interact with them.

Oof this is a good point. The problem is that future doesn't exist yet to see. You could fake it with vessels that are landed or in easy orbits, but if the vessel is in transit or in an orbit that eventually intersects a moon's SOI you've got problems. It's almost like players need to be able to scan forward and backward in time to see whats going on at any given point.

[mcwaffles2003]

14 hours ago, Master39 said:

Think about it, you have to be able to see future crafts, bases and stations, otherwise you wouldn't be able to catch up and interact with them.

I feel like this would be difficult (not impossible but I'm trying to imagine it) with rotating bodies orbiting other bodies in space. In the most simplistic manner of only a single point of origin at Kerbol someone at Kerbin that's 10 seconds away from you in time but relatively in the same space is 92km away since Kerbin is going around Kerbol at 9.2 km/s.  If the point of origin is set by center of SOI, which makes a lot more sense, then the n-body dynamics regions like rask and rusk will get a bit weird in a similar fashion.

That aside, while attempting to perform a rendezvous as a player in the past I think we will need to see both the relative present  target as well as its future ghost, right? But if you go to rendezvous with the future ghost and if the rendezvous requires a timewarp that passes the present of the future player then when you arrive will you be arriving to rendezvous with a predicted target or will that target temporarily disappear on arrival? And if that target is there what happens if the new past player that was the future target before now alters course so as the rendezvous would never have made it?

Edited June 17, 2021 by mcwaffles2003

[Pthigrivi]

I have an easier time thinking about this kind of thing when I draw it out. I have no idea how difficult this would be to program, but it would be amazing if these multiplayer saves were a continuum of edits and players could scan forward and back to see whats happening at any given time and hop in and make edits as they like so long as they weren't breaking causality. 

Edited June 17, 2021 by Pthigrivi

[Incarnation of Chaos]

On 6/17/2021 at 3:15 PM, Pthigrivi said:

I have an easier time thinking about this kind of thing when I draw it out. I have no idea how difficult this would be to program, but it would be amazing if these multiplayer saves were a continuum of edits and players could scan forward and back to see whats happening at any given time and hop in and make edits as they like so long as they weren't breaking causality. 

All a save really is in reality is a ledger, and it keeps track of enough state to rebuild the game at the desired point.

But it only represents that instant of time, for you to "rewind" you would have to keep track of far more than a standard save.

At which point, you might end up with the size of them running away from you rather easily.

But this is definitely an area I'm not exceptionally knowledgeable about.

[Pthigrivi]

16 hours ago, Incarnation of Chaos said:

All a save really is in reality is a ledger, and it keeps track of enough state to rebuild the game at the desired point.

But it only represents that instant of time, for you to "rewind" you would have to keep track of far more than a standard save.

At which point, you might end up with the size of them running away from you rather easily.

But this is definitely an area I'm not exceptionally knowledgeable about.

Right, but we don’t necessarily know how ksp 2 will go about it. You also dont have to record every bump of an rcs thruster, just the location, vector, and configuration  after exiting from the active vessel. Im not a programmer and this may still be too much but it seems to me like yhe most robust and useful system. With any luck they’ve anticipated the “How do I see craft in the future” problem and found a way to jump ahead and back to see where things are and when things are so you can plan rendezvous. 

Edited June 19, 2021 by Pthigrivi

[Incarnation of Chaos]

5 hours ago, Pthigrivi said:

Right, but we don’t necessarily know how ksp 2 will go about it. You also dont have to record every bump of an rcs thruster, just the location, vector, and configuration  after exiting from the active vessel. Im not a programmer and this may still be too much but it seems to me like yhe most robust and useful system. With any luck they’ve anticipated the “How do I see craft in the future” problem and found a way to jump ahead and back to see where things are and when things are so you can plan rendezvous. 

It would probably be more like a checkpoint system, where the game would record the state after certain milestones and then you could "rewind" there. 

But yes you're absolutely right, you don't need or want to store everything. Because then you're essentially just making a second copy of the game lel.

[OHara]

7 hours ago, Pthigrivi said:

With any luck they’ve anticipated the “How do I see craft in the future” problem

There was a comment from the new developers, something like "I've never heard people laugh so hard" that implied they were prototyping multiplayer several months ago, so that helps the odds that they have anticipated.

But, after reading this thread, I fail to see any "how do I see craft in the future" problem.

LunaMultiplayer, for example, will delay showing actions taken by player A who has time warped, to other players, until they reach the Kerbin time when player A took those actions.  So, yes, it acts as if it is storing player-A actions in a queue for the server to relay to other players when the time is right.  The players who are slow to time-warp do not see Kerbin-future events until their Kerbin-time clocks reach the times of those future events.

To be concrete, I set up player-A to take Bill out to rescue player-B's Jebediah. 
Player A did a few quarter-orbit time-warps as part of the normal rendezvous. Player B had no reason to time-warp, so sees rescuer's orbit change several minutes later in real-time, when player B's Kerbin-time reaches the the rescuer's burn time.  In the image at right, Player B sees Bill still in LKO, but Player A has time-warped and completed the burn to rendezvous.

Player B's screen has a blue » button, that he should use to catch up to Player A, so he can watch his Jebediah being rescued, or even cooperate.   Suppose Player B does not time-warp.

Then Player A time-warps two days in the future to the rendezvous point.  Player B could frustrate the plan with a tiny tap on the RCS thrusters, which will change his orbit, and significantly change his location two days in his future, frustrating player A . 

Player-A trying to rendezvous sees where their targets will be through the patched-conic curves, and these curves reflect all the actions taken by other players up to the Kerbin-time currently on Player-A's clock.

Edited June 19, 2021 by OHara
example with images

[Pthigrivi]

@OHara Agreed, I think that all works fine locally at a small scale, and I do think in your time you should not see craft that do not yet exist (except perhaps bases for space allocation purposes.) Vessels that exist in your present but have been altered in your future would need to be ghosted and non-interactive to avoid paradoxes. What Im saying is if you're saving those moves anyway, wouldn't it be helpful as a player to jump forward in time temporarily to see the state of things at the time of your anticipated arrival? I think this is especially important when considering interplanetary and eventually interstellar time-scales, where players may be time-warping years apart waiting for transfer windows or flying to Jool. Player 1 might be building up infrastructure in KSOI while Player 2 has flown to Duna, set up a base, used IRSU locally to build half a colony and a receiving station in orbit, for example. If the idea is that we can collaborate on stations and bases then it probably helps for Player 1 working in Player 2's past to see whats going on. Say there's no HE3 on Duna but there is on the Mun. Player 1 might want to build a tanker above Kerbin, load up the HE3, and send it out on an efficient window. In the intervening time however (at least 300 days) a lot could change around Duna. It would be nice for Player 1 to be able to jump ahead and see "Okay the receiving station is (will be) 100km up, I need a docking port sr, and I can count on there being enough LS and RCS when I get there, but there wont be enough H2 at the station to get myself home again. Maybe I'll ask Player 2 to send some up while the tanker is in transit." They could of course do some of this over chat, but it seems like if that spatial information already exists it would be easy enough to let all players fast forward and rewind in time to see how things are evolving and chip in where its needed. 

... Although, one reason you wouldn't allow players to jump back and forth in time would be because it makes adventure mode progression a mess. Even if all the parts are unlocked from the beginning it sounds like Boom Events will effect population levels throughout the system. So if Player 1 builds a Duna Colony on day 300 that has enough LS to support 50 kerbals, then timewarps ahead doing something else, but Player 2 comes in on day 325 and plants a flag on Moho does that screw up Player 1's base? Or do they then have to jump back to day 310 to add habitation capacity? With 4 or 6 players this could get kind if insane. I guess we probably don't yet know enough about these systems so there might be a lot more complicated stuff for us to worry about here.

Edited June 20, 2021 by Pthigrivi

[OHara]

8 hours ago, Pthigrivi said:

wouldn't it be helpful as a player to jump forward in time temporarily to see the state of things at the time of your anticipated arrival?

Helpful to the player peeking into the future, yes.  In the example I put above, Player B could then see that he disrupted a future rendezvous with his RCS thrusters, and reverse the damage. 
But, in my opinion, enabling peeks into the future is not likely to make a better game, because it breaks the illusion of a Kerbal piloting the craft in some real-ish universe.  Better to let the other players say on chat: "stop changing your orbit and time-warp-sync to catch up with us."

===
The word 'paradox' in this context might mean different things to different people, but the potential for conflicting timelines seems unavoidable, however KSP might let players time-warp independently.   I think we can only hope for a simple set of rules on how the conflicts are resolved.

To be concrete again, asteroid YRJ-552 is going to hit Kerbin on Day 200, so player A launches VAlentina and player B launches JeBediah to intercept, with inadequate mission planning.

VAlentina burns reasonably to arrive at the asteroid on day 95 with sufficient fuel remaining.

JeBediah uses larger burns to arrive on day 51.

Players A and B will be entering physics range of the asteroid at nearly the same real-word time, but different Kerbin dates.  If they both decide move the asteroid, there are conflicting versions of history, which the server needs to reconcile.

LunaMultiplayer happens to prioritise the physics effects of the player who first (in real-world time) loaded the asteroid into KSP physics.  In my case, Player A reached the asteroid on Day95 a minute or so before, in real-world time, Player B reached in on Day51. 
When Player A bumps the asteroid to change its velocity by 0.1 m/s, Player B sees its position quickly change by 100 km (0.1 m/s × 50 days)
When Player B bumps the asteroid with Jeb's craft, Jeb's craft bounces back, the asteroid stays 'on rails' and its orbit is unchanged.

When Player A has VAlentina claw the asteroid on day 127, Player B sees the asteroid disappear on Day 51.  It seems that LunaMultiplayer is now considering VAlentina's craft and asteroid YRJ-552 to be a single craft with just one orbital history.

==
The LunaMultiplayer wiki says "pausing is not a thing in multiplayer games" but I see no reason it could not be.  The mechanism for synchronising after time-warp would seem to apply to synchronising after one player pauses.

Restoring from a quicksaves is very awkward in LunaMultiplayer, but quicksaves are very valuable in a game like KSP.  I hope KSP2 can make some easy way to revert to a saved multiplayer state.

Edited June 20, 2021 by OHara

[Pthigrivi]

@OHaraThis is super helpful, thanks. I like the ‘on rails’ solution as well. And I think the immersion argument is the best Ive seen against sneak-peeking. 

Edited June 21, 2021 by Pthigrivi

[mattinoz]

On 6/18/2021 at 6:15 AM, Pthigrivi said:

I have an easier time thinking about this kind of thing when I draw it out. I have no idea how difficult this would be to program, but it would be amazing if these multiplayer saves were a continuum of edits and players could scan forward and back to see whats happening at any given time and hop in and make edits as they like so long as they weren't breaking causality. 

I've seen this before ---- it's basically GIT or another subversion tool much like the ones the developers use to handle multiple coders working on the project.