Disable deleting vessels in atmosphere...

[MarkTheRabidCat]

With career being a thing, and recovering parts saving you money, it's starting to REALLY REALLY .... me off that I can't set up some parachutes on a piece of debris and let it land on it's own, without some optimisation system arbitrarilly deciding to delete it. It's also bugging me, that the only "fix" that anyone has thought of for this, is to just increase the load distance, which includes object that are otherwise fine on their rails in space. I would just like it if it would just load anything in the atmosphere, either within the current simulation or in it's own, but just load it!

I dunno, maybe even some kind of auto recovery, if debris is going slow enough that it shouldn't get burned to bits, then a quick evaluation of how much drag it would get at the range of atmospheric density, then compute a speed and position curve using basic physics, find it's speed at the parachutes predeploy altitude and if they're not going to rip off or burn off, and are going to fully deploy before it hits the ground, and have enough drag to bring the object below the lowest crash tolerance of the vessel, have it be auto recovered when it should reach the ground!. Then maybe use that to set up a pre determined path so players could still interupt it.

It might not be completely realistic, but as long as you ballence it toward it being more dangerous than normal simulation, it won't feel broken.

Edited May 23, 2015 by MarkTheRabidCat

[Laie]

It may well require considerable effort on part of the player to do it (so as to give people a reason to not care still throw away stuff). But sometimes I do care and I want to recover a certain piece, and I really wish there was a way to pull it off.

[Vectura]

StageRecovery mod does that.

[MarkTheRabidCat]

StageRecovery mod does that.

Link?

[Two]

I would be totally ok if the game would at least just do something simple to check if a part can recovered (complex also, but I read there are technical difficulties?).

For example the game could check if the total mass vs the maximum drag of all parachutes combined would be sufficient to get the craft below 7 m/s, and if that is the case, the "debris" is automatically recovered instead of destroyed. I think that would be a good compromise between calculation speed and gameplay value, with a big benefit for career players. Because currently you are basically forced to build a big, heavy, but recoverable mass of a rocket, which is completely unrealistic.

[amorymeltzer]

Link?

Forum and KerbalStuff. I love it!

[Murph]

It's really not a big problem, I wouldn't care if it never got fixed. On normal difficulty, I really don't need the cash from recovering spent stages, and I don't want complexity added around them to generate lag for the active vessel. I'm also against having lots of spent stages laying around on Kerbin splashed/landed, as I think it would add nothing of value to the game to have to clean up more trash after launches.

If anything is to change, it should be limited to an extremely simple and quick recovery mechanic, without any full physics simulation. Just a trivial yes/no for sufficient parachutes based on mass alone, then immediately recover, no complex physics.

[Guest]

They should be fully simulated (and option for simplified simulation or deletion).

Options are good, single, "best for everyone" solution is worst.

Personally, I don't have too much debris reentering too often.

Discarded first stages and associated parts are falling through the atmosphere while your second (and may be third) stages are still in active phase and so no on-rail time-warp anyway.

Debris, that accidentally hits atmosphere is rare, and inability to enter on-rails time-warp is not game breaking experience, as long as explanation is provided by game.

Actually, steady atmospheric decay from lower orbits, with simplified physics, would be nice debris cleaner. That, of course, raises a question about active satellites, and their ability to re-boost and re-orient themselves without player's intervention.

(Active = probe core powered, optionally SAS engaged)

[dryer_lint]

What really bugs me is how they've extended the physics bubble, but landed debris is still removed. It's landed, for God's sake! No need for a calculation or anything, if it has zero velocity then don't remove it!

[Starwhip]

What really bugs me is how they've extended the physics bubble, but landed debris is still removed. It's landed, for God's sake! No need for a calculation or anything, if it has zero velocity then don't remove it!

It's what now?!

I've never noticed this before.

[Murph]

They should be fully simulated (and option for simplified simulation or deletion).

Options are good, single, "best for everyone" solution is worst.

Full simulation really isn't necessary or beneficial to the game. It's just not needed, and I believe would be something only 1% of users would really appreciate. The other 99% would suffer from unnecessary complexity, and considerable development time diverted from far more useful things. A simplified quick yes/no calculation could be of interest to many, there's merit to adding that. As far as I'm aware, the physics engine only supports a single bubble for full physics, so it would be major development effort to deliver that 1% solution, therefore a mistake to put effort into it.

