Jump to content

New booster recovery strategies


Vl3d

Recommended Posts

I saw the video below and I wonder what would we need in KSP2 to be able to implement creative new reusability and recovery strategies (while not having to do it manually every time)?

The example below means having parachute strings that can be hooked and also automation for helicopter flights with an autopilot for atmospheric intercept of the falling booster.

Some kind of multi-vessel coordinated autopilot would also be necessary for boosters landing on a drone ship.

There's also the mechazilla tower to catch a landing booster. That would require.. precise landing and the actual tower with arms.

Any other ideas?

Edited by Vl3d
+
Link to comment
Share on other sites

If we ever get robotics like the Breaking Ground DLC (Specially large ones) then anything is possible. 

If it will be automated and trully reusable... that's another story that we don't know.

Link to comment
Share on other sites

Any serious space program uses more than one computer/human operator to cooordinate movement of multiple vessels at the same time. You probably could set up a stage to control its descent somewhat, but to catch it mid air, you'd need either an advanced ai (that reads positions, velocities of itself and falling stage, and acts accordingly) which is most likely impossible, or take control on your own.

Link to comment
Share on other sites

11 minutes ago, The Aziz said:

Any serious space program uses more than one computer/human operator to cooordinate movement of multiple vessels at the same time. You probably could set up a stage to control its descent somewhat, but to catch it mid air, you'd need either an advanced ai (that reads positions, velocities of itself and falling stage, and acts accordingly) which is most likely impossible, or take control on your own.

Or you know, could just put a bunch of chutes on the  booster and get the staging to enable the chutes during the decoupling

Link to comment
Share on other sites

3 hours ago, Vl3d said:

I saw the video below and I wonder what would we need in KSP2 to be able to implement creative new reusability and recovery strategies (while not having to do it manually every time)?

All we'd need is a stock implementation of FMRS so we can land a booster and revert back to the orbital stage just after boost sep. Anything else isn't necesarry.

3 hours ago, Vl3d said:

The example below means having parachute strings that can be hooked and also automation for helicopter flights with an autopilot for atmospheric intercept of the falling booster.

The accomplishment aspect would wither away if this was only handed to autopilots. Like any other aspect of the game, this is something you can get good at with practice.

3 hours ago, Vl3d said:

Some kind of multi-vessel coordinated autopilot would also be necessary for boosters landing on a drone ship.

Again, not necessary. Landing a booster isn't this kind of impossible feat that necessitates autopilot - like any other difficult but localised challenge (Runway speed record, Mun colony landing) you can do this with 30 minutes of free time and some trial and error.

3 hours ago, Vl3d said:

I think any serious space program should have a way to simultaneously coordinate more than one craft for a mission.

FMRS

Link to comment
Share on other sites

20 minutes ago, siklidkid said:

just put a bunch of chutes on the  booster and get the staging to enable the chutes during the decoupling

Yes, but that's abstracting recovery away. There is a lot of creativity left on the table. Building a multi-craft system that works together for a mission is much more rewarding, even if you do it manually once and then automate it like suggested by @Bej Kerman

14 minutes ago, MechBFP said:

This highly depends on if recovery has a practical purpose in the game or not. We have no idea what the economy of the game is like yet.

Totally agree, but I would love to have a mass production economic model that works with more complex mission profiles, not just stages. Especially if we can do it co-op and then automate it (I would prefer it not just be abstracted away, at least recorded and visible).

32 minutes ago, The Aziz said:

You probably could set up a stage to control its descent somewhat, but to catch it mid air, you'd need either an advanced ai (that reads positions, velocities of itself and falling stage, and acts accordingly) which is most likely impossible, or take control on your own.

Agree, answers above expand on this. I just don't know what solutions the devs preferred...

Link to comment
Share on other sites

Great video and idea. Stage recovery is a tricky question, mainly because we don't know much about how adventure mode/career will work. Like is stage recovery similar to what we have now--just a fun challenge for players to prove that they can?--or is it structurally incentivized by the game? We also don't know to what degree or in what style automation might be integrated. For instance its been bandied around quite a bit here that in order to establish a supply run you'll need to run a kind of 'proof' mission that would establish the kind of delivery vessel and incur similar costs, maybe also taking into account transit dVs to keep things fair, but none of that has actually been confirmed by Intercept. It may just be that resources are somewhat magically transported from base to base and the transit time and shipping costs are calculated behind the curtain. 

