Kerbal Space Program 2: Episode 5 - Interstellar Travel

[The Aziz]

1 hour ago, InfernoSD said:

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.

elaborate algorithm: tell the spacecraft to launch within dark blue area of the mission planner. There are some variations in travel time, DV requirements (in this case, transfer + orbit insertion never exceeds much more than 1700m/s), launch/arrival dates, but as long as your rocket has enough fuel, it should do it without problem. Just let it pick the best spot, just like TWP always does. Then repeat and look for next window after this time frame ends. Kerbal universe is forgiving, transfer windows don't end after day or two so you miss the opportunity to launch, as you can see. It is impossible to replicate a flight even a single time, but if we give the computer some margin which it can operate within, I see no problem.

1 hour ago, InfernoSD said:

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.

How to replicate? Look at the Kerbin - Minmus - Mun - Duna system from above. Repeat when all are more or less in the same positions relative to each other. As pointed out above. You can get very similar result with little differences in delta v. Problem with Minmus is that it orbits Kerbin once every ~50 days, so you literally have one shot at this per optimal Duna transfer window. And you probably may need to pack a bit more fuel in case it goes slightly suboptimal. (so, let the game look for a window to launch with bigger margin) I've been using KSPTOT for a time, and while it takes some time to calculate possible options for gravity assists (as I usually look for interplanetary transfers, not help from the Mun for example), and me being obviously slightly inaccurate with my maneuvers, I always get my things right, even if my fuel usage rises by few percent because I need a correction here and there. All of this is doable if you let the game calculate it.

The difference between automated supply runs and flying on full MechJeb autopilot from start to end, is that the game picks the launch date, not the player.

[InfernoSD]

So it sounds like your desire is for the game itself to plan its own supply route?  This enters strange territory for me. Might as well trim the fat and allow the player to assign any supply route without having to fly it himself first, because the automated route will not resemble his initial journey anyway.

[t_v]

28 minutes ago, InfernoSD said:

So it sounds like your desire is for the game itself to plan its own supply route?  This enters strange territory for me. Might as well trim the fat and allow the player to assign any supply route without having to fly it himself first, because the automated route will not resemble his initial journey anyway.

1 hour ago, The Aziz said:

Repeat when all are more or less in the same positions relative to each other. As pointed out above. You can get very similar result with little differences in delta v.

So, what do you mean "resemble" ? There seems to be a big misunderstanding going on here, because you are both arguing for the same thing and yet against each other. To me, it seems that when @The Aziz shows the Transfer window Planner tool, it indicates that during a transfer, there is an area of time around that transfer that results in the same outcome (in this case Kerbin to Duna low orbit) with a bit of leniency in the locations of the planets with roughly the same mission requirements (less than 1679 dV). This doesn't mean that supply routes will pick an optimal route no matter what you do, it means that supply routes will be able to mimic your route even if planets are in slightly different positions. If you choose to go outside of a transfer window, the algorithm might change the start date by a few days (I'd say 8 at most in each direction) towards optimality, but not half a year. 

3 hours ago, InfernoSD said:

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.

This is exactly what @The Aziz is proposing - something that alters the route for changes in planetary position. Let's take the Minmus - Kerbin - Duna route. Minmus won't be at the same position in its orbit when Kerbin and Duna line up matching the original run, but if you wait 15 days, Minmus will be within 15-25 degrees of its position in the original run, and the route can adapt and thus run - the exact time to wait can be calculated with a transfer planner like the one above. So once again, I think you are both effectively asking for the same thing but with different wording. 

[Pthigrivi]

Something to keep in mind is that the whole point of the supply routes is to reduce grind by reducing the amount of time spent babysitting these things. Generally speaking the system that requires the least ongoing fuss and maintenance for the player is probably the best. Thats what you're optimizing for. I think its fun to do the first run to set things up, but after that you kinda just want to click "repeat on similar windows" and have it plot out the launch and arrival dates. Maybe you can tweak them or tell it to send them a certain number times and then stop, but the more time you're in there manually fiddling with launch schedules the less time you're doing things that are fun. 

