Parallel-sequential missions: allow returning to the past after completing a mission

[Vl3d]

56 minutes ago, Bej Kerman said:

How would NASA plan a rescue mission for another mission that hasn't happened yet? Bonus points if the rescue rocket has features you would only see in a rescue mission.

If you want to plan a rescue mission instead of reverting without recording the milestones to the main timeline, it's your choice.

Edited February 11, 2023 by Vl3d

[mattinoz]

4 hours ago, Bej Kerman said:

How would NASA plan a rescue mission for another mission that hasn't happened yet? Bonus points if the rescue rocket has features you would only see in a rescue mission.

Don’t most of the current mars mission plan involve sending ‘rescue’ missions prior to the crewed mission?

supplies and tools not found in the original ship. Whole complete extra ships to come back to earth on. 
 

the difference here is Ksp is a game it can be fun to find your crew in unintended consequences then be able to work backwards to avoid or add an escape route. Sure Kerbals have the luxury of time that humans don’t so you can just launch a rescue seconds after the accident fully customised a decade later the survivors are just sitting waiting. Still it would be more fun to work on incremental success instead of progressively failing.

[Pthigrivi]

So I finally sat down and read this thread and it kind of confirmed what I suspected when I thought about this problem a couple years ago: its a neat idea but in practice it creates a rat’s nest of issues that kind if negate the benefits. Best solution is to have time move in one direction and just run concurrent missions with alarms and switch from vessel to vessel to execute burns as they come up. There are much less problematic and time consuming solutions to things like stage recovery. And yeah, it has some interesting implications for multiplayer but keeping things simple is the reason I no longer support the green  ‘go back’ arrow in this diagram: 

Edited February 12, 2023 by Pthigrivi

[mattinoz]

3 hours ago, Pthigrivi said:

So I finally sat down and read this thread and it kind of confirmed what I suspected when I thought about this problem a couple years ago: its a neat idea but in practice it creates a rat’s nest of issues that kind if negate the benefits. Best solution is to have time move in one direction and just run concurrent missions with alarms and switch from vessel to vessel to execute burns as they come up. There are much less problematic and time consuming solutions to things like stage recovery. And yeah, it has some interesting implications for multiplayer but keeping things simple is the reason I no longer support the green  ‘go back’ arrow in this diagram: 

In terms of game play it would take many months even years in game time for something happening at duna to travel back to Kerbin. Then even with in the system thing happen far apart that getting them together to interact is a skill in it's own right.

How dense a game play situation are you expecting for this to be a real problem?

Oh well can always be a mod - might even be one before offical multi player once we get a look at the game save file structure.

[pandaman]

I think what the OP actually wants is a continuous 'recording' of each mission that can be rewound to any point, without affecting any other missions happening at the same time.

On the face of it a 'quicksave' or 'revert' type system works almost as well, but that resets the whole game, not just the one mission.

Whilst an interesting idea, I really don't see it as practical, or viable, to implement.

 

[Vl3d]

6 hours ago, Pthigrivi said:

So I finally sat down and read this thread and it kind of confirmed what I suspected when I thought about this problem a couple years ago: its a neat idea but in practice it creates a rat’s nest of issues that kind if negate the benefits. Best solution is to have time move in one direction and just run concurrent missions with alarms and switch from vessel to vessel to execute burns as they come up. There are much less problematic and time consuming solutions to things like stage recovery. And yeah, it has some interesting implications for multiplayer but keeping things simple is the reason I no longer support the green  ‘go back’ arrow in this diagram: 

You didn't really explain why you think the system I described wouldn't work. I think you have a certain idea in your mind and think what I'm describing is like that.

There are multiple solutions to the colony building problem (A builds / lands a colony at T1, B arrives faster and builds / lands a colony in the same place at T0). As long as events are placed on the same timeline, the system has the necessary information to prevent any paradoxes. Both A and B can be prevented in building there depending on what you prioritize - first one to get there using in-game time or first one to record there using the mission milestones.

