Support for MIRVs

[Yakky]

I recently designed a rocket outfitted with 32 mini "fire and forget" science probes. Each probe had a small rocket pack for separating from the mother ship, a parachute to survive re-entry, a control unit, some solar panels, and some basic science and radio instruments. My plan was to put lots of mini-science stations all over Kerbin with a single launch. In Cold War parlance, this technique was called Multiple Independent Re-entry Vehicles, or MIRVs for short. (The idea back then was to nuke many targets with one missile.) But in my case it was all in the name of science!

I launched the rocket up very high on a sub-orbital trajectory, jettisoned all 32 probes (after activating their parachutes and rocket packs), and then sat back to wait as they all re-entered and landed on various random places on Kerbin. See cool pics:

The launch vehicle with 32 probes attached:

The cool-looking re-entry trajectories of the probes after separation:

Great idea in theory, but some of you probably know what happened next. KSP doesn't preserve objects that re-enter too far away from whatever vehicle has the focus. Most of the probes simply vaporized upon re-entry and/or impact, even though they all had active parachutes. Only the very few that I actually shifted the focus to, and tracked live through touch-down, were preserved.

I understand the computational challenges of tracking so many objects, but is there a way that they could be preserved? Here's my suggestion: Compute the atmospherics, at least in a basic way, for any object that has a command node (i.e. it has a manned capsule or an unmanned remote/robotic control node built into it) as something that has to be preserved and computed all the way through re-entry and touchdown. Spent boosters and other debris don't meet this criteria and can be safely vaporized. Presumably only the "important" bits will have command nodes attached to them. In general, people won't bother sticking command nodes on things that aren't important.

Alternately, when you have a non-focus object that is about to impact an atmosphere, pop up a dialog that asks people whether it should be calculated or not. Or at least pop up the dialog if said object has a command node in it. MIRVs could be fun!

[Sirrobert]

In order to do that, they'd need to stimulate physics for each craft. Seeing as the game lags out bad when you have to much parts to simulate, permanently simulating everything would be a BAD idea. Maybe we'll eventually get a way to not simulate it entirely, and only when in atmosphere, but right now, nope.

There is a mod that extends the simulation range to 100km, you could try that.

[Tex_NL]

In order to do that, they'd need to stimulate physics for each craft. ...

Not exactly. Read back to what Yakky said: "Compute the atmospherics, at least in a basic way, for any object that has a command node ...", "... pop up a dialog that asks people whether it should be calculated or not". The way I read it he suggests to let drop debris de-orbit just the way it is currently doing but ask if the physics for craft should be calculated.

There is a mod that extends the simulation range to 100km, you could try that.

I think you mean the romfarer.dll pugin.

[DancZer]

What if he not separate the vehicle to multiple smaller? The part count is same as before and after separation isn't it? Why would be more laggy the game if they calculate multiple vessels simultaneously? I think simulation scale factor is great a opportunity of the game. Maybe some part of the game they should make in OpenCL.

I like your idea Yakky.

Edited November 26, 2013 by DancZer

[peadar1987]

Can't mechjeb calculate the landing position of a body taking into account atmospheric drag? Perhaps it could be made so you could designate parts as probes, and if they have enough parachutes (1 chute/ x units of mass), they get placed on the ground at the calculated position.

[Yakky]

I think you mean the romfarer.dll pugin.

Thanks... I'll try that. BTW it was a bit laggy during launch because the vehicle had over 400 parts.

Another possible approach: Use some clever calculus integrals to derive a closed-form analytic solution, so that no iterative calculation is needed. Given the planet's size, the gravity, the atmospheric density gradient, the speed and angle of atmospheric entry, the vehicle's mass, and an approximation of its drag coefficient, I bet someone with math skills (or math software) could come up with the integrals to determine where it would be, and how fast it would be going, at any point in time. Is this what mechjeb does? Or if not, any mathy KSP fans want to come up with a mod using this technique?

Anyway, all fun and interesting stuff.