Im also betting the game is going to be better than we are at solving for optimal transfers. If we were to put that in porkchop-terms that means our good but sub-optimal test run could be shown as a series of egg-shaped contour regions of the graph, and any future transfers would need to fall within those regions. When you initiate the supply run it would default to the lowest possible dV, or better yet the shortest travel time, but you could manually tweak it within those regions if you wanted. In the end though because we're not going through the fuss of end-to-end modeling the delivered goods would simply match your demonstration run each time.

Edited April 27, 2022 by Pthigrivi

[darthgently]

2 hours ago, Pthigrivi said:

Thats what you're optimizing for. I think its fun to do the first run to set things up, but after that you

Jumping in here..yes, overall I agree, but wouldn't it be cool if you can manually override an automated supply route just as a one-off once in a while, to break things up a bit?  I know I would.  Like maybe my next KAC alarm is a few days off and rather than warp to it, I just manually do a rover supply run between bases on Moho that is normally automated just for the heck of it.  I mean, why not?  It is a game right?  And maybe to make it interesting, if you can do it more efficiently than you did it before, maybe it makes future automated runs that much more efficient or something.  I don't know, a lot of possibilities for future releases anyway

[Pthigrivi]

1 hour ago, darthgently said:

Jumping in here..yes, overall I agree, but wouldn't it be cool if you can manually override an automated supply route just as a one-off once in a while, to break things up a bit?  I know I would.  Like maybe my next KAC alarm is a few days off and rather than warp to it, I just manually do a rover supply run between bases on Moho that is normally automated just for the heck of it.  I mean, why not?  It is a game right?  And maybe to make it interesting, if you can do it more efficiently than you did it before, maybe it makes future automated runs that much more efficient or something.  I don't know, a lot of possibilities for future releases anyway

Yeah thats what mean about the 'egg shaped region' on the porkchop graph--you can select anywhere within that window and still be approved because everywhere in that window uses the same or less dV as your previous run, certainly with a few days. It creates an interesting choice for players; they can chose to tightly optimize the flight which gives them greater efficiency on future runs, or brute-force it a bit and get more flexibility and maybe shorter turnarounds. There might be a better solution but it seems like the best of both worlds to me. 

Edited April 28, 2022 by Pthigrivi

[darthgently]

5 minutes ago, Pthigrivi said:

Yeah thats what mean about the 'egg shaped region' on the porkchop graph--you can select anywhere within that window and still be approved because everywhere in that window uses the same or less dV as your previous run, certainly with a few days. It creates an interesting choice for players; they can chose to tightly optimize the flight which gives them greater efficiency on future runs, or brute-force it a bit and get more flexibility and maybe shorter turnarounds. There might be a better solution but it seems like the best of both worlds to me. 

A few months back I started a topic in KSP 2 suggestions that was very related to manually running supply runs that would be automated based on that manual run and could be redone to get better efficiency and such.  I hope a mechanism like that eventually emerges because striving for efficient runs is such common theme in KSP gameplay

Edited April 28, 2022 by darthgently

[InfernoSD]

3 hours ago, t_v said:

So, what do you mean "resemble" ?

Just that I would be disappointed if I flew a mission one way and the game algorithmically decided to fly it another way.

I will admit that I don't have much familiarity with TWP or mechjeb, and so it's possible that the task of autopiloting between planets as laid out above is easier than I give credit for. So let's go with that assumption, that KSP2 will have a functional autopilot than can complete the entire task of take-off, orbit, hohmann transfer, and precision landing. This still leaves us with an immense number of questions to be answered.