I mention this because how that is handled probably has implications for how stage recovery might be handled. For instance you might need to demonstrate recovery for a booster and then be able to automatically recover that booster if it was attached to future vessels as a subassembly. If so players could devise whatever Rube Goldberg strategy they liked to demonstrate the proof, and it would just be considered repeated any time that subassembly was dropped. Or it might be more like the StageRecovery mod where you just need sufficient chutes to drop it to a safe speed or sufficient remaining dV to land itself (theoretically) and then its automatically considered recovered. Both paradigms are exploitable, so in the end no matter what you do there's going to be a certain honor system involved. I think a lot of it comes down to how clear expectations can be given to the player and how simple or onerous it is for players to interface with the recovery process. Theres going to be an optimum point where holding players feet to the fire to give clear goals and avoid exploits is outweighed by complicated stipulations that waste player time. 

Edited by Pthigrivi
Link to comment
Share on other sites

1 hour ago, Pthigrivi said:

Great video and idea. Stage recovery is a tricky question, mainly because we don't know much about how adventure mode/career will work. Like is stage recovery similar to what we have now--just a fun challenge for players to prove that they can?--or is it structurally incentivized by the game. We also don't know to what degree or in what style automation might be integrated. For instance its been bandied around quite a bit here that in order to establish a supply run you'll need to run a kind of 'proof' mission that would establish the kind of delivery vessel and incur similar costs, maybe also taking into account transit dVs to keep things fair, but none of that has actually been confirmed by Intercept. It may just be that resources are somewhat magically transported from base to base and the transit time and shipping costs are calculated behind the curtain. 

I mention this because how that is handled probably has implications for how stage recovery might be handled. For instance you might need to demonstrate recovery for a booster and then be able to automatically recover that booster if it was attached to future vessels as a subassembly. If so players could devise whatever Rube Goldberg strategy they liked to demonstrate the proof, and it would just be considered repeated any time that subassembly was dropped. Or it might be more like the StageRecovery mod where you just need sufficient chutes to drop it to a safe speed or sufficient remaining dV to land itself (theoretically) and then its automatically considered recovered. Both paradigms are exploitable, so in the end no matter what you do there's going to be a certain honor system involved. I think a lot of it comes down to how clear expectations can be given to the player and how simple or onerous it is for players to interface with the recovery process. Theres going to be an optimum point where holding players feet to the fire give clear goals and avoid exploits is outweighed by complicated stipulations that waste player time. 

Totally agree, great post.

Best in my mind is to do it manually once by being able to go back to a save point and control multiple craft as if simultaneously with a kind of progressive record and playback.

But the recording should be done by key actions and playback by autopilot, to allow improvisation in dynamic conditions. This way the recording could also be editable and you could actually see your vessels repeat the mission independently. Of course you would have to leave enough fuel for the autopilot to redo the key actions.

Sure, it's complicated and needs multiple systems, but it would be very cool and useful to create complex multi-vehicle missions and it would encourage building a larger variety of utility craft (drone ship, transport helicopter, catch tower.. whatever you can imagine).

I don't like the magic easy method: to just abstract everything away and change the resource numbers. That's lazy and it sucks.

Link to comment
Share on other sites

If for fun (as we do here) we imagine ourselves in the developers shoes I think first we have to ask: what are we trying to achieve? We can then order things from needs to wants and consider the cost benefit of different methods from a practicality standpoint. Im not a programmer but I can guess a bit between whats hard, what’s really hard, and whats basically impossible. There’s also the level of onus and management placed on the player to consider.

For me the only thing that’s absolutely necessary for the game to function is that landed parts are recoverable for some portion of their value. Everything else is a bonus. For things that land the value curve could be rejiggered but distance from KSC or another launch site like in KSP1 works fine. But what about dropped stages? Lets look at some wants:
 

1) Stages that fall from physics range can be recovered.

2) Recovered stages should be checked for survivability. 

3) Recovery proximity to launch sites should be factored.

4) Recoverability can be tested by the player and applied to matching subassemblies in the VAB for reuse. 

5) Stages are equipped with autopilot that makes recovery testing easier. 

6) Multiple vessels can autopilot based on player defined instructions.

7) Players can retroactively reverse time to manually guide multiple stages and vessels


Now to narrow things down Id say almost nobody really wants to manually babysit every stage to a precise landing location on each launch. Ideally this would feed into a proof of concept launch that would produce values that could be applied to subassemblies in the VAB.  For the sake of testing this could be pretty simple: what was the max altitude of subassembly x, and what was the recovery value. This could even be tested in isolation the way SpaceX did by launching and recovering falcon 9s before strapping them together. And you could apply whatever wacky idea you wanted for this so long as the subassembly was recovered, it could just show up in the VAB thereafter with a marker: “Recoverable for 90% if separated on Kerbin below 50km.”

