Kerbal Space Program 2: Episode 5 - Interstellar Travel

[Pthigrivi]

4 minutes ago, MechBFP said:

We will have to wait and see. 

For sure. I guess if you can see it that opens a lot of questions. Can you focus on it? Can you take manual control of it? Does it consume fuel or is it just like a dummy object? Once it connects to a docking port is then 'real'? It's this weird aberrant thing in this world. 

[shdwlrd]

2 hours ago, Pthigrivi said:

My main worry with full automation for these deliveries is that a lot of people can travel and land more efficiently than MechJeb can. Now, maybe KSP2 can greatly improve upon that, but if any significant number of players can still do it with less fuel manually you'll have a lot of cases of automated deliveries running out of fuel several hundred meters above the target, or before they're able to zero out relative velocity with a station they're docking to. 

I'm not to worried. The current explanation for automation would be completely abstracted with no physical craft moving around.

My little pipe dream scenario for automation wouldn't work beyond a planet's SoI anyway. You would need a couple static destinations or a destination that you can easily figure out the timing for it to work. So surface to surface, surface to orbit, orbit to surface would be the best uses for it. Every transfer would be very similar so you can set all the parameters and record all the maneuvers and execute them with the same results. But it's my ideal solution, not the one currently suggested be Nate.

[MechBFP]

1 hour ago, Pthigrivi said:

For sure. I guess if you can see it that opens a lot of questions. Can you focus on it? Can you take manual control of it? Does it consume fuel or is it just like a dummy object? Once it connects to a docking port is then 'real'? It's this weird aberrant thing in this world. 

Things like that is why I think it will be fully abstracted. Although it would be amusing if you could do something like crash into an automated ship and ruin the supply run.

[GigFiz]

The video on this thread addresses some of the concerns you guys have been bringing up (I think even automating supply runs gets an offhand mention). It is mentioned that interstellar ships will be too big for even the massively increased VAB size (like, he mentions a single engine that outsizes the whole VAB by itself), and will basically necessitate having orbital dockyards first in order to even build the things, so some progression and infrastructure will be necessary first. Also at the end it's mentioned how they really want the first step into interstellar travel to be a really big moment and something that has been built up to, which seems to imply the build up and progression to get to that point that would create a moment like that.

 

Also, RE: grindiness. Don't forget that in early KSP1 especially, there were none of these systems at all, so if you wanted to do that, you basically had to imagine it and self enforce; really even career mode was a sandbox with progression, you had to provide the impetus and imagination most of the time; even now, outside of the most extensive mods, you still have to do that. So having systems like this in place from day one that you can engage with if you want to (or not, or mod out/mod into something different. which is potentially great because it's easier to modify a system with a mod than build it from scratch) is a pretty big win overall. Even if you end up not loving how they do it, the more robust systems there are in place from the beginning, the more effort modders can put into raw creativity of modifying things, rather than the legwork of adding in systems and processes that they have to build from nothing. 

Edited April 27, 2022 by GigFiz
Added another point rather than a new post

[Vl3d]

I still support vessel automation by using recorded key-frame autopilot actions repeating when travel parameters are optimal.

[Pthigrivi]

5 hours ago, Vl3d said:

I still support vessel automation by using recorded key-frame autopilot actions repeating when travel parameters are optimal.

Me too. I hope it's possible, and they've certainly tackled a lot of other really difficult problems through this whole thing. The thing is every maneuver and transfer is going to come with its own set of dV costs based on the exact time of launch and the position of every body and vessel that's being interacted with along the way. Say you want to set up a supply run from a station above Minmus to a station above Moho. It's not just a mater of mimicking the key actions you took because that exact arrangement of planets and moons might not repeat for centuries. It's basically got to solve for the total journey including any and all inclination burns, rendezvous burns, monoprop usage, LS or reactor fuel use depending on differences in flight duration etc. for each time it does the run to check if its going to run out of something along the way. If it's delivering fuel that it's also consuming that could also result in large differences in the actual delivered quantity each time. 

But like I said, they've solved a lot of hard technical challenges so far, and maybe it's not as hard as I think? Maybe it has to solve for all that anyway and it can just show you green windows on a calendar indicating when you can schedule launches without worry? Thats a more difficult math problem but would probably be easy enough to navigate as a player. 

Edited April 27, 2022 by Pthigrivi

[The Aziz]

