Tracking Beacons

[palioxis1248]

In light of the upcoming budget system, I'm anticipating that throwing away rocket parts might cost money.

The problem/situation is familiar to everyone. You've got your rocket flying below 35km or something like that. You jettison stages, equipped with parachutes that you've verified can return the stages safely to the surface. But as the stages slide past 2.5km, they vanish, claimed by the Kraken or what have you. And your well thought-out recovery plan is turned to so much hot air.

Clearly this is unsustainable if we're gonna start charging fees for these disappearing stages. If only there was a way to keep the game from ignoring those stages past 2.5km!

Now I know what some of you are gonna say. Mods! There are mods out there that can extend your physics range to 100km and more!

I've got two problems with that.

1. Increasing the physics range to 100km induces all sorts of lag as the game tries to simulate everything around, below and above your rocket.
   
2. Since the issue we're addressing here is critical to enabling a stock feature to work well, I don't think just asking players to download a mod to solve a stock problem is very thoughtful.
   

So here's my suggestion. All probe bodies and command pods will contain what we shall call a Tracking Beacon. This tracking beacon allows the game to selectively continue rendering physics for any object attached to it. Also included will be a separate radially mounted Tracking Beacon Unit, that serves the same function but doesn't allow you to control the parts. When spent stages equipped with Tracking Beacons are detached and slide past 2.5km, the game continues selectively rendering these objects all the way until the Tracking Beacon, which will draw power at a rate similar to small probes, runs out of power, the stage has splashed down, it has been recovered, or the Tracking Beacon has been deactivated (with a right-click context menu option/action group of course). This would allow a simple (methinks) solution to the Disappearing Stage problem, and finally allow us to recover and reuse those lower stages.

Of course, I'm not a game designer, so I'm not sure that selectively rendering specific parts is as easy as I think it is. Suggestions/criticisms are therefore welcome and encouraged. And if the idea is solid, maybe someone float it over to Squad...?

[sumghai]

I believe that the now-unavailable TT NeverUnload add-on had similar functionality, so this idea is definitely feasible from a technical perspective.

I wouldn't mind seeing this as a stock feature myself.

[NoMrBond]

Instead of tracking these expended stages to the ground, it could be simpler to model conditions for recovery

Parts passing out of the 2.5kM 'atmospheric window' are checked for conditions (i.e. parachutes + will land in water, parachutes+legs+will hit land, etc) before being unloaded by the game, anything that meets the recovery conditions is automatically recovered at some calculated 'touchdown' recovery time (or appears in the tracking station to recover).

Perhaps there will be a time delay or reduced value depending on how far away from KSC parts are recovered from

[palioxis1248]

Instead of tracking these expended stages to the ground, it could be simpler to model conditions for recovery

Parts passing out of the 2.5kM 'atmospheric window' are checked for conditions (i.e. parachutes + will land in water, parachutes+legs+will hit land, etc) before being unloaded by the game, anything that meets the recovery conditions is automatically recovered at some calculated 'touchdown' recovery time (or appears in the tracking station to recover).

Perhaps there will be a time delay or reduced value depending on how far away from KSC parts are recovered from

Thought about that too, but the problem is short of modelling the whole process for itself it's pretty hard for the game to decide what constitutes a successful landing. Any rules of thumb implemented would discount certain... interesting recovery methods methinks. I dunno. Maybe this is easier...

[Justin Kerbice]

Good idea but the whole thing of tracking beacon + calculate physics for parts looks like too complicated regarding what was already done in KSP.

Successful landing is not such process resources demanding as you have mass + number of chutes + chutes capabilities + parts resistance, all mixed can give you just enough to make something good enough for the task.

Tracking should be automatic I guess as NASA boosters recovery process, I think they just use a radar to get the approximate landing zone.

Then if the code is smart designed enough, someone could create mod (part failure thing) to add some random "spicy" which make sometimes there is bad luck and parts are destroyed partially or not.

Anyway, there is a big issue to fix first as even manned command pod with a kerbal inside disappear outside this 2.5 kms range, even when there is chutes, engine, anything attached to them.

