Automatic delete of space debris that have orbit perapsis lower than 30 km

[JoCRaM]

No it doesn't. If an unmanned space plane re-entered Earth's atmosphere, the fact that it had wings wouldn't matter. I propose they simply ignore everything except mass and number of deployed parachutes.

what is special about parachutes that isn't about wings? they both have give craft the capability of landing unattended.

[Superfluous J]

what is special about parachutes that isn't about wings? they both have give craft the capability of landing unattended.

What?

Here's the difference between the two.

1) Get a capsule in LKO, with a periapsis below 70k. Deploy the chute. Go to bed. When you wake up in the morning check it out. It'll be on the surface of Kerbin.

2) The next night, make a space plane. You can do WHATEVER YOU WANT to it except no mods and no parachutes. Put it in the same orbit the capsule was in. Go to bed. I suspect it will not fare quite as well as the capsule did.

All I want is anything with a reasonable expectation of surviving the above scenario, to survive it if I am piloting Jeb around Mun instead of sleeping in my bed letting the full physics engine run.

[Dunbaratu]

The parachute is irrelevant to the calculation of whether or not the debris should be removed.

Yes, it is. But it doesn't have to be.

I chose my words very carefully there. I didn't just say that it is irrelevant to the calculation of whether or not the debris IS removed. (i.e. describing current game behavior). I said it was irrelevant to the calculation of whether or not the debris SHOULD BE removed. (i.e. describing how I am claiming the game should behave).

As long as the drag coefficient is >0.0, then it doesn't matter if it's 0.2 or 0.5 or 200 or 500 or whatever because ANY drag will mean the orbit will eventually decay and fall in. If it only went as deep as 50,000 m or 60,000 m and had no parachutes it would still eventually go away. That's why I'm saying there shouldn't be a situation in which a craft dips deep enough into the atmosphere to be removed if it has parachutes, but not be removed if it doesn't.

[Superfluous J]

I chose my words very carefully there. I didn't just say that it is irrelevant to the calculation of whether or not the debris IS removed. (i.e. describing current game behavior). I said it was irrelevant to the calculation of whether or not the debris SHOULD BE removed. (i.e. describing how I am claiming the game should behave).

As long as the drag coefficient is >0.0, then it doesn't matter if it's 0.2 or 0.5 or 200 or 500 or whatever because ANY drag will mean the orbit will eventually decay and fall in. If it only went as deep as 50,000 m or 60,000 m and had no parachutes it would still eventually go away. That's why I'm saying there shouldn't be a situation in which a craft dips deep enough into the atmosphere to be removed if it has parachutes, but not be removed if it doesn't.

I concentrated on the word "removed."

Yes, the existence of a parachute should not determine if an orbit would decay, and I'm not arguing that idea at all. My personal argument is regarding the deciding between removing something from the game, and landing it instead. Which is a hijack of the thread that has gone on too many pages, and for that I apologize to the OP.

For that reason alone I should stop, but I'm going to in any case because we're arguing cross purposes anyway. Either you think it's important or you don't, and you either think my idea is good or you don't. Nobody at this point will convince the other.

[UberFuber]

I concentrated on the word "removed."

Yes, the existence of a parachute should not determine if an orbit would decay, and I'm not arguing that idea at all. My personal argument is regarding the deciding between removing something from the game, and landing it instead. Which is a hijack of the thread that has gone on too many pages, and for that I apologize to the OP.

For that reason alone I should stop, but I'm going to in any case because we're arguing cross purposes anyway. Either you think it's important or you don't, and you either think my idea is good or you don't. Nobody at this point will convince the other.

The difficult is that just because some space-craft have sufficient parachutes, doesn't mean it can safely land (or necessarily in one pieces).

You'll have to deal with some edge cases. Such as parachute placed on, say, a structural weakpoint (your parachutes are connected to the rest of your space-craft with flimsy decoupler). Yes, the parachute can slow your space-craft down, but with full physics simulation, most of your space-craft may shear off and destroy themselves.

In short, you need some form of physics simulation. For that, I have a possible solution.