51 minutes ago, pandaman said:

OP actually wants is a continuous 'recording' of each mission that can be rewound to any point, without affecting any other missions happening at the same time.

Yes, main timeline gets copied to mission timeline (and updated if needed), mission milestones are recorded and then at the end of the mission you can choose if you add then to the main timeline or just discard the recording. Any conflicts can be solved either by asking players for input or automatically.

Think of it like Git, guys. Git works, it doesn't cause any paradoxes.

[OHara]

26 minutes ago, Vl3d said:

Think of it like Git, guys. Git works, it doesn't cause any paradoxes.

Git is a good analogy.  `Git merge` highlights conflicts between branches, and helps the user to resolve those conflicts (analogously to what you suggest just above).  

In discussions of multiplayer with time-warp, people often use the term 'paradoxes' to describe conflicts between timelines that  evolved independently when  want results from both timelines saved in the same save-game.   

The mods Luna Multiplayer and FMRS resolve conflicts in simplistic ways, which doesn't bother users of the mod because they generally don't create conflicting timelines.

In FMRS, we often launch a 2-stage rocket from Kerbin, put the second stage in orbit, then jump back in time to land the booster.   If I wanted to be evil, instead of landing the booster I could use its remaining fuel to crash into the second stage and destroy it before it gets a chance to reach orbit.  FMRS has to resolve the conflicting timelines: is second stage destroyed or not?  (For this case, the second stage is restored in orbit when I return-to-space-centre after the crash, but maybe other cases force FMRS to resolve in a different way.)

[Nazalassa]

3 minutes ago, OHara said:

Git is a good analogy.

[Pthigrivi]

1 hour ago, Vl3d said:

You didn't really explain why you think the system I described wouldn't work.

I think it might be possible, maybe, if instead of being able to go back an arbitrary amount of time and change things you could only go back to after something was last edited by someone else. In any case its likely not feasible and it’s definitely overcomplicated. I think its pretty unlikely that they’ll add stock mechjeb at all, and if things may or may not work players will interpret that as random failures, which the devs have said they’d like to avoid. Its the same reason they probably won’t use a mechjeb solution for supply routes. There’s just a much simpler and more reliable way to accomplish the same goal. 

Edited February 12, 2023 by Pthigrivi

[Penoso]

19 hours ago, Vl3d said:

If you want to plan a rescue mission instead of reverting without recording the milestones to the main timeline, it's your choice.

You can’t revert in multiplayer neither load previous saves.  For example, player B docked to your ship and refueled his ship.  Latter you revert your misson, what happen to the fuel player B got?

[Penoso]

Another problem I can see.

How would you interact with other players if you will never be at the “present” at the same time.

For example:

You play a mission to Duna which takes 300 days. Go back and are running another mission in parallel.

Player B see your Duna ship while it is in Kerbin orbit, before your Duna transfer burn. Player B want to interact with your Duna ship. What happen?

a) It is impossible to interact (what is the point to play multiplayer if you can’t interact)

b) You can interact and the game erases all your 300 days in the future that you have already played (which would be frustrating to toss all that played hours in the trash)

 

[Vl3d]

1 hour ago, Penoso said:

You can’t revert in multiplayer neither load previous saves.  For example, player B docked to your ship and refueled his ship.  Latter you revert your misson, what happen to the fuel player B got?

This thread is not about multiplayer. Also, all interactions in multiplayer should require approval / consent. Otherwise it's sabotage.

Edited February 12, 2023 by Vl3d

[t_v]

1 hour ago, Penoso said:

a) It is impossible to interact (what is the point to play multiplayer if you can’t interact)

Option b isn’t happening, and people are generally ok with option a, as the current multiplayer mods have a similar level of non-interaction. There are a few other systems that prioritize being able to interact if you dig though the dumpster fire of the Multiplayer Discussion Thread, but on the whole, interaction shouldn’t be expected to happen automatically in multiplayer. 