[Kasuha]

Personally I'm kinda hoping there will be money refunds on any parts you recover and equal refunds on any parts that disappear in Kerbin's atmosphere ("automatic recovery"). With that, you'll not have to care about the fate of stages you drop on your ascent and the game will not have to deal with player requests for following them all the way to surface.

Without refunds, fully reusable (launch once, fly forever) ships would have too much of advantage.

With refunds for recovery only, SSTO/spaceplanes would have too much of advantage.

[Vaporo]

Well, I think that there is an obvious solution to part recovery. As aerodynamics stand now there are only three points during reentry when your air/spacecraft is under any real stress:

When parachutes first open

When parachutes deploy

On touching the ground

What I would do is create a "simplified" physics simulation for any craft containing a parachute to determine whether or not your craft would survive these three points (simplified instead of full so that it can be done at time warp). The simulation would first determine what orientation your craft is likely to fall at, and then uses that orientation for the initial parachute calculations. If the simulation determines that your reentering object is shredded, it would continue to simulate any debris that contains a parachute until it hits the ground. Your craft would then be re-oriented by the simulation to match its new likely fall angle caused by the opening of the parachutes. The "full" parachute opening would work similarly. Hitting the ground would be the tough one to simulate, I think. When your craft touches down, it would, of course, simulate the effects of hitting the ground. If you land on a slope, your craft may buckle and tip over. If the craft has many parts, it could buckle under its own weight. There are a lot of variables in this situation. Any debris that falls off will also have a simulation run to determine its landing site. The simulation would run for each piece of debris until it has reached a "stable" position.

I know that its probably more complicated than I make it sound, and someone would probably find a way to exploit it. Perhaps the simplified simulation could be made to be a bit more unforgiving than the actual full simulation.

It would also have to be updated to work with more advanced aerodynamics, when we get them.

That's how I would try and do it. Maybe I should make a mod.

[Kasuha]

Well, I think that there is an obvious solution to part recovery. As aerodynamics stand now there are only three points during reentry when your air/spacecraft is under any real stress:

When parachutes first open

When parachutes deploy

On touching the ground

There are drogue chutes, too.

Each parachute can have different setting for the height at which it opens

The moment when parachute is deployed plays role, too. In some times you save your ship by deploying the chute later or even below the full open height.

The way how the ship is oriented when the chute opens may play important role.

In the end your simplified simulation isn't that much simpler than full physics simulation.

[r4pt0r]

here was my imput in a similar thread:

some minecraft mods have "chunk loaders" that keep areas of the game world loaded, no matter how far you are from it. perhaps squad could add a "tracking beacon" part that would keep a craft loaded. to prevent it from being loaded all the time and eating up processor power, make it toggleable from the map view.

for example:

in orbit over kerbin.

map view, click your ship, click "activate tracking beacon"

begin your re-entry to kerbin

detach your "science pod" or whatever you wish to call it (ensure it has the beacon not the command craft!)

follow the command craft to touchdown

use tracking station to recover the science pod

as for recovering booster stages i think the game should auto-recover them provided they have: 1.deployed chutes and 2. a ratio of 1 chute for every 6 tons?(is that reasonable? i dont view the weight of my craft ever)

then bigger boosters would need more chutes, cuz realisim or something...

in hindsight i would make the beacon togglable by rightclicking it like we do solar panels, not via map view.

this would be great for dropping a line of probes to find landing sites on duna for example.

Edited June 13, 2014 by r4pt0r

[rtxoff]

Well here's my few cents regarding this matter:

Tracking beacons will not be necessary here. As long as your ship stays as whole you be fine. Now the first time a stage is getting rid of some parts of your rocket it would be required to make a new physics thread for the new subship and continue to calculate it's physics until it either touches down, explodes or ends up on a rail. Because at the moment there is only one physics thread this situation would be ideal to make a new physics thread in the program. Nowadays everyone uses CPU's with more cores, give them some load to compute

