Talk:Parachute

Full-deployment altitudes depending on pressure?

Hey, there were some edits, that the full deployment altitudes are depending on the pressure like the semi deployment. Now I haven't visited another planet, but according to the part.cfg (e.g. Mk16) the full deployment altitude is defined by the altitude itself and not the surrounding pressure. Can somebody test this and may back this up? — xZise [talk] 14:39, 8 May 2013 (CDT)

The full deployment altitude is always 500 m above ground. That makes a pressure-based trigger impossible, because the air pressure does not "follow" the terrain. (e. g. on a 10km high mountain the air is thinner than at sea level, but the parachutes will fully deploy at 10500m anyway.) It might be possible that the full-deploy height is different for each planet, but there is no config file for such values. Also it would cause the parachutes to deploy much sooner on Eve than they would on Kerbin, because of its high atmospheric pressure. I haven't been there myself, but I checked a video, the parachutes deployed at 1700m, the landing was at 1200m, so 500m above ground. There is no way that this is pressure-controlled. --Dgelessus (talk) 15:34, 8 May 2013 (CDT)

Ah nice ;) Maybe link the video. I'm now changing this article back. — xZise [talk] 16:32, 8 May 2013 (CDT)

Here it is: http://www.youtube.com/watch?v=yj0T-ylVbjU. The landing is in the last few minutes. --Dgelessus (talk) 15:37, 9 May 2013 (CDT)

Here is the same video link with time code http://www.youtube.com/watch?v=yj0T-ylVbjU&t=45m40s. --Omega (talk) 11:19, 10 May 2013 (CDT)

Semi-deployment altitudes

The semi-deployment altitudes listed in the table are not correct for version 1.0.x. It appears the altitudes are computed using an outdated formula that is not compatible with the new atmosphere models. I've computed what the altitudes should be (see table below) but I don't how to edit the table imbedded in the article. If there is somebody else who knows how to do this, I request that you make the appropriate changes. Thanks. — OhioBob (talk) 05:51, 30 May 2015 (UTC)

	Eve	Kerbin	Duna	Jool	Laythe
0.04 atm	34 432 m	17 590 m	11 671 m	171 873 m	21 482 m
0.02 atm	38 301 m	21 204 m	15 279 m	180 959 m	27 471 m

Thanks for the efforts and information. This is a slightly complex fix. The table is produced by {{Deploy Table Parachutes}}, and the actual altitude numbers come from {{Body data/alt at pressure}} via {{Deploy Table Parachutes/Cell}}. So, if we want to use static numbers, there's a little bit of template de-tangling to do. They are being generated from the old "scale height" and "pressure" using the old method.

It seems that we have 2 choices here. Either fix {{Body data/alt at pressure}} to give "good enough" results, or convert the table to use static data instead of dynamically calculated data. At this precise moment, I'm not certain which is the best way to go, so am not going to attempt to fix it right now. Someone else, please feel free to jump in and work on it, don't wait for me (but I am thinking about how best to fix).

In the interim, I'll add an outdated notice, so that visitors know the data isn't accurate.

--Murph (talk) 07:58, 30 May 2015 (UTC)

Yes Murph you completely untangled this. Now I personally would prefer if we can get “alt at pressure” to give somehow sensible results from the data we got as there might be other templates using that one. But if that is not feasible/possible we could just get rid of the {{Deploy Table Parachutes/Cell}} and just enter the values manually. — xZise [talk] 09:49, 30 May 2015 (UTC)

Going out for coffee can be a good thing1

I had a flash of inspiration while taking a break from staring at the seemingly infinite number of curly braces inside wiki code, and have put in a very quick hack to hard wire the numbers in {{Body data/alt at pressure}} for 0.02 and 0.04. It doesn't fully address the wider issue, but solves the immediate narrow problem for the table on the parachute page.

I'd be happy to plug appropriate maths into that template, and no problem to do them on a per-body basis. I think we got a formula to estimate Kerbin from you, OhioBob. If you can provide such a thing for all of them, I'll try to integrate them into the template, as long as they are a simple "altitude = fn(pressure)" type thing, even if the maths inside the function are complex-ish.

--Murph (talk) 16:51, 30 May 2015 (UTC)