1. What if my mission doesn't begin by entering orbit, but instead continues thrusting away from Kerbin? Can the autopilot differentiate between these different types of missions. Will it know the correct time to take off?
2. Opposite that, what if my mission ends by going directly to landing, instead of orbiting first? Does the autopilot have a way of recognizing this different type of outcome? Can the algorithm always reach that precise landing spot, even if it's on the far side of the planet?
3. What if I use aerobraking to land? Some landings will inevitably be more difficult than others. To compensate for heat, or to control where I land, I may need a different angle of attack from one flight to the next. Will the autopilot figure this out on its own?
4. If I make multiple passes through the atmosphere to slow down, will the autopilot do the same?
5. What if I use any other form of transfer that isn't a hohmann transfer? Can the autopilot perform a simple high energy transfer? Would it recognize that this is not necessarily dependent on being in a transfer window?
6. If my mission used 10 separate burns just to transfer out of Kerbin, does the autopilot then plan a route with 10 manuevers? Can it plan that many steps?
7. Is the autopilot capable of plotting a course if I use a third body somewhere in my route? If I decide to burn 500 dV in Kerbin's SOI and 500 dV in Mun's SOI, will the autopilot do the same? What happens with some of these immensely more complicated trips like you get when you travel to Jool's moons?
8. Say the autopilot recognizes that I passed by the Mun on my way to Duna. Will it assume from that that that route must also pass by the Mun, even though it was just incidental? How will it know the difference?
9. What if I'm using an ion engine that requires solar power for thrust? Will the autopilot know to look ahead and check whether the vessel will be in shadow?
10. What if my mission activates different engines at different times, as opposed to a conventional staged approach? Will the autopilot know to do a 180 and fire up the front rockets during one part of the journey?
11. What if the mission incorporates driving with wheels?
12. What if it incorporates flight?

I'm only scratching the surface here. Not that these are questions for you to answer, but that they would need to be solved by Intercept. To me it seems like an impossible thing to code or even to design, but maybe I'm small-minded.  All of these questions have bearing on fuel effiency, meaning that if the autopilot could not replicate the player's actions, it may result in a failed mission. I don't want to belabor this any further, so I'll make this my last post on the subject.

[Vl3d]

Nate: https://screenrant.com/nate-simpson-interview-kerbal-space-program-2/

"There is a much wider variety of resources that you can harvest. We even have a system that lives alongside the colony system that's called delivery routes, and what it allows you to do is automate resource collection and resource transfer missions that start and end at a colony. So, if I want to just go dig up some stuff somewhere with a specialized drilling vehicle, and then bring it back to a colony? Once I return to the colony, I can make that a delivery route. And then I will continue to receive that amount of that resource in perpetuity, and I can move forward to go find other stuff. Similarly, when I'm transferring resources from one colony to another, I can automate those kinds of missions as well."

"...if you go dig up some rock somewhere and bring them back to a colony, you can automate that mission. If you've gone to a new place that has a new kind of rock on it, then feel free to bring it back and automate that mission."

[shdwlrd]

9 hours ago, InfernoSD said:

Just that I would be disappointed if I flew a mission one way and the game algorithmically decided to fly it another way.

I will admit that I don't have much familiarity with TWP or mechjeb, and so it's possible that the task of autopiloting between planets as laid out above is easier than I give credit for. So let's go with that assumption, that KSP2 will have a functional autopilot than can complete the entire task of take-off, orbit, hohmann transfer, and precision landing. This still leaves us with an immense number of questions to be answered.

1. What if my mission doesn't begin by entering orbit, but instead continues thrusting away from Kerbin? Can the autopilot differentiate between these different types of missions. Will it know the correct time to take off?
2. Opposite that, what if my mission ends by going directly to landing, instead of orbiting first? Does the autopilot have a way of recognizing this different type of outcome? Can the algorithm always reach that precise landing spot, even if it's on the far side of the planet?
3. What if I use aerobraking to land? Some landings will inevitably be more difficult than others. To compensate for heat, or to control where I land, I may need a different angle of attack from one flight to the next. Will the autopilot figure this out on its own?
4. If I make multiple passes through the atmosphere to slow down, will the autopilot do the same?
5. What if I use any other form of transfer that isn't a hohmann transfer? Can the autopilot perform a simple high energy transfer? Would it recognize that this is not necessarily dependent on being in a transfer window?
6. If my mission used 10 separate burns just to transfer out of Kerbin, does the autopilot then plan a route with 10 manuevers? Can it plan that many steps?
7. Is the autopilot capable of plotting a course if I use a third body somewhere in my route? If I decide to burn 500 dV in Kerbin's SOI and 500 dV in Mun's SOI, will the autopilot do the same? What happens with some of these immensely more complicated trips like you get when you travel to Jool's moons?
8. Say the autopilot recognizes that I passed by the Mun on my way to Duna. Will it assume from that that that route must also pass by the Mun, even though it was just incidental? How will it know the difference?
9. What if I'm using an ion engine that requires solar power for thrust? Will the autopilot know to look ahead and check whether the vessel will be in shadow?
10. What if my mission activates different engines at different times, as opposed to a conventional staged approach? Will the autopilot know to do a 180 and fire up the front rockets during one part of the journey?
11. What if the mission incorporates driving with wheels?
12. What if it incorporates flight?