To me, you're arguing for implementation of a "worst for most" solution, when it should be far simpler to implement an "adequate for most, substandard for a tiny minority" solution. I don't care if it is never implemented at all, but I can see how some might like an improved mechanic, and I strongly believe that the simple solution would satisfy the vast majority of them. Full physics simulation is extremely computationally expensive, if it's even possible to get the engine to run more than 1 simulation at the same time. Multiply the physics load by the number of dropped stages, random junk on suborbital reentry, etc, and it's entirely possible to turn the game into a slideshow on even the most powerful systems. Evaluating the object for total parachute area vs. mass is computationally extremely cheap, and only has to be done once per object, not something far more complex many times per second for full simulation.

[MarkTheRabidCat]

Full simulation really isn't necessary or beneficial to the game. It's just not needed, and I believe would be something only 1% of users would really appreciate. The other 99% would suffer from unnecessary complexity, and considerable development time diverted from far more useful things. A simplified quick yes/no calculation could be of interest to many, there's merit to adding that. As far as I'm aware, the physics engine only supports a single bubble for full physics, so it would be major development effort to deliver that 1% solution, therefore a mistake to put effort into it.

To me, you're arguing for implementation of a "worst for most" solution, when it should be far simpler to implement an "adequate for most, substandard for a tiny minority" solution. I don't care if it is never implemented at all, but I can see how some might like an improved mechanic, and I strongly believe that the simple solution would satisfy the vast majority of them. Full physics simulation is extremely computationally expensive, if it's even possible to get the engine to run more than 1 simulation at the same time. Multiply the physics load by the number of dropped stages, random junk on suborbital reentry, etc, and it's entirely possible to turn the game into a slideshow on even the most powerful systems. Evaluating the object for total parachute area vs. mass is computationally extremely cheap, and only has to be done once per object, not something far more complex many times per second for full simulation.

Honestly, it would never really be a mistake to add a feature, besides, full physics simulation for all applicable vessels is probably something they've decided they need for truely supported multiplayer. Cause I'm not sure if you've noticed, but there's a lot of glitchyness around airborne vessels in DMP, someone else is landing their vessel and it gets deleted for you, and all other kinds of desyncs related to this, not to mention DMP also has to continually block deletion. And don't even get me started on the automatic debris removal, I deffinately want that gotten rid of.

Though I do also agree that a simpler option would be better, for single player, like a quick simple plotting of a trajectory by calculating an average drag co-efficent, and then doing "basic" curve plotting with the parachutes deployment altitudes added in. The kind of thing you would do in university on a TI-82, which your computer could do without even batting an eye.

TL:DR, I think full simulation would be a good idea serverside, and a quick ballistic trajectory calculation for singleplayer, and for said trajectory calculation, I just think that should do auto recovery when it hits the ground, if it should be able to survive, otherwise it should be deleted on IMPACT.

[TheMoonRover]

What really bugs me is how they've extended the physics bubble, but landed debris is still removed. It's landed, for God's sake! No need for a calculation or anything, if it has zero velocity then don't remove it!

It's what now?!

I've never noticed this before.

That only applies to debris at the KSC, and even then it doesn't always happen.

I think a simple calculation would be sufficient much like stage recovery mods, although personally I don't consider it to be a major issue. I play normal difficulty and funds are never really an issue. I can see the advantage for people playing on hard difficulty though.

[Murph]

Honestly, it would never really be a mistake to add a feature, besides, full physics simulation for all applicable vessels is probably something they've decided they need for truely supported multiplayer. Cause I'm not sure if you've noticed, but there's a lot of glitchyness around airborne vessels in DMP, someone else is landing their vessel and it gets deleted for you, and all other kinds of desyncs related to this, not to mention DMP also has to continually block deletion. And don't even get me started on the automatic debris removal, I deffinately want that gotten rid of.

It can certainly be a mistake to add a feature, if that feature comes at a high cost to other more useful or essential features, such as a heavy performance hit for the active flight.

It would be a very naive implementation that performed full physics simulation of every active flight on every connected client in multiplayer, as that would be horrifically unscaleable. A clever implementation can have each client perform only the physics needed for that client's own active flight(s) and share the computational load for a far greater scaleability. Remote clients can easily cover any data update gaps via the normal on-rails processing, or an enhanced version of on-rails (but still overall simplified) process, until they get their next full update.