Now, as we get later into wants 5-7 things get a bit more complicated. Maybe there are reasons why stock automation would be included anyway, but even that has levels between maintaining angle to horizon and hovering to full-on Autoland. If you want the game to take the wheel and pilot vessels to a destination you’re in all the way. Its not just a recording, because its not like your separation altitude and velocity are going to exactly match. And then there’s the player management factor—specifying land locations manually for each detached stage and hoping they survive the journey. And to be honest, if the point here is to just incentivize recoverable stages do you really need to model every instance and worry about them all the way to a (hopefully successful) automated recovery? Either from a programming or player management standpoint?

Edited by Pthigrivi
Link to comment
Share on other sites

4 hours ago, Pthigrivi said:

if the point here is to just incentivize recoverable stages do you really need to model every instance and worry about them all the way to a (hopefully successful) automated recovery? Either from a programming or player management standpoint?

If you can see it, then yes it should not be fake or abstracted. It's KSP2: millimeter resolution of light year spanning volume. I think they can manage with some basic key actions recording automation. We're not in KSP1 territory anymore.

I agree we should manage our expectations to not be disappointed, but there are certain standards imposed on a game of this scope and target audience. 

Comparison: In a racing game you would expect the other cars to have good AI. It's mandatory, not optional. Otherwise you would just have time trials.

Link to comment
Share on other sites

If the code to simulate a craft model is separated from the code to display/view/operate the craft, then running it on multiple craft simultaneously is neither hard nor expensive.  Given that there will be few craft in a recovery trajectory.  (Not counting suborbitals which can stay on rails until summoned, just as now.)

Two arguments for doing this:

  1. not all recovery works;e.g. mountainous landings.  It would be interesting to replay the final moments for diagnosis/improvement;
  2. those who play by ASR (Air/Sea Rescue) rules are required to journey to the crash site to effect the recovery.  (Otherwise why have planes?  Helos.  Subs.  Etc.)
  3. 2b. Eve multi-stage to orbit benefits from stage recovery
Edited by Hotel26
Link to comment
Share on other sites

1 hour ago, Vl3d said:

Comparison: In a racing game you would expect the other cars to have good AI. It's mandatory, not optional. Otherwise you would just have time trials.

And yet, here we are, with Gran Turismo 7, in a year marking 25th anniversary of the franchise, with AI as stiff as it was in GT1.

Link to comment
Share on other sites

Stage recovery is an excellent opportunity for cooperative multiplayer.

I use recoverable first stages all the time, with Kopernicus as my only mod (scaling up the system, not worth it on smaller systems). I've made reusable 1st stages for Eve ascent vehicles (stock 1x scale Eve, with breaking ground robotics).

It would be a lot easier if I didn't have to have a flight profile that requires switching between stages, with enough time for the 2nd stage to achieve orbit and for me to switch back to the 1st stage before it gets too deep into the atmosphere.

Link to comment
Share on other sites

I've considered a first stage that has ISRU capability for Eve, Tylo, etc.  It gets the 2nd stage and payload on its way, lands again, then makes more fuel to launch itself into orbit where it reunites with the 2nd stage and payload and is off to the next world

Link to comment
Share on other sites

8 hours ago, darthgently said:

I've considered a first stage that has ISRU capability for Eve, Tylo, etc.  It gets the 2nd stage and payload on its way, lands again, then makes more fuel to launch itself into orbit where it reunites with the 2nd stage and payload and is off to the next world

The funny thing is that it is almost pointless for Eve. You would think it would make a big difference, as your landing stage could be empty of fuel and simply mine all the fuel it needs, but in reality the ship has so much dry mass as a result of all the fuel tanks, engines, etc, that the fuel is almost negligible to the overall mass, and your initial Kerbin launcher still ends up needing to be massive.

Link to comment
Share on other sites

16 hours ago, MechBFP said:

The funny thing is that it is almost pointless for Eve. You would think it would make a big difference,

As he described, yes, but with a purely suborbital 1st stage, it can be a massive bonus.

Also, my first stages have no ISRU. I have a ISRU rover for that.

It works as a system for getting mass to or it of eve, but not as a "go anywhere in the solar system" system.

The abstraction if ksp2 should focus on getting tons of resources to orbit via supply lines, accounting for reuse.

That should require demonstrating a flight with recovery. The payload vs resource cost is calculated, and those are the fees for sending supplies to an orbital depot/destination.

No automation of flights, just abstraction of resource transfer after proof of concept flights

Edited by KerikBalm
Link to comment
Share on other sites