Any object with an attached parachute deployed are loaded for physics computation if they're in atmosphere (you can deploy parachute in space, they just won't "pop-out" unless they're in atmosphere). So, if you want to abandon a spacecraft, just don't deploy its parachutes. This cuts down on simulation costs as only space-crafts that player specifically wants to recover will get loaded and simulated. So, what would this allow?

1. Probe recovery: Player can set the probe parachute to deploy and set it on a reentry trajectory and forget about it until it hits the atmosphere (which will cause physics to kick in and limit time-warp to 4x physics).

2. Booster recovery: If economy is added, it might be a good idea to recover boosters. Player just have to add parachutes to their booster and tie their deployment to the booster being staged.

[dawg]

You can "terminate" them in the KSC Tracking Station...

It'd be really awesome if you could terminate all unmanned debris with fewer clicks, though.

[Waster]

You can "terminate" them in the KSC Tracking Station...

It'd be really awesome if you could terminate all unmanned debris with fewer clicks, though.

Yes. Yes it would.

At least apply common windows ability to "select all" with the shift key or click the ones you want with the Ctrl key.

[Superfluous J]

Yes. Yes it would.

At least apply common windows ability to "select all" with the shift key or click the ones you want with the Ctrl key.

Please don't get me used to doing that in-game or I'll go back to multi-selecting fuel tanks to transfer fuel, and accidentally end up powering up my rockets and plowing through my space station again.

I propose multi-select be done with "alt" or perhaps allowing a box to be dragged out on the screen.

[Grumman]

Deleting it is kinda the only way to do it that will not burn a common computer. Simulating your current vessel + a 2.5km bubble around it is hard enough in a lot of cases... but potentially loading multiple planets & location to simulate a bunch of derbies would be either most likely impossible or at least lots of wasted resources.

Just a rough estimate would be enough. If the mass of the rocket is less than X*number of deployed parachutes, it lands safely. Otherwise, it is destroyed.

[Kasuha]

I believe parachutes should be left out of equation. Because when you start wanting to land things with chutes, you're bound to do full physics of its landing. Is it sturdy enough to not break when chutes deploy? When they open? Is it sturdy enough to not break when it lands? It would be way too easy to land things if the engine just dropped them safely on the ground if they had a chute. I could send a whole orbital station down safely with single chute that way.

I would not object against the game fully simulating atmospheric entry for anything that enters atmosphere. Perhaps in x4 physics warp if not attended. It's not like there's much of it anyway. But definitely not anything like "if it has chutes, it landed".

Edited November 22, 2013 by Kasuha

[S4qFBxkFFg]

Another idea that might deserve airing:

I understand why there's a cut-off distance beyond where physics simulation stops, it could lead to excessive load on CPU/GPU, but, there may be a way round it -- is there anything that says the simulation of a dropped booster has to take place there and then? What I'm proposing is that it stops getting simulated when moving out of the bubble but has its state saved. Then, whenever the resource load becomes less (e.g. when the player goes to the Space Centre), the game simulates it in the background and goes back on rails once the object is re-inserted back in wherever it would have landed.

I realise this could throw up all sorts of problems if you turned the rocket around and started flying back towards the spent boosters - what appears, where does it appear, when does it appear?

Is this crazy?

Is there some horrendous problem I haven't even thought of?

[John Nowak]

Something bare bones such as "once an orbit, if periaps is less than 70km reduce apoaps by 10%; if apoaps and periaps are both below 70 km delete" would be nice.

[Kasuha]

What I'm proposing is that it stops getting simulated when moving out of the bubble but has its state saved. Then, whenever the resource load becomes less (e.g. when the player goes to the Space Centre), the game simulates it in the background and goes back on rails once the object is re-inserted back in wherever it would have landed.

The only problem with this is that you need the simulation to be already done when you switch to map view. So anything less than real time is too late.

[Dunbaratu]

Another idea that might deserve airing:

I understand why there's a cut-off distance beyond where physics simulation stops, it could lead to excessive load on CPU/GPU, but, there may be a way round it -- is there anything that says the simulation of a dropped booster has to take place there and then? What I'm proposing is that it stops getting simulated when moving out of the bubble but has its state saved. Then, whenever the resource load becomes less (e.g. when the player goes to the Space Centre), the game simulates it in the background and goes back on rails once the object is re-inserted back in wherever it would have landed.

I realise this could throw up all sorts of problems if you turned the rocket around and started flying back towards the spent boosters - what appears, where does it appear, when does it appear?

Is this crazy?

Is there some horrendous problem I haven't even thought of?

Are you proposing that the object remains frozen in position until a low load time? I don't think that's workable, as it breaks the object's position relative to other objects.

.

[S4qFBxkFFg]

Are you proposing that the object remains frozen in position until a low load time? I don't think that's workable, as it breaks the object's position relative to other objects.

.

No, but what I'm thinking of is arguably even more drastic - the object that would have been deleted still gets removed, but with its physics state saved. The idea is that once the processing load reaches some defined lower level (or maybe fps is above a certain level?), the object's physics are restarted. Note that this would just be the calculations - nothing is actually re-inserted into the game until its landing position and state are known.

I realise that this could lead to some decidedly odd behaviour but how much, and exactly what, I'm not sure.

edit:

I didn't actually address your point - yes, it would have to check to see whether the trajectories for all the debris/booster objects intersected or not, apart from the (possibly mistaken) assumption that once outside the 2.5km limit, nothing's going to hit the player-controlled ship.

The only problem with this is that you need the simulation to be already done when you switch to map view. So anything less than real time is too late.

Honest question - is this really necessary? Ideally, I'd like everything to be done as soon as I hit m, but I think we could fudge this by making up an explanation that the tracking station prioritises crewed ships and doesn't even try to locate spent boosters etc. until it's sure the mission is in a safe orbit or whatever.

Perhaps in the interim period, a message could appear saying "locating boosters...", or something similar.

Edited November 28, 2013 by S4qFBxkFFg
elaborated reply to Steven

[John FX]

This all sounds terrible, intrusive, and counter to good gameplay. Why not just set debris to 0 and be happy with other vessels vanishing at 20Km?

[Dun Kirk]

agreed. A timer of "will burn up in x amount of time" should get triggered in this scenario, else it can get stuck there if you time warp through the <30K stages.

[Frederf]

A small speed change retrograde applied at every Pe between 23km and 69km (function of height of course) would be a very cheap way of having decaying orbits. No parachutes, no landings, no slippery craft, no draggy craft, just -N m/s where N is a function of altitude. Parts that barely skim the atmo at 67km will take ages to hit the 23km wall and ones at 24km will likely disappear on the first Pe. It isn't very often that an unattended craft passes Pe. Unattended ascending craft would be immune since it's only evaluated at Pe.

It's simple and efficient and handles 80% of what's desired compared to full physics for all craft in the atmo band.

[Grumman]

I believe parachutes should be left out of equation. Because when you start wanting to land things with chutes, you're bound to do full physics of its landing. Is it sturdy enough to not break when chutes deploy? When they open? Is it sturdy enough to not break when it lands? It would be way too easy to land things if the engine just dropped them safely on the ground if they had a chute. I could send a whole orbital station down safely with single chute that way.

You're fighting a strawman. Nobody wants a single parachute to have infinite carrying capacity. Even if the X*parachutes > mass calculation was just to decide whether to bother simulating the landing or not, it is important as a way to distinguish between the bits which might land safely and which are inherently incapable and will do nothing other than eat up valuable processing power.

[JoCRaM]

What?

Here's the difference between the two.

1) Get a capsule in LKO, with a periapsis below 70k. Deploy the chute. Go to bed. When you wake up in the morning check it out. It'll be on the surface of Kerbin.

2) The next night, make a space plane. You can do WHATEVER YOU WANT to it except no mods and no parachutes. Put it in the same orbit the capsule was in. Go to bed. I suspect it will not fare quite as well as the capsule did.

All I want is anything with a reasonable expectation of surviving the above scenario, to survive it if I am piloting Jeb around Mun instead of sleeping in my bed letting the full physics engine run.