Glitchy problems like you describe are no surprise when something complex like MP is forcibly retrofitted on top of a framework that was never designed to cope with MP issues, without any proper ability to modify the internals of the original framework. Those sort of problems should be far easier to reliably deal with when it is Squad doing the work, with the ability to provide proper support throughout the framework. For example, someone else's active ship would never get deleted as debris because it would have a flag set marking it as an active player ship, which would short-circuit the normal debris handler. Simple things become complex, hacky, and unreliable when you can't get any real support from the underlying core (when the core doesn't already provide the necessary methods/properties/attributes/interfaces/etc, or behaves in a conflicting manner).

Though I do also agree that a simpler option would be better, for single player, like a quick simple plotting of a trajectory by calculating an average drag co-efficent, and then doing "basic" curve plotting with the parachutes deployment altitudes added in. The kind of thing you would do in university on a TI-82, which your computer could do without even batting an eye.

TL:DR, I think full simulation would be a good idea serverside, and a quick ballistic trajectory calculation for singleplayer, and for said trajectory calculation, I just think that should do auto recovery when it hits the ground, if it should be able to survive, otherwise it should be deleted on IMPACT.

Exactly, it's quite feasible to do a "more than good enough" computationally simple calculation (doesn't rule out complex maths, as long as it's overall quick for a CPU). That doesn't have to be done once per physics frame (many frames per second), and should give basically 99% the same result as a full simulation for most reasonable cases (if your craft/debris is completely bizarre, live with less accurate results). That scales extremely well; full simulation doesn't scale at all well. For stages and debris, it really doesn't matter if it lands in the precisely correct spot, or if an object with highly marginal survival chance falls on the wrong side of the cut (fix the object, if it's highly marginal it wouldn't survive every time under full sim).

Auto-recovery of survivable landing/splash, sure, no argument against that (only that I don't personally feel it's a high priority need, but it is still a worthwhile feature). Auto-delete for the rest, yup. If we're to get better stage/debris handling, I want to see the simple yes/no (as above) for each compound object as a whole, then auto-recovery or auto-delete based on the outcome of that simple calculation. I'd even allow a 3rd case of (optionally?) leave in place if it has an active command part (probe core, or manned pod). False positives and negatives are just fine with me, for something like this, as long as they are edge cases, and the vast majority get a reasonably correct outcome.

Edited May 24, 2015 by Murph

[Superfluous J]

Landed debris is not removed. It's recovered. You just don't get the alert. Run a test. Put some debris around the KSC, look at your money, and then change scenes or whatever to trigger the debris being removed, then look at your money again. It'll go up.

If you want debris to be persistent, make it be "not debris" by adding a probe core or capsule. You must want to control it at some point if you want it to stay around anyway.

[Kegereneku]

At first the new 25 km distance was good enough for me to retrieve the first stage.

But depending of design, if I drop my first stage around 10km high, the debris simply don't have the time to land before leaving the 25km zone and being deleted. I also don't have the time to switch to them to land them. (even with parachute that open at the last minute)

However, if I drop my first/middle stage on a wide sub-orbital trajectory I have the time to orbit the payload and switch to the stage... which can suffer a little during reentry.

I wish recovery was purely based on physic, but the problem is very hard to solve for all the reasons pointed out here. Increasing even more the physic bubble could be a problem (maybe with 64bits ?).

So for now I'll just have to work around the limit.

[cicatrix]

What really pisses me off is that I can't deorbit things if they are on rails. My option is that if an object 'touches' the atmosphere it should deorbit and fall eventually. I have stages that had not enough fuel to lower the Pe substantially but really, a Pe of 35 km is enough to deorbit something, but this blessed thing continues to fly 'on rails' as if no atmosphere is present. At least the 'limit' where objects are deleted should be at least 50 km. I use Stage Recovery and this would be sufficient for me. For those who do not use it this is not a solution obviously.

A simple calculation (has parachutes / does not have parachutes), reentry speed + drag = recovered sum (if any) would be sufficient, I think.

Of course, there's always an option to incorporate stage recovery in stock but even then objects 'on rails' should lose speed in atmospheres.

[Murph]

At least the 'limit' where objects are deleted should be at least 50 km.

No, that would cause worse problems in the opposite direction, deleting craft that very much should not be deleted. The altitude threshold is set to a level that should pretty much guarantee capture, no matter where you're coming in from. If you're coming in from even just the Mun, 50km isn't remotely close to capture, and from solar orbit it's barely going to make a dent in your velocity.

You can de-orbit things on rails, it's the "Terminate" button in the tracking station. Try to think of it as a "rapidly simulate aerocapture combined with burning up on re-entry" button in that situation. ;-)

[cicatrix]

No, that would cause worse problems in the opposite direction, deleting craft that very much should not be deleted. The altitude threshold is set to a level that should pretty much guarantee capture, no matter where you're coming in from. If you're coming in from even just the Mun, 50km isn't remotely close to capture, and from solar orbit it's barely going to make a dent in your velocity.

You can de-orbit things on rails, it's the "Terminate" button in the tracking station. Try to think of it as a "rapidly simulate aerocapture combined with burning up on re-entry" button in that situation. ;-)

I told it was only partial solution. I don't want to terminate them, ideally I want them to reentry, deploy parachutes and land so that they can be recovered.

As for the first problem - I propose a very simple solution - reduce the velocity of the craft 'on rails' passing any atmosphere by a certain amount that can be calculated using a simplified drag formula (nothing complex).

This way, objects that are not supposed to be captured will fly by losing some of their speed whereas objects that are actually ORBITING and having Pe < atmo height will eventually be deorbited. This is strange that by simulating one end of the problem (not capturing objects that are not supposed to be captured) the current setup completely ignores the other end - objects that have to be captured are allowed to pass through the atmosphere as if it never had been there.

P.S. there's more. You say SOME objects should not be captured at 50 km on Kerbin but if the object goes too fast it should burn instead. So, burning = deletion.

Edited May 25, 2015 by cicatrix

[Murph]

I told it was only partial solution. I don't want to terminate them, ideally I want them to reentry, deploy parachutes and land so that they can be recovered.

As for the first problem - I propose a very simple solution - reduce the velocity of the craft 'on rails' passing any atmosphere by a certain amount that can be calculated using a simplified drag formula (nothing complex).

This way, objects that are not supposed to be captured will fly by losing some of their speed whereas objects that are actually ORBITING and having Pe < atmo height will eventually be deorbited. This is strange that by simulating one end of the problem (not capturing objects that are not supposed to be captured) the current setup completely ignores the other end - objects that have to be captured are allowed to pass through the atmosphere as if it never had been there.

Ok, that's much better than "delete below 50km". Yeah, if that can be done while not generating lag, it sounds cool. Possibly a single adjustment right at periapsis would be the way to go (gives you a nicely defined point to trigger at), or a small adjustment every n physics frames, where n is moderately large (e.g. once per second, once per minute, etc).

P.S. there's more. You say SOME objects should not be captured at 50 km on Kerbin but if the object goes too fast it should burn instead. So, burning = deletion.

Hmm, I've not yet really tried much totally mad atmospheric entry from solar in 1.0.2. So far, it seems like 50km is well above any significant heating, even for extreme speeds (but maybe there is a threshold, I don't know). It seems like the real heat is pretty much always below 35–40km. To be honest, for the flights I've seen so far, it's not "some" that shouldn't be captured at 50km, but more like "most" that shouldn't be captured there (that should only capture if you had an Ap quite close to the atmosphere boundary in the first place, for a single pass through, obviously repeated passes do ultimately drop Ap below 70km). BTW, I mean captured by the atmosphere, into guaranteed descent to surface, not captured into orbit, although I think you probably got that.