Like I said, proper mission planning. If you can get your fuel budget estimate for a mission from A to B, you know what you have to build. And so, my guess is, your automated supply run will have no problem doing any part of the trip as long as the ship's capabilities fit within the estimate. Where it's the usual transfer window but with some obvious error margin. I bet whatever you come up with in the VAB, the game will choose a moment for departure that ensures mission success without running out of resources.

[InfernoSD]

4 hours ago, Pthigrivi said:

that exact arrangement of planets and moons might not repeat for centuries

This is the key issue. A mission launching from Kerbin's surface and landing on Duna's surface could be repeated once every two years. The same arrangement simply does not occur more often than that. What if we launch from the surface of Minmus instead? Or what if we slingshot around another body, as we often do for more fuel-efficient missions? Then the period until that same arrangement occurs may be effectively infinite. This is ignoring that planets rotate, and that they have oval orbits, and that they have moons which tend to get in the way, all of which introduce additional problems for the game to solve. And this is without even getting in to the many creative flight plans players will use, like aerobraking out of an interplanetary transfer.

So I don't see that any version of KSP could ever "solve for" all of the various differences that may arise during an automated flight. What it could do is fake it, but even to fake it would require an immense amount of problem solving. It would ultimately be easier to build an AI that charts its own course to a destination rather than trying to replicate a previous course. And at that point the whole thing is fake, so what is the point? Is it even desirable to allow the player to interact with an automated flight, and if not, why permit them to see it at all?

My current expectation is that automated flights will be abstracted. Maybe put a graphic in the tracking station that displays the progress of current automated missions, where the progress bar uses iconography for Kerbin, the rocket, and the destination. If anything, allow the player to watch them take off and land, which is where keyframes would come in handy.

[Catto]

Action groups and staging have a baby. 

Dynamic staging: Say, you want a cargo bay to open on a certain stage: like stage 2 for example.

On the same stage, you want a payload to decouple, but not at the same time the bay opens.

You can set a timer, for about 3 seconds in this case, before the payload decouples.

And you don't have to stage more than once.

[Vl3d]

7 hours ago, Pthigrivi said:

Say you want to set up a supply run from a station above Minmus to a station above Moho.

You just have to account for the Kerbin-Moho transfer window. I think journeys will have that type of cyclic behavior. It would repeat the transport you did when recorded, with a minimal direct transfer DeltaV requirement. You don't automate cyclic logistic runs using complex slingshots (maybe only using moons). If you try to, it will say "journey parameters will be similar in 100 years". Then you're forced to do another supply run that's more conventional.

1 hour ago, InfernoSD said:

My current expectation is that automated flights will be abstracted.

Abstracted only in deep space, visible at takeoff and landing, yes. But also what I said above: supply runs should be very simple, without fancy slingshots.

You have to optimize for the minimal cycle, not for minimal DeltaV.

Edited April 27, 2022 by Vl3d

[The Aziz]

4 hours ago, InfernoSD said:

A mission launching from Kerbin's surface and landing on Duna's surface could be repeated once every two years.

Or every 5 minutes if you pack enough fuel to deal with not so optimal transfer window on your template rocket. (30k dv or so in the worst case).

4 hours ago, InfernoSD said:

What if we launch from the surface of Minmus instead?

Then that's entirely different supply run requiring different approach. It's Minmus -Duna, not Kerbin - Duna. Hell, even Duna - Minmus is different thanks to the orbital mechanics, all have different maneuvers and fuel requirements. I say different too much.

5 hours ago, InfernoSD said:

Or what if we slingshot around another body, as we often do for more fuel-efficient missions? Then the period until that same arrangement occurs may be effectively infinite.

Using simple logic, if you needed relatively constant flow of resources, would you set up a supply run through a gravity assist of some other body, knowing well that it's a rare occurrence and even if reduces fuel requirement, it's not worth it long term?

For the rest of it, I don't know what's to solve because the solution is right in my previous post here. There's no solving, it's literally reading orbital parameters and acting accordingly. As we've been doing for years manually, except this time it's going to happen before launch, not in the middle of flight (because someone suddenly discovered by the end of a mission that Ike would be in a way, oh my oh dear, if only there was a way to predict it...)

[t_v]

One thing I’ll add to the previous solution is that there needs to be leniency built into the timing. So if you launched to Duna when it was 45 degrees apart from Kerbin, the next transfer window will have them at slightly different altitudes, but the mission can just run the same without worrying about different fuel expenditure. Similarly, if you do a gravity assist off of the Mun while it is facing directly away from Kerbol, this exact arrangement will not come very often, and so a leniency of 15 degrees will be added to the Mun position, so that the mission will run if the Mun is close to the same location, but still not every transfer window. 

