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

[Vl3d]

34 minutes ago, Snafu225 said:

Vl3d: do you guys realize that we might be getting AI controlled space agencies and space-race gameplay right from the start of Early Access?

It's possible. It would be incredibly cool.

34 minutes ago, Snafu225 said:

Maybe I'm misunderstanding it but it would look like this?

Mission A: Events 1-15 are happening -> Final ingame time: 3y

Mission B: Events 1-10 are happening -> Final ingame time 2y

etc add however many we want, now they all get recorded. Now I jump back into time to do my really long interstellar. 

And now everything  recorded and saved somewhere/somehow (haven't come up with a way to do it) gets projected onto the mission.So do I tell that system that it has to record now or is it supposed to record all the time until I hit the button to jump back? How do I queue multiple timelines and how would you tell the system that now it's go time?

You do mission A: events A1 .. A15 are recorded. You end mission A at year 3 and return to the start time T-A. Events A1 .. A15 get placed on the main timeline M.

M now has events: [A1 .. A15]

Let's say 2 minutes pass (so T-B = T-A plus 2 minutes) and you start mission B and complete it at year 2.  During this time the events A1 .. up to An (max year 2) take place. You return to the start time T-B. Events B1 .. B10 get placed on the main timeline M.

Main timeline M now contains events: [A1 .. B1 .. A7 .. B10 (year 2) .. A15 (year 3)]. A and B events are interlaced.

Remember you are now at time T-B on M.

You start the interstellar mission C. Same mechanic. During your C mission all events of missions A and B take place.

The system records everything during missions and every time you start a new mission the M timeline gets copied to the mission timeline. When you return to mission start the recorded events get added to the M timeline (if you choose to; you can also choose to discard the mission recording and just reset time to mission start).

So there is only 1 timeline at any point in the game. There are no time travel paradoxes. M gets copied and recorded mission events are added to M when you return to the mission start time (if you don't discard the recordings).

If you choose not to return to the mission start time, then you stay in the future and everything up to that point that was on M has taken place, including the mission events. Future events will take place as recorded on M.

Edited February 6, 2023 by Vl3d

[Snafu225]

Got it.
So as I said, I think one option could be to use the delivery route system, as it is most likely deep rooted into stock KSP2 but to be honest, this feels like a long time until the delivery route system gets implemented and we have literally no clue how it's going to work (on a technical level) and only a vague idea how it could work gameplay wise.
Performance wise I'd say this could be the safest route.

Edited February 6, 2023 by Snafu225
fumbled and posted 2 words at first :D

[Vl3d]

2 minutes ago, Snafu225 said:

I think one option could be to use the delivery route system

It's very possible that the delivery route system is based on the recorded events mechanic. Delivery routes is another thing that becomes possible using this timeline-recordings thing, next to space-races and rewinding and other stuff.

[daninplainsight]

I'm not sure I'm understanding how this system would handle causality conflicts. For example, suppose you're doing a rescue mission to rescue some Kerbals stranded on Duna. You record mission A as a rescue, where you leave Kerbin, use a Hohmann transfer at the appropriate window, rescue your Kerbals, and then return to Kerbin orbit before reverting to when you first started your mission on the main timeline. Then you decide, oh, I probably could have used this torch ship that was already in orbit around Kerbin, so in mission B you leave Kerbin orbit before mission A and arrive at Duna after only a few days but then botch the landing and kill all of the stranded Kerbals instead of rescuing them. How would the game be able to handle reconciling differences? How would the recording of Mission A respond? Would the game force you, as the player, to choose which sequence of events is preferred?

[Vl3d]

14 minutes ago, daninplainsight said:

I'm not sure I'm understanding how this system would handle causality conflicts. For example, suppose you're doing a rescue mission to rescue some Kerbals stranded on Duna. You record mission A as a rescue, where you leave Kerbin, use a Hohmann transfer at the appropriate window, rescue your Kerbals, and then return to Kerbin orbit before reverting to when you first started your mission on the main timeline. Then you decide, oh, I probably could have used this torch ship that was already in orbit around Kerbin, so in mission B you leave Kerbin orbit before mission A and arrive at Duna after only a few days but then botch the landing and kill all of the stranded Kerbals instead of rescuing them. How would the game be able to handle reconciling differences? How would the recording of Mission A respond? Would the game force you, as the player, to choose which sequence of events is preferred?

Slow rescue mission arrives at Duna, finds the dead kerbals, returns empty.

Ideally when there is an interaction the craft uses the recorded milestones but adapts to the task mechjeb style.. so you would have the recorded events be: get to this Duna orbit, land here, return to Kerbin. It's up to you as a craft to get it done with what resources you have onboard. If you don't have enough delta V or monopropellant or something breaks your solar panels during the mission.. well then the mission probably fails. There's no guaranteed success after interaction. The simulation works in the background for all craft during the main timeline current time. And the main timeline gets copied to the current mission timeline. So there are no causality conflicts.

It's single player.. everything that happens is your fault.

Edited February 6, 2023 by Vl3d

[daninplainsight]

4 minutes ago, Vl3d said:

There's no guaranteed success after interaction.

I'm not sure that's a desirable outcome for the users to find themselves in. Say a new mission A was the flight of a mothership that stopped to refuel at an orbital depot along the way to Jool or something, where it spawned off missions B, C, D as landers, science satellites, etc., which the user records after completing all of them. Then they reverted to the start of mission A, and a utility drone in mission E drained the fuel depot before mission A got to it. It sounds like that would simply cause A-D to fail. It would probably make players, even experienced ones, very angry, because I think that's something a lot of us could just do accidentally. For me, it would garner a similar response as if the game told me it had corrupted my save file and I had to redo the last 6 hours of gameplay.

[Vl3d]

7 minutes ago, daninplainsight said:

Mission E drained the fuel depot before mission A got to it. It sounds like that would simply cause A-D to fail. It would probably make players, even experienced ones, very angry, because I think that's something a lot of us could just do accidentally. For me, it would garner a similar response as if the game told me it had corrupted my save file and I had to redo the last 6 hours of gameplay.

Just go back to mission E and don't drain the fuel. Or refuel it before A arrives.

Edited February 6, 2023 by Vl3d

[daninplainsight]

7 minutes ago, Vl3d said:

Just go back to mission E and don't drain the fuel. Or refuel it before A arrives.

How will the user know when they've caused a paradox? Will they know when they've caused it? Like they'll get a notification: "You just caused the mission recording for vehicles A, B, C, D to break, be sure to meet X condition before time T or their recordings won't continue"? Or not until the recording fails?

[Vl3d]

27 minutes ago, daninplainsight said:

How will the user know when they've caused a paradox? Will they know when they've caused it? Like they'll get a notification: "You just caused the mission recording for vehicles A, B, C, D to break, be sure to meet X condition before time T or their recordings won't continue"? Or not until the recording fails?

That's not a paradox actually. That's just causality.

You don't have enough fuel for the mission because you took it out.

Yes you could get notifications and the mission could pause until all original requirements of the recording are met. Or it could just fail. I don't care how it's done, that's up to play-testing. I care about the overview of the system.

Edited February 6, 2023 by Vl3d

[linuxgurugamer]

The one thing you are ignoring is, define an "event".  What do you think an "event" is?  Is it the completion of a milestone?  Is it a launch?  Is it a single second of time?

You are throwing ideas out which have no real thought behind them, it just seems to be your wish list.  And while it is conceivable that all of the ideas are _possible_ , the time and effort needed to do these ideas is expensive, borh in tim and money

[Vl3d]

13 minutes ago, linuxgurugamer said:

You are throwing ideas out which have no real thought behind them

Spoiler

 

13 minutes ago, linuxgurugamer said:

The one thing you are ignoring is, define an "event".  What do you think an "event" is?  Is it the completion of a milestone?  Is it a launch?  Is it a single second of time?

Ideally an "event" (I use milestone interchangeably, though milestone is a better word to use) is an end-goal, a result. Like "get to this specific orbit around Duna by starting a burn at this time". It would get parsed when it's triggered by a mechjeb like sub-system that finds a solution taking into account the limitations of the craft (example: how much deltaV it has / needs for the mission). This way the craft can "adapt" to changes in its state to try to complete the goal. If it cannot find a solution, it fails (by running out of fuel for example) or notifies the player.

I did not say it's easy to program. I can't define the details of how it should be implemented in 2 days. This is a system that needs other sub-systems for it to work.

Edited February 6, 2023 by Vl3d

[daninplainsight]

27 minutes ago, Vl3d said:

I don't care how it's done, that's up to play-testing. I care about the overview of the system.

I'm asking these questions because I don't think your idea would even make it off the drawing board without them getting answered first. I like the basic concept because I think it'd be great for me to timewarp my first interstellar mission to arrival and not have hundreds or thousands of years pass back in the Kerbolar system, but allowing the user to go back in time without effecting future events that have already been defined is very difficult to even make work outside a few simple cases, where future events can't reasonably be effected by past ones.

6 minutes ago, Vl3d said:

This is a system that needs other sub-systems for it to work.

However this is implemented, if it's going beyond fairly simple, limited cases, it would have to be baked in from the start of development. More than just needing some subsystems for this to work, almost all subsystems would have to be designed with this in mind for them to function correctly, and we have no indication that they've planned a feature like this. Obviously, no evidence that this is planned isn't evidence that they're not planning this, but this is big enough I feel like they might have mentioned something about it by now.

We know they're planning on allowing milkrun missions/trade routes to be automated, but we don't even know if that means that we'll see ghosts in the game of traveling cargo ships, or if we'll just get resources periodically deposited.

I will grant you that this may be able to piggyback off whatever the devs have planned for implementing time streams in multiplayer. They've said that they've architected the game around making it multiplayer-friendly and that may include unconventional timestreams, but there's no way to know until the devs say something.

[Vl3d]

7 hours ago, daninplainsight said:

However this is implemented, if it's going beyond fairly simple, limited cases, it would have to be baked in from the start of development. More than just needing some subsystems for this to work, almost all subsystems would have to be designed with this in mind for them to function correctly, and we have no indication that they've planned a feature like this.

It's one of the fundamental systems needed for in-space multiplayer. The whole game was architected from the beginning with multiplayer in mind. Actually in multiplayer it would be even easier to implement because you would block P2P interactions by making craft pass-through without docking approval. The delivery routes system and the single player usages I came up with are derivative.

I've been saying this for a long time: KSP2 is multiplayer. Multiplayer is the essence of KSP2.

Edited February 7, 2023 by Vl3d

[pandaman]

15 hours ago, Vl3d said:

 

I've been saying this for a long time: KSP2 is multiplayer. Multiplayer is the essence of KSP2.

Nope, sorry, I strongly (and respectfully) disagree.  The essence of KSP2 is the same as KSP1,  which was always intended primarily as a single player game that needed 3rd party mods (and resulting funky work arounds) to give it MP functionality.

That said, stock MP is certainly a nice, and very welcome, addition that will enhance it for many.  And I am looking forward to trying it out with my kids.

[linuxgurugamer]

Where did this idea that "rewinding time" would be a part of the game?  Multiplayer can be done in many different ways, none of which will require rewinding time.

There's a reason many games don't have a rewind ability.  These "events"  you are talking about is really everything that happens to every single vessel during this time.  The amount of data to be collected and stored is huge.  Managing it, and then "rewinding" it would be an extremely difficult task, prone to issues which everyone will then complain about

[darthgently]

Poor man's rewind:. Quicksave

[Vl3d]

The devs mentioned a number of times that multiplayer is a fundamental part of the design architecture of the new game and that making multiplayer work was THE most challenging feature of the game.

Not one of, but "THE central technical challenge of this game was the overhaul of the architecture that is required to facilitate multiplayer" (Nate, Purdue Space Podcast, 38:00).

I cannot emphasize this idea enough. IMO KSP2 is fundamentally built for multiplayer, but will also allow single player DRM free gameplay.

[pandaman]

On 2/7/2023 at 5:32 PM, Vl3d said:

 

I cannot emphasize this idea enough. IMO KSP2 is fundamentally built for multiplayer, but will also allow single player DRM free gameplay.

Unlike KSP1, multiplayer was intentionally 'designed in' from the start.  But I think it's more likely the opposite way around to what you think.  If MP was the main focus it would be much earlier in the EA roadmap IMO. 

[Vl3d]

45 minutes ago, pandaman said:

If MP was the main focus it would be much earlier in the EA roadmap IMO. 

No, because when MP is released then 1.0 launches.

Edited February 8, 2023 by Vl3d

[mattinoz]

On 2/7/2023 at 6:32 AM, Vl3d said:

 

There are no different branches. There's just the main timeline current time and the mission time. That's it. Events get recorded during the mission and get added to / placed on the main timeline. As time advanced the events of the main timeline take place.

The system is theoretically functional and allows for a lot of new cool gameplay mechanics.

Why not have different branches and just use one of the commonly available versioning systems to run it?

It looks like GIT anyway so why not use those tools. Solves the transport issues of remote low interaction multiple players by using a well known system and game can then concentrate on close and live multi-player interactions in game. 

Ok so you need an editor that stops the merging with the main timeline to cause a paradox but in theory that could be as simple as blocking merges that paradox the timeline. Add say a system to that allows a contract to be issued in the past that solves the paradox if completed. or the player gets reverted to last stable position in their branch. I call it ground hog day mode.

Crash and brake something "its Groundhog Day again" and you find yourself back before last burn or change in sphere of influence. 

Yes I'm a big fan of this idea. Let me plan by the seat of my pants. In the same way KSP wanted us to fly by the seat of our pants, crash, rinse, repeat, learn, laugh. 

Edit to add:

Would love full "momento" mode ie have scenarios with say a capsule in reentry to KSP splashdown with 3 kerbals and bunch of science data on board from Mun or Duna or such and have to work backwards to put the mission together. Make great forum content as people post speed or efficiency runs.

 

Edited February 9, 2023 by mattinoz

[Snafu225]

8 hours ago, Vl3d said:

No, because when MP is released then 1.0 launches.

No, because when MP is released it is considered feature complete thus 1.0.

The fact is at the very end is most likely, as mentioned plenty of times, due to it being the one of the most complicated things to implement and polish. They probably want to have all other big updates in place, working and balanced before releasing MP

[Lowi_Sace]

On 2/1/2023 at 7:45 PM, Vl3d said:

This system allows for massive gameplay expansion.. like stage recovery, having single player space races against an AI controlled agency and rocket construction time passing in the stock game.

agree, This would really add a lot to the game. I would still want to be able to timewarp the game normally to the future (maybe because needing science/recourses from ongoing missions). For interstellar, auto-resupply and multiplayer this would also be great. 

The problem you might run into is when the craft interacts with other missions. Probably is hard to make is autocorrect. A solution for this is if they do not show the autocorrect, but the mission will fail if you push it to much deltV ofcourse (like dependend on the amount of deltav in feul tanks

[Penoso]

On 2/1/2023 at 3:45 PM, Vl3d said:

I propose a third:

3. Parallel-sequential missions. A good way to play I think would be to finish a whole mission then go back in time and continue with other missions from the moment you launched. Recorded mission milestones would be added to the main timeline. And the science points would come in the future, thus respecting the timeline.

I think this would be useful for space races also, because I'm that case the timeline is very important and you can't really time warp because you're losing opportunities to launch more missions. So there's a lot of freedom to be gained by being able to go back in time. But from a gameplay perspective it's also very useful for the flow of the game to be able to focus on a single mission and finish it.

This system allows for massive gameplay expansion.. like stage recovery, having single player space races against an AI controlled agency and rocket construction time passing in the stock game.

Not to mention multiplayer (see multiplayer thread)!

Later edit:

Interaction with the craft could be feasable without resetting the recorded events timeline from that point onward if we have mechjeb-like automated control using milestones.

The craft (or capable subassembly in case of separation) would just try to adapt and continue with the mission even if crippled or modified. If the physics simulation doesn't allow it to be successful (not enough Delta V for example of broken solar panels) then.. yes it would fail.

That’s not a good ideia, because it allows for causality paradox.

You could fly a mission to Duna and have some kerbals lost in space at the end of it.

Then you just go back in time and launch a rescue mission for that kerbals that arrive exactly the moment the kerbals get lost. It is the most friendly paradox I could think of, but you can exploit it in so many ways that you are gonna break the game (and it would generate a hell of bugs for the developers to deal with).

You are effectively creating a Time Machine, and there is no way the prevent causality paradoxes.

Even the information of knowing that a mission was successful or failed will be enough to influence your decision when you go back in time.

Why will you plan for the next step on your mission to the Mun knowing the first one will crash?

[Vl3d]

2 hours ago, Penoso said:

That’s not a good ideia, because it allows for causality paradox.

You could fly a mission to Duna and have some kerbals lost in space at the end of it.

Then you just go back in time and launch a rescue mission for that kerbals that arrive exactly the moment the kerbals get lost. It is the most friendly paradox I could think of, but you can exploit it in so many ways that you are gonna break the game (and it would generate a hell of bugs for the developers to deal with).

You are effectively creating a Time Machine, and there is no way the prevent causality paradoxes.

Even the information of knowing that a mission was successful or failed will be enough to influence your decision when you go back in time.

Why will you plan for the next step on your mission to the Mun knowing the first one will crash?

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.

[Bej Kerman]

24 minutes ago, 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.

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.