12 minutes ago, Vl3d said:

Otherwise it's sabotage.

i like being sabotaged surprised by the kind actions of my peers

[Bej Kerman]

11 hours ago, Pthigrivi said:

Best solution is to have time move in one direction and just run concurrent missions with alarms and switch from vessel to vessel to execute burns as they come up.

This is time consuming and also exceedingly boring. As many tangles as this solution might have, it's worth being able to run many missions simultaneously without having to wait so long to see the payoff of your missions.

[BigStar Aerospace]

This idea would be perfect for console too since we don't really have to ability to download mods. Meaning I wouldn't have to constantly switch between two missions that are supposed to arrive at different times at different places but being ran at the same time (it's very exciting, but very tiring and troublesome). I hope the devs choose to implement this feature as soon as they implement interstellar or science/career mode...

[Penoso]

On 2/11/2023 at 2:13 PM, Vl3d said:

You're confusing terms: having information about the future and acting accordingly in the present is not called a causality paradox, it's called planning.

There are no paradoxes when there's a single timeline with milestones caused and recorded by you.

And even if it was multiplayer - the information related to one player's recorded milestones would not be shared with another player. So information about the future doesn't really leak.

Even if you could only send only information across time you can cause all sorts of causality paradoxes.

Imagine travel back in time and telling yourself the winning lottery numbers.

Talking about Kerbal, how your system would prevent such exploit like the example I gave (sending a rescue mission before the kerbals got lost?)

Other example: you send a probing mission that goes many places and detect ore in one specific location. You come back in time and send a mining mission to explore exactly that location, with all the information about deltaV, orbital maneuver etc. You can arrive this second mission in the mining spot before the probing mission even detected the ore (supposing the probing mission travel to a lot of places). This is a huge exploit. How to prevent that?

[Penoso]

3 hours ago, Vl3d said:

This thread is not about multiplayer.

Knowing that Kerbal 2 will be a multiplayer game, your system has to work in multiplayer.

3 hours ago, Vl3d said:

 Also, all interactions in multiplayer should require approval / consent. Otherwise it's sabotage.

But suppose you want to give the consent (because you are willing to help, or get a trade with him, or whatever your motive) then you will trash all your hours played to have that interaction?

[Pthigrivi]

4 hours ago, Bej Kerman said:

This is time consuming and also exceedingly boring. As many tangles as this solution might have, it's worth being able to run many missions simultaneously without having to wait so long to see the payoff of your missions.

Well it takes the same amount of player time, it's just broken up differently. I personally like to do lots of missions at the same time because it makes missions to Jool feel so epic and I don't mind hopping around. But I don't begrudge players who feel differently. It's just a personal playstyle difference. I think the game really needs to let players play either simultaneously or sequentially depending on their preference, but I don't see why it would be worth it to create a bunch of temporal headaches so that players could do both. I mean if you're going back in time then you're going to wait for the payoff anyway. Boom events are already solving the core issue,  because your population grows based on what you've explored rather than the clock. So if you set up a colony on the mun all that matters is that your outputs are in the black and you can timewarp a few days or a 2 years and nothing bad happens. The clock only really matters for vessels en-route, and each player can decide for themselves how much of that they want to manage at a time. If you want to have concurrent missions you do concurrent missions. If you want to do them sequentially do them sequentially. All that changes is the calendar date. 

Edited February 12, 2023 by Pthigrivi

[Bej Kerman]

1 hour ago, Pthigrivi said:

Well it takes the same amount of player time, it's just broken up differently

How it's broken up isn't something that doesn't matter. Sequential missions leave my space center unutilized and parallel missions can make you wait a very long time to see the payoff of a mission.

For the record, I did read your entire reply. This was just the noteworthy thing I chose to comment on because it's what the debate pivots on.

[Vl3d]

2 hours ago, Pthigrivi said:

All that changes is the calendar date. 

That's a big change if you're also working with life support and space races.

[Snafu225]

2 minutes ago, Vl3d said:

That's a big change if you're also working with life support and space races.

How? The duration of a mission and the irl time to do that mission doesn't change. It's all the same just in different order.

[mattinoz]

11 hours ago, Nazalassa said:

Late Merge?

[Pthigrivi]

5 hours ago, Vl3d said:

That's a big change if you're also working with life support and space races.

LS isn't really a problem here. If you can gather what you need to keep colonies supported they're just going to top off the tanks and stay stable. If vessels require LS (and I hope so) those aren't really an issue either, because in theory you've packed what you need for your journey. This is the same whether you're doing a dozen missions at once or one. The space race issue is more subtle. You've suggested a system in which players can go back in time and augment and revise missions they've already run, and you'd like both or several players to be able to do this. You probably don't realize this but you've created an inevitable stalemate-grind senario. There is no way to resolve a space race with retroactive causality, because each player or team in a losing position can continue to go back in time and revise or augment until they beat the winning team or player, and then that team goes back and does the same, and so on and so on. The team or player who wins the space race is not the team who executed the best and fastest plan, but the player or team who refuses to quit in an endless chain of recursive edits. Kudos to them for perseverance I guess, but its not really a recipe for good gameplay. (And if this doesn’t sound like a problem watch the movie “Primer” like 3 times.)
 

This is a general problem with Rube Goldberg solutions to problems that have simpler answers: they spawn additional problems that must be solved with yet more overcomplicated solutions, which themselves require fixes and on and on it goes. This is why I don’t particularly like kerbal classes either, because its a bad solution to the problem that creates more and more player busywork the more you try to fix it. So Im not saying parallel sequential missions with recursive casualty is fundamentally impossible, Im saying its a deeply inefficient solution to the problem. 

Edited February 13, 2023 by Pthigrivi

[Pthigrivi]

7 hours ago, Bej Kerman said:

How it's broken up isn't something that doesn't matter. Sequential missions leave my space center unutilized and parallel missions can make you wait a very long time to see the payoff of a mission.

This might sound harsh, but I don’t mean it so. If you are playing in an unrealistic way you might have to accept that there are unrealistic consequences. I, personally, believe KSP is at its heart an expansive, creative, unpunishing game and no particular playstyle should be ruled out by the games mechanics. Some folks say they knew KSP2 was in good hands when Nate said he’d played 2000 hours. I knew it was in good hands when they described how boom events drive population growth, because its an incredibly efficient and elastic mechanic that allows for so many ways of playing. Pace matters in terms of resource collection and maybe reactors burning through fuel and snacks being gobbled but the player has full control over colony growth and how many and how long each mission takes. In this way players are able to set their own pace, and growth is based not on the calendar but on how far you’ve explored. So yeah, if you build a self sufficient colony on Minmus and then you launch a probe to Jool and time warp all the way there your Minmus colony is going to top off all the resources you’re collecting, but nothing bad will happen. Because its self sufficient there’s no harm in underutilizing it. No biters are going to come chew through everything you’ve built. Thats just a choice based on how you’d like to play and there’s nothing wrong with that. 

Edited February 13, 2023 by Pthigrivi

[Vl3d]

2 hours ago, Pthigrivi said:

You've suggested a system in which players can go back in time and augment and revise missions they've already run

I have never suggested this. I told you that you have a certain idea in your mind and you're projecting it here.

First of all I'm talking about space races vs AI here, not PvP multiplayer.

I suggested only doing a mission then saving it's milestones to the main timeline, after which you would return to right AFTER that mission was launched (if you choose to). No editing missions you already completed.. because that would probably reset the recording and you would have to redo it. Also you can do that using quickload.

And for multiplayer, like i said in a previous post.. you could have construction time, resource requirements and also a certain real world timer to prevent users doing the same mission 100 times just to get better results.

It seems to me you're finding problems just to have arguments why "it can't be done". Trust me, it can be done.

Edited February 13, 2023 by Vl3d