[Pthigrivi]

7 hours ago, Vl3d said:

Abstracted only in deep space, visible at takeoff and landing, yes. But also what I said above: supply runs should be very simple, without fancy slingshots.

I think we’re all actually agreeing here. By ‘abstracted’ we mean not continuously modeled with resource flow from end to end. Whether you see it land and take off as a non-interactive dummy vessel is a little easier to deal with but still comes with awkward questions, like what happens if the docking port you used on the proof run is now blocked. 

 

9 hours ago, The Aziz said:

Like I said, proper mission planning. If you can get your fuel budget estimate for a mission from A to B, you know what you have to build. And so, my guess is, your automated supply run will have no problem doing any part of the trip as long as the ship's capabilities fit within the estimate. Where it's the usual transfer window but with some obvious error margin. I bet whatever you come up with in the VAB, the game will choose a moment for departure that ensures mission success without running out of resources.

This is basically what I expect. It might even be possible to have AI do it ‘for real’ from end to end, which would be amazing, the dev team is a lot smarter than I am, but I wont be too disappointed if thats not the solution Intercept ends up going with. 

Edited April 27, 2022 by Pthigrivi

[The Aziz]

2 hours ago, Pthigrivi said:

like what happens if the docking port you used on the proof run is now blocked

Probably getting a notification, "your ship x cannot access the station y" or something, obviously clickable to get right to it and do something about it. With dozens of missions, bases, stations, colonies, all of them active, discovering things, extracting, refining resources, kraken knows what else, I can't imagine this game without proper notification system. We're actually running a space program this time.

[Pthigrivi]

44 minutes ago, The Aziz said:

Probably getting a notification, "your ship x cannot access the station y" or something, obviously clickable to get right to it and do something about it. With dozens of missions, bases, stations, colonies, all of them active, discovering things, extracting, refining resources, kraken knows what else, I can't imagine this game without proper notification system. We're actually running a space program this time.

Totally. But this would be under a paradigm in which the transfer itself is abstracted and resources are just automatically deposited at the mission-planned time of arrival. The ship you see leave and arrive is just a dummy vessel for visual effect with no actual resources on board. As players are going along they might even reconfigure their station and delete the docking port they used on an earlier demonstration run. If the transfer of resources is essentially automatic then there's no real problem with that, except what happens to the dummy vessel? Does it disappear? Dock to thin air? It's not catastrophic or anything it's just a weird situation. 

[t_v]

5 minutes ago, Pthigrivi said:

Totally. But this would be under a paradigm in which the transfer itself is abstracted and resources are just automatically deposited at the mission-planned time of arrival. The ship you see leave and arrive is just a dummy vessel for visual effect with no actual resources on board. As players are going along they might even reconfigure their station and delete the docking port they used on an earlier demonstration run. If the transfer of resources is essentially automatic then there's no real problem with that, except what happens to the dummy vessel? Does it disappear? Dock to thin air? It's not catastrophic or anything it's just a weird situation. 

Ideally, you would be able to decommission old supply routes as your tech improves, so I think that people will decommission missions that landed at an old landing pad or at a port that no longer exists. However, an alternate (albeit annoying) solution is to delete missions that connected to that pad or port, or allow the player to re-do the final approach to a new location. 

[JoeSchmuckatelli]

1 hour ago, t_v said:

allow the player to

Maaan... The tutorials better be Hella Gud!

(B/c this here knuckledragger cannot be trusted to land in the same crater from mission to mission, let alone on a pad!) 

[Pthigrivi]

1 hour ago, t_v said:

Ideally, you would be able to decommission old supply routes as your tech improves, so I think that people will decommission missions that landed at an old landing pad or at a port that no longer exists. However, an alternate (albeit annoying) solution is to delete missions that connected to that pad or port, or allow the player to re-do the final approach to a new location. 

The nice thing about abstracting it rather than fully modeling it is you wouldn't even have to worry about that. It wouldn't care if you'd moved or replaced things because its just being dumped into the storage tanks directly. Fussing with designating docking ports and landing pads only really matters if the game is literally launching a fully modeled vessel thats actually carrying the resources from end to end. That would be cool, cause you could commander them or re-route them and see them buzzing about in a real way, but it might cause headaches too. 

Edited April 27, 2022 by Pthigrivi