I'm only scratching the surface here. Not that these are questions for you to answer, but that they would need to be solved by Intercept. To me it seems like an impossible thing to code or even to design, but maybe I'm small-minded.  All of these questions have bearing on fuel effiency, meaning that if the autopilot could not replicate the player's actions, it may result in a failed mission. I don't want to belabor this any further, so I'll make this my last post on the subject.

You have a bunch of valid concerns. But Intercept never said that physical crafts would be running these missions. The original flight is considered proof that it could be done. After that, the resources are transferred on a schedule related to you original flight. It's the easiest way to create a resource transfer system without having to consider all the minute details of doing an actual mission. There is no need to spawn an asset with that method.

I maybe wrong, but this is the best solution to the infinite number of ways to do a mission. I personally don't like this method, but it makes sense in the ease of getting it working.

Intercept may surprise us, but from everything that has been said in the subject, it looks like everything will be abstracted after the mission proof is done.

[MechBFP]

2 hours ago, shdwlrd said:

You have a bunch of valid concerns. But Intercept never said that physical crafts would be running these missions. The original flight is considered proof that it could be done. After that, the resources are transferred on a schedule related to you original flight. It's the easiest way to create a resource transfer system without having to consider all the minute details of doing an actual mission. There is no need to spawn an asset with that method.

I maybe wrong, but this is the best solution to the infinite number of ways to do a mission. I personally don't like this method, but it makes sense in the ease of getting it working.

Intercept may surprise us, but from everything that has been said in the subject, it looks like everything will be abstracted after the mission proof is done.

This is my belief as well. The complications of trying to do it otherwise is an extreme time-sink and adds very little to the gameplay. That time could be better spent on almost anything else, frankly. 

[Guest]

On 4/28/2022 at 7:22 AM, InfernoSD said:

Just that I would be disappointed if I flew a mission one way and the game algorithmically decided to fly it another way.

I think there's a misunderstanding on the purpose of the system, the automation here is needed to have a more complex resource system without having to manually fly every single supply run.

Any other solution implies to completely remove manually flying from the equation or oversimplify the resource system (one magic ore that can be mined everywhere).

Finding a way to gather a valuable and rare resource from Eve to bring it to your Gilly refinery before sending the resulting goods to Kerbin for a profit is a good flying and designing puzzle, expendable parts of the Eve lander will need their own supply lines to be constructed, maybe built on Duna with resources mined on Duna, Ike and partially imported from Kerbin.

Such a complexity would make flying everything manually a chore, and make the game a micromanaging hell, I'd love to design, build and fly that Eve lander and miner, especially if I have constraints given by what fuels and parts I can build and use to make that specific craft, but after flying it a couple of times the fun part of that gameplay is exausted, I just want it to be a "x resource/day" value in my production table for the refinery, so I can use that resource in my next mission.

Even the most abstracted system in which it's just all magical resource transfer after you prooved the route is going to allow for a more complex system, more spread in the resource placement and, by consequence, more different missions to fly and design specialized crafts for.

And, if you actually like repetition you can just continue to improve the existing routes by iterating on the design and trying to shave a bit of overhead from the recorded transfer.