[cicatrix]

Hmm, I've not yet really tried much totally mad atmospheric entry from solar in 1.0.2. So far, it seems like 50km is well above any significant heating, even for extreme speeds (but maybe there is a threshold, I don't know). It seems like the real heat is pretty much always below 35–40km. To be honest, for the flights I've seen so far, it's not "some" that shouldn't be captured at 50km, but more like "most" that shouldn't be captured there (that should only capture if you had an Ap quite close to the atmosphere boundary in the first place, for a single pass through, obviously repeated passes do ultimately drop Ap below 70km). BTW, I mean captured by the atmosphere, into guaranteed descent to surface, not captured into orbit, although I think you probably got that.

Depends on the speed, really. I found the hard way, that even 1 km below the atmosphere boundary is deadly at 8 km/s (even with 1.0.2 aero)

It can be combined though. Reentry heat is mainly dependent on the 2 things - ship's drag coefficient and its velocity at reentry. If we want to simulate it further, we should take atmosphere density into account (and it varies depending on the altitude). I think the simplified formula would fit here nicely. Take just Pe and velocity, subtract the speed, if the delta-V is too high (E = 0.5 * m*v^2 ) then burn the thing (delete).

[Barking Sands]

I have a suggestion for this problem: Add a function to the staging panel in the VAB/SPH and in flight. When right-clicking on a stage that has a decoupler, you can toggle "persistent" to have the game continue to track the components attached to that stage decoupler until it is recovered/destroyed (default "off"). Drawbacks to this method: the game would have to use a background simulation for that stage after it's detached, which would eat up CPU/RAM resources and there could be physics glitches (Kraken) as a result. It does have a chance of working, however, and it's also a method that doesn't affect gameplay or performance when not actively applied.