Difference between revisions of "Talk:Parachute"

Latest revision as of 04:07, 2 December 2015

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)

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)

FYI, here is the actual pressure equation and coefficients used in the game: http://www.braeunig.us/pics/KSP/PressureEquations.pdf. You guys might want to keep a copy for future reference. — OhioBob (talk) 03:42, 1 June 2015 (UTC)

Thanks for that, it's interesting to see, and might well end up useful for something. Are those numbers precisely Squad's numbers, or did you have to derive them? I don't much fancy writing wikicode to handle the Kerbin case, though! It certainly looks like they really tried to fine tune the hell out of its atmosphere compared to the other bodies, or at least that was the first thing that sprang to mind when I saw that page.

Those are essentially the numbers provided by Squad, though I did have to do some calculations to get them into a form that can be plugged into the equation. Here is an example of the actual raw data for Eve:

key = 0 506.625 0 -0.08693577

key = 9723.525 113.4918 -0.0149408 -0.0149408

key = 20000 29.0968 -0.003046887 -0.003046887

key = 45000 0.8180758 -5.822258E-05 -5.822258E-05

key = 80000 0.005512151 -3.777213E-07 -3.777213E-07

key = 90000 0 0 0

All the A-F coefficients are directly computed from the above data. For example, the value of the first B coefficient for Eve is, B = -0.08693577*(9723.525-0) = -845.32213298925, and so on.

Regarding Kerbin, Squad was trying to match an actual atmospheric model, the U.S. Standard Atmosphere, so they used a lot of points to try to get it as close as possible. For the other planets they were apparently just making it up, so they could get a reasonable looking curve with fewer points.

— OhioBob (talk) 15:02, 1 June 2015 (UTC)

One issue could be that we can't really have a if-elif-else construct without cascading ifs (if else (if else)) and afaik does MediaWiki only allow 40 levels. For example Kerbin has already 32 levels (see in the page's source code: Highest expansion depth: 32/40). — xZise [talk] 10:54, 4 June 2015 (UTC)

That's a perfectly valid concern. It might be possible to work around it, however, with something like the following (being lazy and not using full syntax and just inventing numbers for discussion purposes):

{{#ifexpr: altitude < 500 | calculation_1 }}
{{#ifexpr: altitude >= 500 and altitude < 1000 | calculation_2 }}
{{#ifexpr: altitude >= 1000 and altitude < 5000 | calculation_3 }}
... etc ...

(Yes, that would be pressure from altitude, not altitude from pressure.) I.e. avoid the worst of the nesting completely by avoiding "else if".

--Murph (talk) 12:45, 4 June 2015 (UTC)

Here are the equations I came up with to compute altitude from pressure: http://www.braeunig.us/pics/KSP/AltitudeEquations.pdf. In all but a very few cases, the accuracy is within 100 meters; and in many cases, particularly at low altitudes, the accuracy is within a one meter. I still favor making the parachute semi-deploy altitudes static values, but if you really want to use the equations, I won't argue; however, I would like to see the result rounded of to no closer than the nearest 100 m. Remember, you might not have to use all the equations because the parachute deploy slider is adjustable between 0.02 and 0.5 atm only. — OhioBob (talk) 06:39, 6 June 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Does anybody know how to change the semi-deployment altitudes? With the version 1.0.5 atmosphere changes, the semi-deployment altitudes have changed for Eve, Duna, and Jool. The new altitudes for Eve are 34459 m and 38355 m, the new altitudes for Duna are 4448 m and 9266 m, and the new altitudes for Jool are 142580 m and 149810 m. I don't know how to make these changes, so I request help from somebody who knows how to make the required modifications. Thanks. — OhioBob (talk) 04:07, 2 December 2015 (UTC)