Done.

The wings snapped off, but the pilot survived. If it had landed "on land" without crashing into a mountain it would probably survive in one piece.

[Superfluous J]

Done.

The wings snapped off, but the pilot survived. If it had landed "on land" without crashing into a mountain it would probably survive in one piece.

Nicely done. I should have made that a challenge. I'd love to see the craft file so I can land it unassisted a couple dozen times and prove to myself that it works flawlessly.

Is it safe to assume you can recreate the results most if not all of the time, and design a wide range of ships for which it'd work? And could you think up a way to code KSP to look for it and decide if it'll land itself? Because if you can, I'll happily add it to the list of things I think the game should allow to become landed once it would normally delete it, along with the relatively simple "If it has enough chutes that you'd expect it to be able to land if you followed it down but didn't interact with it" that's already on my list.

[JoCRaM]

Nicely done. I should have made that a challenge. I'd love to see the craft file so I can land it unassisted a couple dozen times and prove to myself that it works flawlessly.

Is it safe to assume you can recreate the results most if not all of the time, and design a wide range of ships for which it'd work?

it's trivial to do - most toy plane kits before radio control managed to land without crashing. it took me 5 mintes to build my test craft - it took me longer to build the launch vehicle that could cope with the aerodynamics pulling it off course - in retrospect I should have simply put two landers on top of the rocket belly to belly. (last night was my first visit to the forum since my previous post)

Is it safe to assume you can recreate the results most if not all of the time, and design a wide range of ships for which it'd work?

I imagine so, it worked on the first flight I got out of atmosphere.

Unfortunately my upgrade to windows 8 destroyed my filesystem, but pretty much all of my space planes would have large parts of the assmbly survive an unsupervised landing. (since the rebuild I've been concetrating on kOS - my initial goal was to emulate a skylon mission, but I detoured into a fully automated Apollo style mission as a way of learning it.)

And could you think up a way to code KSP to look for it and decide if it'll land itself? Because if you can, I'll happily add it to the list of things I think the game should allow to become landed once it would normally delete it, along with the relatively simple "If it has enough chutes that you'd expect it to be able to land if you followed it down but didn't interact with it" that's already on my list.

I don't know, "enough lift" is calcuable, as is offset center of drag for directional stability, but lifting surfaces can be used for that instead. offset conter of mass to provide roll stability is probably important.

[thereaverofdarkness]

I had a suggestion a while back about extending the "end" of the atmosphere to make long term low orbit stations require orbital maintenance. The relevant part was that I was suggesting making ships in atmosphere that are not in physics to be under partial physics in which they count as a single spherical piece and slow down over time due to drag. If this were implemented, the auto-delete distance could be moved down, and craft in low orbits would fall eventually without you manually watching them.

I still want to have the edge of the atmosphere extended for easy debris removal: put yourself in low orbit and drop your spent fuel tanks, you have several minutes, hours, even days to get into a new orbit but your fuel tanks will eventually fall down.

[JoCRaM]

A second, similar design, landed with no damage both attempts I made, the first on land (after 8 hours of dipping into the atmosphere) the second flight didn't actually go above 8000m, but successfully landed on water in exactly the same way it would have done had it gone through the whole orbital procedure. Video/craft to follow. The mountain problem is still a threat, so I might see if I can minimise that by designing the lander to cricle.

but my desire for atmospheric simulation (with simplification by hard-bodying if performance really is an issue) is far more about letting the carrier aircraft glide while I take the second stage to orbit, before returning to the carrier to land it properly. I don't really care if it freezes in place, does a full simulation or a simplified one, just don't destroy it without good reason.

[JoCRaM]

version 1

version 2, full flight, 14 aerobraking dips and a 15th lithobraking entry.
Highlights: Final re-entry starts around 11:40; 30,000M for renerty plasma at 13:15; the craft finally gets enough atmospheric bite at 6500m 14:50; actual ship landing starts at 16:25

version 2 landing in/on water Edited December 14, 2013 by JoCRaM