It would'nt slow anything as long as new physics threads are made for all subships and as lonsg as the number of this subships stay overlookable. The only question that remains here, what to do when switching to the spacecenter?

[allmhuran]

I think the concept of having parts selectively tracked using tracking beacons or different physics threads are both elegant solutions.

The difficulty, I believe, comes from how the underlying game co-ordinates system works.

KSP has objects covering vast distances, and the game must use some point or other as the origin for figuring out where things are. The problem with setting the origin to the sun (say) is that the numbers for the distance between the sun and your ships get very, very large. As the numbers get larger and larger the room for precision gets smaller and smaller, and you start getting rounding errors. This is where the kraken came from: different parts of your ship in very slightly different positions end up with differently rounded numbers and your ship ends up being torn apart.

Squad's solution to this was elegant: make the origin of the world be the ship itself! In other words, the origin of the game's co-ordinate system actually moves with you. Since only things in a short range of the "active" ship are ever undergoing physics calculations the distance to any of those things is small and there is no problem with rounding.

But the limitation of this is that you can't load things a long way away. Mods that extend the physics range are extending the range from the active vessel. Squad chose 2.5km, and yeah, mods can push this higher. 100km is still a small enough distance that rounding issues won't pop up, so no worries there. But if you have a "tracking beacon" style part that selectively runs physics no matter how far away the part is, the kraken will resurface.

Running multiple different physics threads could, I suppose, be done if each thread also had a moving origin... but does this run into limitations regarding the inability of running multithreaded physics in unity? Possibly.

I agree that being able to recover spent stages does seem pretty important. Some imaginative thinking is going to be needed to make it work, though, given the hurdles outlined above.

[Vaporo]

There are drogue chutes, too.

Each parachute can have different setting for the height at which it opens

The moment when parachute is deployed plays role, too. In some times you save your ship by deploying the chute later or even below the full open height.

The way how the ship is oriented when the chute opens may play important role.

In the end your simplified simulation isn't that much simpler than full physics simulation.

Yes, there are drogue chutes, and chutes that open at different altitudes and etc. etc. etc. What you would do is run the simulation (even if unsimplified) for each time a chute opens. However, this system would mostly exist to return spent stages to Kerbin, which are generally just dropped boosters and fuel tanks with one or two simultaneously opening parachutes, not big complicated landers with numerous chute opening altitudes. (People would do it, though.) Also, the system would be there only to potentially make physics on returning craft more lightweight, not guarantee that there will be lightweight physics calculations on returning craft. (if you make a big enough craft *cough*Whackjob*cough*, even simplified physics will lag.)

I suggested simplified physics so that the return system would be lightweight and usable at timewarp. If the devs can get full physics to work on reentering craft with reasonable speed while the focused ship is at timewarp, and at a very great distance from the reentering craft, then there is no real need for simplified physics, in which case the originally suggested beacon system would probably be better.

Edited June 13, 2014 by Vaporo

[allmhuran]

But if you have a "tracking beacon" style part that selectively runs physics no matter how far away the part is, the kraken will resurface.

... and, thinking about it a little more, maybe that's OK...

If the game continues to use the current origin on the active vessel, then the active vessel will have no kraken issues. The parts that are susceptible to kraken attack will be the spent stages you are dropping back to a surface.

Why might this be acceptable? A few reasons:

1) It's unlikely that these parts are ever going to be more than, say, a few thousand km away from the active vessel by the time they hit the ground. This is probably still within "high precision" range, and so kraken attacks will be rare.

2) Extending the physics range out to a few thousand km raises the problem of performance when you have several ships in orbit all being loaded, but if we only selectively run physics on distant objects (using a tracking beacon style mechanic) then this problem is eliminated

3) Even if kraken attacks do occur they should be fairly rare. And even if they do occur, maybe we can just say that spent stages sometimes break, and that's OK.

4) We could add the provision that even if something is being tracked, physics for the object are disabled once it reaches the surface.

Put together this might work quite well, as long as players are willing to accept the occasional, probabilistic loss of, or damage to, spent stages.

[allmhuran]