I've been thinking about how complicated this would be but I don't think its that bad so long as the test values were applied to subassemblies. First you do a simulation of your flight with stages attached and dump them as you need to, noting the altitude. Then you fly the stage by itself above that, return for the best recovery you're able to and in the recovery screen select "validate stage". Then that recovery data (rated staging altitude + recovery value) are just applied to that subassembly whenever you launch from that location in the future. Validating supply runs would be more complicated than that, because they could be one way, round trip, or include 3 or more stops. I would think the logic is the same. When recovering the vessel you could select "validate supply run" and the vessel would receive a dV rating + recovery value, and all of the transfers it made could be repeated using the mission planner when similar trip dVs are available.  Because this would have implications for colonial trade you'll also need input/output resource graphs for each colony and station that anticipate these transfers and other resource harvesters and consumers and let you know if you're still in the green and what your buffers are or need to be.  Its interesting because you can make it really complicated if you want to, but its not reliant on all that fussy belting and logic gates like Factorio-like games use.

Edited by Pthigrivi
Link to comment
Share on other sites

18 hours ago, Pthigrivi said:

I've been thinking about how complicated this would be but I don't think its that bad so long as the test values were applied to subassemblies. First you do a simulation of your flight with stages attached and dump them as you need to, noting the altitude. Then you fly the stage by itself above that, return for the best recovery you're able to and in the recovery screen select "validate stage". Then that recovery data (rated staging altitude + recovery value) are just applied to that subassembly whenever you launch from that location in the future. Validating supply runs would be more complicated than that, because they could be one way, round trip, or include 3 or more stops. I would think the logic is the same. When recovering the vessel you could select "validate supply run" and the vessel would receive a dV rating + recovery value, and all of the transfers it made could be repeated using the mission planner when similar trip dVs are available.  Because this would have implications for colonial trade you'll also need input/output resource graphs for each colony and station that anticipate these transfers and other resource harvesters and consumers and let you know if you're still in the green and what your buffers are or need to be.  Its interesting because you can make it really complicated if you want to, but its not reliant on all that fussy belting and logic gates like Factorio-like games use.

And a  KSP equivalent of the standard intermodal container, that would cut off a lot of repeated validation flights.

"This rocket can bring 10 containers to orbit" is way better than flying it 4 times to demonstrate how much iron, copper, supplies and monoprop it can carry each time.

Link to comment
Share on other sites

21 minutes ago, Master39 said:

And a  KSP equivalent of the standard intermodal container, that would cut off a lot of repeated validation flights.

"This rocket can bring 10 containers to orbit" is way better than flying it 4 times to demonstrate how much iron, copper, supplies and monoprop it can carry each time.

Tried doing that in KSP1, it's very good idea. In practice, it's a royal pita. My method of true intermodal containers did rely on actually moving containers around. What was I thinking? KSP doesn't make anything like that easy.

It would have been much easier if you were able to easily change the cargo around instead of the actual containers. Again, without mods, that was impossible.

I'm hoping that Intercept will make cargo hauling easier by not needing specialized craft for each item in the game. Or needing to physically move containers around.

Intermodal containers would be a boon for KSP2 just how they are in RL. Just make them easier to deal with.

Link to comment
Share on other sites

1 hour ago, Master39 said:

And a  KSP equivalent of the standard intermodal container, that would cut off a lot of repeated validation flights.

"This rocket can bring 10 containers to orbit" is way better than flying it 4 times to demonstrate how much iron, copper, supplies and monoprop it can carry each time.

Yeah great point. Maybe contents are interchangeable so long as you don't exceed the rated mass? And what about fuel deliveries? I like being able to fuel-switch different tanks but I'd expect some of the more exotic fuels would need more specialized containers. How complicated is too complicated? It's probably hard for us to guess from here. 

Although in the dev videos they're still showing what look like interchangeable storage containers strapped to big vessels. Seems like these might do the job for everything but fuel. 

Edited by Pthigrivi
Link to comment
Share on other sites

24 minutes ago, Pthigrivi said:

Yeah great point. Maybe contents are interchangeable so long as you don't exceed the rated mass? And what about fuel deliveries? I like being able to fuel-switch different tanks but I'd expect some of the more exotic fuels would need more specialized containers. How complicated is too complicated? It's probably hard for us to guess from here. 

That's what you would have to do. It's just a matter of knowing at what altitude your booster dies out and planning for that. So planning and setting up your launch vehicle at the maximum weight possible, you should be set for anything weighing less. (There's always overkill, but none of us are guilty of that. :sticktongue:)

Link to comment
Share on other sites

×
×
  • Create New...