Edited April 29, 2022 by Master39

[GigFiz]

I think one other relevant factor needs to be accounted for, and that's processing footprint. So this sounds like a potentially pretty important system here and, considering we will be eventually working at an interstellar level, so how many of these supply routes are we going to be setting up? A few? Dozens? Hundreds? I think the devs have to be thinking about the scenario of what happens when you reach say...triple digits. At that point, what would be the hit of simulating these vs just checking that some criteria are met and changing some numbers (also, what are the odds of being in range to see a delivery, especially when you start to have a bunch of stations/routes/bases, etc. The cost/benefit of actually simulating it doesn't seem worth it). 

Also, there are kinda two subcategories here as well: surface to base and base to orbit vs interplanetary and up with planet to moon kind of somewhere in between. On the surface, timing is a non issues, and even orbit windows and lunar transfers are extremely consistent and predictable and take the same delta-v (And I would imagine if you move the base or station, I would guess you have to redo a run (or maybe even have that be a changeable difficulty setting thing even)). When you get to the next level, that's where it starts to get wibbly. Have they actually said supply runs would be able to be automated going interplanetary, even? It seems like that would be a much lower priority, not even because of complexity, but because of frequency: having your mining rig going back to base twice a day and then sending a supply ship to orbit twice a week is going to get tedious really fast, but even a Kerbin <-> Duna Supply route will take several years for a round trip. That's a whole lot less micromanaging than the lower scale possibilities (and actually, at that point, fully simulating it is no longer as big a processing sink, because you (well...probably. This is KSP after all) won't have hundreds of ships going to Duna. But in general I would wonder if interplanetary stuff will be automatable.

My question, I think, is: how is refueling the supply ships going to be handled? Surface stuff is easy, just gotta have power, but it doesn't matter how efficient or not your ascent and transfers are if you don't have a way to refuel. So this implies that there could be a prerequisite for unlocking supply routes of having a viable refinery and supply chain set up first, otherwise you would be able to skip a big game requirement. Which is nice, it's a natural system of progression of starting small and then building up and giving yourself the capacity for bigger and more complicated supply chains

 

Edit: I understand why interplanetary supply runs are desirable. I just asked, with the extra layer of complexity there, if they had firmly said if they are implementing it up to that scale or not.

Edited April 30, 2022 by GigFiz

[t_v]

Due to this I personally think that if you are able to see supply runs, they will only be visual as a bit of polish. There’s no real practical reason to make an algorithm that can go anywhere just for the purpose of having it run in the background. Visuals are pretty much all you’ll experience, and sometimes not even that. As for the question of why supply runs interplanetary are important, there are lots of reasons. The biggest one is transferring materials that you can’t get within the system that you have to import from other planets. For example, when setting up a colony that isn’t big enough yet, you might need shipments of kerbals to get to that critical population and you don’t want to ferry 500 kerbals 10 kerbals at a time. Or, if the game is designed properly, planets won’t have every resource on them and to get massive supplies of hydrogen fuel, you will probably need to export it from a gas giant. Stuff like that. 

[Vl3d]

6 hours ago, t_v said:

There’s no real practical reason to make an algorithm that can go anywhere just for the purpose of having it run in the background. Visuals are pretty much all you’ll experience, and sometimes not even that.

Not sure about that. You should see ALL vessels flying in map view and be able to switch to them in case of emergency. Maybe you need a cargo rocket to save another mission. Improv.

Edited April 30, 2022 by Vl3d

[InfernoSD]

On 4/29/2022 at 1:38 PM, GigFiz said:

(also, what are the odds of being in range to see a delivery, especially when you start to have a bunch of stations/routes/bases, etc. The cost/benefit of actually simulating it doesn't seem worth it). 

Agreed, it's pretty low odds. The player would need to have foreknowledge of a supply run and make a conscious effort to travel and time warp there. In my opinion, it would only make sense while managing a colony. I think it would be worth it for the purpose of making colonies look alive. The colony view could have a little calendar in the corner of the screen to let you know when the next launch or landing was scheduled, so the player could easily warp to see it for theirself. 

On 4/29/2022 at 1:38 PM, GigFiz said:

Have they actually said supply runs would be able to be automated going interplanetary, even?

I don't see that they have said that anywhere. But the tediousness of making ten repeat mining missions is no worse than the tediousness of making ten repeat interplanetary shipping missions. I think it will be a necessity, especially if some resources can only be collected from specific planets. 

On 4/29/2022 at 1:38 PM, GigFiz said:

how is refueling the supply ships going to be handled?

Presumably when a supply run completes you'll get a report like "-400 Liquid Fuel, +1000 Ore". I imagine a small fuel refinery will be one of the first things you build in every colony.

What if it's not a round trip, though? Then I imagine your starting colony will have "-800 Metals" and your destination colony will have "+800 Metals". It's likely that I will make a lot of one-way trips to move resources around, and if Metals are a resource, that may require some management as well.

[Grimmas]

On 4/28/2022 at 5:37 PM, shdwlrd said:

You have a bunch of valid concerns. But Intercept never said that physical crafts would be running these missions. The original flight is considered proof that it could be done. After that, the resources are transferred on a schedule related to you original flight. It's the easiest way to create a resource transfer system without having to consider all the minute details of doing an actual mission. There is no need to spawn an asset with that method.

I maybe wrong, but this is the best solution to the infinite number of ways to do a mission. I personally don't like this method, but it makes sense in the ease of getting it working.

Intercept may surprise us, but from everything that has been said in the subject, it looks like everything will be abstracted after the mission proof is done.

This is the only sane way to do it, from the perspective of conserving limited CPU and GPU cycles. This is not Distant Worlds, we do not need or want a full simulation of an NPC economy to run in the background. They are probably going to make it very similar to how USI WOLF works today.

[isamu]

Does anyone by chance know if KSP 2 will feature FTL technology?  I know they mentioned exotic resources which let them explore experimental technology for propulsion but didn't really extrapolate on that.  Or do we think no it won't since they appear to have gone out of there way to allow for the time to speed up far beyond KSP 1 time warp?  And if yes to FTL, do we think there will be multiple engine types or do we think just one?  I also couldn't find anything relevant in the threads but I'd guess I'm not the first so I apologize in advance if I missed it.

[shdwlrd]

16 minutes ago, isamu said:

Does anyone by chance know if KSP 2 will feature FTL technology?  I know they mentioned exotic resources which let them explore experimental technology for propulsion but didn't really extrapolate on that.  Or do we think no it won't since they appear to have gone out of there way to allow for the time to speed up far beyond KSP 1 time warp?  And if yes to FTL, do we think there will be multiple engine types or do we think just one?  I also couldn't find anything relevant in the threads but I'd guess I'm not the first so I apologize in advance if I missed it.

No FTL, wormholes, star gates, jump gates, or any other forms of quickly moving between stars.

[Grimmas]

Given how scale worked in KSP, we can probably also expect scaled down galaxies... I expect the nearest star system would be less than a lightyear away. And since we can now burn during timewarp it won't take that long to get there. FTL will be left for the realm of modders.

[PopinFRESH]

I've tried to search for this on the forum but haven't been able to find if there is a consolidate thread about it.

Spoiler

Is there a thread about the hidden binary audio images at the end of the Videos? I'm wondering if each episode is additive to the same image or if these are a sequence of images?

If anyone can point me in the right direction I'd appreciate it. 

[The Aziz]

You could look for "karecibo" but in essence every part added more to the image and it's most likely that it's already complete.

[PopinFRESH]

1 hour ago, The Aziz said:

You could look for "karecibo" but in essence every part added more to the image and it's most likely that it's already complete.

Thanks @The Aziz 

[Ryaja]

On 5/17/2022 at 10:57 PM, The Aziz said:

it's most likely that it's already complete.

Or that's just what they want us to think...

[Willeos]

Hello, I really liked the background music in this episode 5. Does anyone know if it's music from the future game or something else? I would like to know the titles if possible.