... But thinking about it a little more a little more, this does mean you would not be able to switch to another vessel, or back to the space centre, until your spent stages had reached the surface. Or at the very least, doing so would mean the loss of the spent stages (since they will go "on rails in atmosphere" and therefore disappear).

This might be somewhat counter-intuitive. I can certainly imagine a whole ton of posts from players asking why their spent stages disappeared.

Similarly, you wouldn't be able to put the active vessel into rails warp until the spent stages hit the surface.

Edited June 13, 2014 by allmhuran

[Kasuha]

Yes, there are drogue chutes, and chutes that open at different altitudes and etc. etc. etc. What you would do is run the simulation (even if unsimplified) for each time a chute opens. However, this system would mostly exist to return spent stages to Kerbin, which are generally just dropped boosters and fuel tanks with one or two simultaneously opening parachutes, not big complicated landers with numerous chute opening altitudes. (People would do it, though.) Also, the system would be there only to potentially make physics on returning craft more lightweight, not guarantee that there will be lightweight physics calculations on returning craft. (if you make a big enough craft *cough*Whackjob*cough*, even simplified physics will lag.)

I suggested simplified physics so that the return system would be lightweight and usable at timewarp. If the devs can get full physics to work on reentering craft with reasonable speed while the focused ship is at timewarp, and at a very great distance from the reentering craft, then there is no real need for simplified physics, in which case the originally suggested beacon system would be better.

Your idea is sure interesting and I would not object if it was put into the game. In my opinion, though, it is not realistic to expect that it will be since it is a lot of work. Particularly - however simple you consider it to be - a lot more work than other solutions.

Time spent on implementing any temporary/placeholder functionality is time wasted and needs to be minimized. Therefore I believe that if devs care at all, they will look for simplest possible reasonable solution.

[ThirdHorseman]

I am sure Squad has a mechanism planned out for this, because in a recent Devnote Felipe talked about recovery of parts that you were testing for a contract:

Not only that, you also get to test parts which you haven’t researched yet, which means we had to add a system to support these ‘experimental’ parts. The main difference when testing an experimental part is that you’ll get a limited amount of them. If you destroy them before completing the test, you will fail. In cases like SRBs, which are one-shot only, performing the test outside the target conditions won’t mean instant failure, but be prepared to recover that one-off prototype intact.

Speaking of recovery, there’s been a lot of progress done there as well. The “Science Summary†dialog is being overhauled into a complete “Mission Summaryâ€Â, which will show not only the recovered experiment data from a mission, but also the parts you recovered (and how much funds you got back from them), as well as crews. For experimental ‘prototype’ parts, recovery also re-stocks them so you get to launch them again, in case the contract is still incomplete.

So not sure if this "recovery" he speaks of means landing a ship intact, or recovery of parts you have staged off your ship...although he does specifically mention SRBs which tend to be dropped so I would hope they have a mechanic in place to recover parts that you detach. I'm sure we'll hear more about this as the next update gets closer to release. I mean, they wouldn't implement a budget and part recovery system without thinking about recovering jettisoned stages, right?

[coolitic]

simply add a parachute or 2 to parts that will hit kerbin?

[Kasuha]

I am sure Squad has a mechanism planned out for this, because in a recent Devnote Felipe talked about recovery of parts that you were testing for a contract:

Not only that, you also get to test parts which you haven’t researched yet, which means we had to add a system to support these ‘experimental’ parts. The main difference when testing an experimental part is that you’ll get a limited amount of them. If you destroy them before completing the test, you will fail. In cases like SRBs, which are one-shot only, performing the test outside the target conditions won’t mean instant failure, but be prepared to recover that one-off prototype intact.

Speaking of recovery, there’s been a lot of progress done there as well. The “Science Summary†dialog is being overhauled into a complete “Mission Summaryâ€Â, which will show not only the recovered experiment data from a mission, but also the parts you recovered (and how much funds you got back from them), as well as crews. For experimental ‘prototype’ parts, recovery also re-stocks them so you get to launch them again, in case the contract is still incomplete.