Although a single equation for each planet is possible, it won't be very accurate. The game uses animation curves to compute pressure, so it is really a series of connected functions. Trying to approximate this with a single function can't be done with high accuracy. For example, here is the curve for Eve: http://www.braeunig.us/pics/KSP/Eve_Atmosphere_T&P.png. I would have to come up with a polynomial that approximates the blue line. It's possible to at least get in the ballpark up to about 80 km, but then the curve deviates dramatically as the pressure is forced to rapidly go to zero when reaching the upper boundary (this happens with all current atmospheres). I don't think there is any way to approximate both the lower and upper parts of the curve with one equation. In the case of Jool, the parachute semi-deploy altitudes are actually in the upper part of the curve. Unfortunately Squad just didn't make it easy on us with the new aero model. — OhioBob (talk) 17:31, 30 May 2015 (UTC)

Is it possible to use a IF function on the right side of "altitude = fn(pressure)" so that different functions are used over different pressure ranges? — OhioBob (talk) 17:43, 30 May 2015 (UTC)

Yes, as long as the total number of different cases is not crazy, and the cases are clearly defined, it's no real problem to use different functions for different ranges. MediaWiki's "ParserFunctions" have a variety of ways of doing clever stuff like that, with "if" and "switch" statements, but it causes increasing brain ache and eye strain that rises just about exponentially with complexity. The following C-ish pseudo-code is possible:

switch(body) {
    case "Kerbin":
        if (pressure < K_PA) { return functionK_A(pressure); }
        else { return functionK_B(pressure); }
    case "Eve":
        if (pressure < E_PA) { return functionE_A(pressure); }
        else { return functionE_B(pressure); }
    …
}

"else if" isn't a problem, so not restricted to just A or B cases, I just wanted to keep the example short. Just how many cases would you anticipate for each body?

--Murph (talk) 18:08, 30 May 2015 (UTC)

If I had to approximate the entire range of pressures from sea level to zero with reasonably good accuracy, I could see it taking maybe 6 or 7 equations. Fortunately I don't think it is necessary to do that. The slider on the parachutes limits the pressure setting to the range 0.02-0.50 atm, so that's all I need to worry about. By dealing with a smaller range of data, it should be easier to get a good curve fit. I'm hoping it won't require more than 2 or 3 equations, maybe even one if I'm lucky. Here's another suggestion, can we round off the result, say to the nearest 100 m? By rounding off we can hide the error and make it more obvious that the result is an approximation. — OhioBob (talk) 19:43, 30 May 2015 (UTC)

Yeah, personally I'm quite happy with "good enough". I'm also a real life scientist/engineer, so I do appreciate accuracy and precision when it's needed, but also the need to accept reasonable error bounds and approximations when it's ok to relax the precision a little. In terms of the Kerbal universe, "good enough" would seem very much in the spirit of the game. So, yeah, that works for me, as long as we can accompany it with a reasonable description of the error bounds, and any limitations or cases where it's less accurate. Rounding to 100m sounds quite reasonable to me. Even rounding to 500m or 1000m wouldn't be completely unreasonable for this context, if there was a big advantage to doing so. As long as we understand it and put the appropriate footnote on any usage, it's all good.

I'm just one person though, so possibly wait to see what xZise thinks before you spend a great deal of effort on it. Anyone else that's watching as well, please do feel free to add your opinion.

--Murph (talk) 20:04, 30 May 2015 (UTC)

I'll try to derive some equations over the next couple days. Unless you inform me otherwise, I'm assuming that pressure will be in atmospheres and altitude in meters. — OhioBob (talk) 00:09, 31 May 2015 (UTC)

Correct. Kerbin sea level should be 1.0, so Kerbin(1.0) == 0m, Kerbin(0.0) == 70000m, Kerbin(0.5) == (somewhere around 4000–5000m), or whatever the precise numbers are under the new model. Thanks. --Murph (talk) 02:08, 31 May 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Just as a sidenote: For parachutes 0.02-0.5 atm might be enough but if we have a parachute specific solution we could just use static values. If we want to have it in the more generic {{Body data/alt at pressure}} we would need the entire range but an approximation should be enough. And if it's not feasible we discontinue using that template and just use static values. — xZise [talk] 22:39, 31 May 2015 (UTC)

If the only place these equations will be used is for parachutes, then I tend to favor static values. Deriving a bunch of equations to estimate ten numbers that I've already calculated to their exact value seems like needless work to me. One the other hand, if the equations have more wide reaching use, then I don't mind putting forth the effort. In that case, however, it seems that it would be wise to have equations that span the entire range of atmospheric pressures. The question then becomes, how much error are we willing to accept? I can probably get an answer that is within a few meters, but that will take a large number of equations and high order polynomials. On the other hand, if ±100m is close enough, then fewer and simpler equations will work. — OhioBob (talk) 23:39, 31 May 2015 (UTC)