[t_v]

45 minutes ago, Pthigrivi said:

Fussing with designating docking ports and landing pads only really matters if the game is literally launching a fully modeled vessel thats actually carrying the resources from end to end. 

Or what I think is more probable, an abstraction that only is modeled when you are actively looking at it, and then only visually, in which case the only reason it matters is just visuals, not the actual result. 

[KSP_linux0191]

@KSPStarIn the video, it said that interstellar travel would be like shooting an arrow at a grape on the moon; did they mean from Kerbin to Mun, or from Earth to Moon?

[MechBFP]

26 minutes ago, KSP_linux0191 said:

@KSPStarIn the video, it said that interstellar travel would be like shooting an arrow at a grape on the moon; did they mean from Kerbin to Mun, or from Earth to Moon?

Since it doesn’t really change the analogy it doesn’t matter. 

[InfernoSD]

13 hours ago, Vl3d said:

You have to optimize for the minimal cycle, not for minimal DeltaV.

Why, though? As a player I would be very irritated by this. The automation system should be designed to automate what the player does, not the other way around. The only way this system interests me at all is if optimization matters. If you take away my ability to slingshot, it's no longer fun.

I know we joke about "more rockets" on this forum, but if the solution to building up a network of colonies in space is simply to send the most rockets as quickly and numerously as possible, then there's no challenge or thought involved, which is not aligned to the spirit of the game.

9 hours ago, The Aziz said:

Or every 5 minutes if you pack enough fuel to deal with not so optimal transfer window on your template rocket.

Sure sure sure, but my point was that transfer conditions will never be perfectly the same again. Therefore there has to be elaborate algorithms to compensate for those changing conditions. Even if you fly in a straight line from Kerbin to Duna, their locations and rotations and the gravitational effects of different bodies will be different every time, and the route has to be altered for those changes.

I think what I'm failing to communicate is that computers are not humans. As humans we notice these differences and adjust for it very easily. For a computer, it would take a very elaborate spiderweb of code to do the same things that we do. As I said above, I think it would be easier to code something that plans its own route than to replicate a preexisting route.

9 hours ago, The Aziz said:

Using simple logic, if you needed relatively constant flow of resources, would you set up a supply run through a gravity assist of some other body, knowing well that it's a rare occurrence and even if reduces fuel requirement, it's not worth it long term?

Well, yes actually, because I like efficiency, but I realize I would not necessarily be in the majority in that opinion.

But there's also no shortage of examples where a supply run would benefit from gravity assist without being a rare occurrence. If we take the Minmus to Duna example, you would want to use the Mun first to bring pe closer to Kerbin, then get the full oberth effect from Kerbin. (I may be wrong, but I believe that is the obvious efficient route to take.) This type of route is not a rare occurrence at all, in the sense that you're speaking of. It could be repeated every transfer window or more often.

The trouble is in telling a computer how to replicate that route.

6 hours ago, Pthigrivi said:

what happens if the docking port you used on the proof run is now blocked. 

Been thinking about this too, although I was considering landing pads rather than docking. I think the only way this would work as desired would be for the player to dedicate a specific docking port or landing pad expressly for the purpose of supply routes. Because you wouldn't want the player to be launching a rocket from the same landing pad that a supply rocket is coming down on. But this could still result in some weirdness if the player manages to block that space anyway. Presumably the supply vehicle dissolves into resources so it doesn't block the next trip.

---

Here's a fun question. Interstellar supply runs, yes or no?

[Barel]

6 minutes ago, InfernoSD said:

Here's a fun question. Interstellar supply runs, yes or no?

In the decades it would take for supplies to reach the system, I’m sure it would be possible to build a decent self-sufficient colony. Otherwise, dad is gonna be gone for milk for a very, very long time 

[Minmus Taster]

28 minutes ago, Barel said:

In the decades it would take for supplies to reach the system, I’m sure it would be possible to build a decent self-sufficient colony. Otherwise, dad is gonna be gone for milk for a very, very long time 

One second kiddo I need to go get something from Debdeb, I will be back soon  

I doubt there will be interstellar supply lines and your just meant to brute-force a colony with at most a few missions.

[Laxez]

25 minutes ago, Minmus Taster said:

One second kiddo I need to go get something from Debdeb, I will be back soon  

I doubt there will be interstellar supply lines and your just meant to brute-force a colony with at most a few missions.

Well... better than nothing... immagine sending  a ship every week for 50 years... is not efficent, but better late than never