So not sure if this "recovery" he speaks of means landing a ship intact, or recovery of parts you have staged off your ship...although he does specifically mention SRBs which tend to be dropped so I would hope they have a mechanic in place to recover parts that you detach. I'm sure we'll hear more about this as the next update gets closer to release. I mean, they wouldn't implement a budget and part recovery system without thinking about recovering jettisoned stages, right?

I'm pretty sure he meant that recovery you perform using the green button above the altimeter or from tracking station.

[ThirdHorseman]

I'm pretty sure he meant that recovery you perform using the green button above the altimeter or from tracking station.

Yea but again he mentions SRB which are almost always staged and discarded. I would really hope that Squad would not spend all this time and energy installing a Contract and Budget system, with a stress on saving funds by recovering equipment, and not address the issue that parts vanish when in atmo. That would be a pretty big screwup IMHO...

[cpast]

Yea but again he mentions SRB which are almost always staged and discarded. I would really hope that Squad would not spend all this time and energy installing a Contract and Budget system, with a stress on saving funds by recovering equipment, and not address the issue that parts vanish when in atmo. That would be a pretty big screwup IMHO...

I don't think you're reading it correctly. He specifically mentions SRBs because he specifically says "if you use them/test them [whatever 'testing' is] in the wrong conditions, you have to be prepared to recover them intact". That implies that normally, you won't be recovering SRBs intact. It wouldn't make sense to be able to easily use an experimental SRB on all your launches by slapping a couple parachutes on the side; if you want to use an experimental SRB (or an experimental part in general) on another mission, you should have to take special steps to ensure that it works right.

That's the biggest issue with letting you recover dropped parts: KSP doesn't have reentry heating, or maximum aerodynamic stress, or anything like that. It's really, really easy to slap a bunch of radial parachutes on a booster, and the parachutes don't weigh a ton. 3 stock radial parachutes are enough to safely recover an ARM LFB and stock nosecone; 5 suffice for a Mainsail (with its lower impact rating). they weigh only 0.45 tons. That means that recovery becomes trivial for all but the smallest rockets (where the 0.15 tons for one parachute could actually matter). Recovering should not be easy. I'd *like* to be able to reuse parts of my boosters, and it'd be realistic to have that idea, but doing something like this would practically eliminate the point of designing for reusability. Budget should encourage careful design, where you actually have to think about how to recover as much as possible, and it's hard to recover everything; if you can just slap a few parachutes on and call it a day, there's zero challenge in designing for recovery, and pretty much every single ship becomes trivially fully recoverable.

[palioxis1248]

Actually the real reason I opined for tracking beacons instead of just rendering for every booster with parachutes on or something like that is this:

Say your 1000 part rocket undergoes rapid spontaneous unplanned disassembly at 20km. Not saying that it would happen, but let's assume pessimistically that the thing breaks apart into as many pieces as you've got parachutes, each piece attached to a parachute. Now the game will try to render each piece, even if the piece was not designed to be recovered/was actually part of a single piece in the first place. The worst is when you have your jumbo 64 tank with 8 parachutes on it, and it explodes and all 8 parachutes end up getting rendered for no reason. So yeah. I felt beacons would be more elegant, because the game only ever need render as many parts as there are beacons. Actually come to think of it, I just realised that activating beacons should be a stageable event, such that they only ever activate if everything goes as planned. Then the game need not render them at all if your ship just blows up.

As for why I'm not comfortable with the simplified physics calculation idea, I think cpast's post pretty much explains it.

[mstrfalco]

Guys I think you should look at this mod called FMRS and how it tackled the problem. The mod creates a save for stages you drop while ascending, then once you have gotten to orbit you can jump back to a stage at the particular moment it was dropped and land it. Once landed you can jump forward in time back to the main vessel but the landed parts remain landed. It is really fun and I have been doing many falcon 9 style landings. No problems found so far either. If there will be rewards for recovery of parts this mod would certainly allow you to recover every part you intent to.

The mod can be found on Curse here: http://www.curse.com/ksp-mods/kerbal/220566-fmrs-v0-1-00