Iskierka

Final velocity doesn\'t decide whether you\'ll change to Kerbin\'s SoI, your apoapsis does, as OP thought. Minimum altitude is (IIRC) 2400-odd km. 2500 should get you out neatly, though you\'ll have significant velocity to burn off, so your 5000-km exit might actually be more efficient.

Have you tried FlightGlobals.ship_Acceleration ? I\'m not sure there is such a device to measure acceleration due to gravity from orbit. GRACE and GRAIL both do so by having the two satellites in communication, and comparing their relative motion to track the changes in their orbits. Overall g is usually calculated by the simpler measure of orbital period ... Perhaps a radar that tracked altitude, planet size, and orbital velocity?

Coriolis effects usually count as an umbrella term that includes centrifugal effects, but yes, technically, it is only parallel to the equator. I however didn\'t account for this dimension beyond a preset velocity, used for calculating the centrifugal aspect. Also, any extra acceleration is a lot for this situation. It\'s enough that accounting for Coriolis on Earth would significantly affect pole vaulting records - which seems a very close simile to this situation here. As for calculating it, PakledHostage gave the equations, though in a very strange coordinate system. My data was actually very simple - I was only using python (because it was only intended to be a quick, simple test), and the default floats, with an increase from 1 ms to 0.1ms steps changing results less than a metre; the initial target would be to get all test cases accurate to within 10 metres, which is currently quite far from what we get. Were you tracking the height by altitude or radius from centre? I did the former to reduce float-point errors outside the calculation of g, where they would be (mostly) lost in the insignificant figures, rather than in the metres of altitude. As for atmospheric density, in the process of playing with the new module loader (which has meant no more work on the simulation), I have found code that results in atmospheric density being taken as 1.223095 mass units per metre cubed. Or, if mass units are kg, then standard Earth conditions. I have not yet found the drag code, however (which may be among the parts which did not decompile) meaning it is quite likely there is another scalar to be applied. One that is close is the ratio of Earth to Kerbin, which, when squared, results in a density between 0.0107 and 0.0109, depending on what size is taken for Earth. Afterthought: It would be interesting to try make a new part that inherits from liquidEngine, but overrides throttle input to try follow the optimum vertical ascent. Hm ...

I have to ask; does your code account for coriolis effects on the craft? In my initial testing I was able to match with a density below 0.01, but then when accounting for such, due to the differences in the result, I found the density going above. I still haven\'t completely matched the results, but there are more fine details to add in. And with 1 ms stepping I seem to see little randomness even with simple step calculations. Additionally, things like the starting altitude (0m versus the listed 64m) do seem to have significant impact.

There is no way to make a paraglider in the game at current. Parachutes are just that, they produce drag, not lift. It might be possible for someone to make a paraglider in code once we have documentation for the part loader.

Everyone who doesn\'t have engine gimballing or magic pod torque as the only means of control exploits the infinite glide bug to some extent.

Just a logistic thought, rather than total orbital energy, it should be the delta from the energy it would have at the surface - since orbital energy is negative, and higher orbits get less negative, meaning your number would reduce from getting higher. IE. Rather than just m *(0.5*v^2 - 3.5284E9/(altitude + 600000) ), use that minus: m *(0.5* 174.55 ^2 - 3.5284E9/(600000) ).

The 50% was done by pressing 'launch' and not touching the controls after - since throttle starts at 50%. It can also be confirmed with a joystick with a very large deadzone set (in KSP\'s options, as KSP ignores directInput settings), to ensure that the throttle is settled in that area. Unfortunately, as these are the only ways to be certain of exact throttles, only 0%, 50%, and 100% can be done, and 100% can\'t yet be reconciled. (Though there are one or two aspects of the Coriolis effect to be implemented yet, and lateral drag at high altitudes may be making a difference). Regardless, the confirmed data points found: 50% throttle: Simulation gets 31991.0 m at current tuning. KSP gets either 31991 or 31992m. 100% throttle: Simulation gets 22597.8m. KSP gets 22647m. (Definitely different result.) Initial conditions of rocket are +64m altitude (appears to be where the rocket sits while on the pad), 0 m/s vertical velocity, and aforementioned other conditions. To tune, I adjust a number until it can match the 50% launch as closely as possible, as I\'m more confident of that result, then compare the other numbers. As for 'calculating the optimal' - either I do a once-through test in which the engine thrusts at either 100% or 20%, depending on whether it is above or below terminal velocity, or I do a brute-force method where, rather than trying random patterns, or trying -all- patterns, I start the rocket off with a simple pattern (usually all 100%) and see where it gets to. Then, at each timestep, I go through all the possible variations, and before moving on to the next timestep, select which one gave the best final result. After a few passes, this should find the optimal thrust pattern, having considered, effectively, all patterns, but without having had to try the silly ones, such as all-0%, as 0% thrust was never optimal. PS. And a thought on 2 + a/g - it\'s quite possible this is simply emergent. If you think backwards, this means T*g = 2g + a ... or, in other words, the thrust we\'re outputting is equal to our losses (which, following terminal velocity, are 2g) plus our acceleration. However, there is no reverse connection: nothing mathematically to say if you follow T = 2 + a/g at each point, you will follow an optimal ascent. You might, but the correlation was emergent, not inherent.

I have that much very easily. I\'m attempting to get much, much more precise. Surface density currently being used is 0.0102095, and a change of just 0.0000001 alters results by metres. Surface velocity is estimated at 174.55 m/s, but could vary significantly; gravitational parameter needs least precision adding, but any that could would be helpful. TWR = 2 + a/g is an interesting suggestion which I will ask the sim to try shortly, and see where it ends up - at the very least, it could be helpful as a dynamic, more efficient target than the on/off currently used when estimating maximum.

For now, I\'ve dropped the iterative solving, due to the differing solution. I\'m going to try correctly calibrate the numbers with the correct forces now added, but as jebbe noted, there is an extreme sensitivity to initial conditions and fundamental constants - a change of 0.01% in the surface-level atmospheric density alters the final altitude by several metres, and unless horizontal coriolis acceleration has a much greater effect than you would expect, adding under 10% to what is already a very small effect, KSP does not actually allow full throttle (attempted full-throttle reference launches consistently get 100-400 m higher than the simulation.) As a fun reference, the simulation currently thinks the limit is 2-3 m above the current record - get cracking on raising the bar, already! (it\'s probably a bit higher than this due to inefficient on/off throttling to maintain velocity and still more to add to the sim itself. If anyone can think of a good alternative way to very, very precisely determine atmospheric density, surface velocity, and Kerbin\'s gravitational parameter, this information will be appreciated.)

Sorry, meant m, not m/s - too used to challenges always aiming to optimise m/s, since it\'s usually a given that you can leave the atmosphere. And what I meant was that I can make the simulation try thrusting at constant 50%, and have the final altitude within a metre of what it is in KSP, but when optimising it\'s out by a hundred metres, even though it\'s only getting 1.5 km higher. The iterative method hasn\'t made much, if any advance on that either. However, I think I know what\'s wrong, which is also something that wasn\'t accounted for in the old thread when using a falling body to determine atmospheric density and scale height; Coriolis effect. I\'ll add that to the calculation of g, re-calibrate atmospheric density with the 50% constant (0.009955 did seem odd ...), and then try the simple 'follow terminal velocity' again to see where it gets. Also, that kind of low precision would be a lot faster than this! It manages several simulations per second, but it\'s currently set up to try each throttle percent between 20 and 100, pick the one with the best result, then move on by a second (up to 120 seconds of thrust, barring cutoff due to burnout. The sim then does another 60 for the ballistic arc). One full iteration through the sequence takes ... a long while. And then it has to try again to smooth out the curve.

Coasting to save fuel is news to me, also; most I was aware of was to have fuel for circularization, which is a very different reason to shut down. For the immediate moment I\'ve stopped mathematical analysis of the problem, and am letting the brute-force algorithm have a go (after tuning the atmospheric density so a constant-thrust launch of 50% reaches the same altitude of 31908 m). Currently it thinks it can get a rocket to 33318 m with the pattern it has, but it\'s only done 1.5 cycles so far. (unfortunately, the code is very slow; only 100% reliable way is to vary the thrust at a point, then simulate the entire flight, and pick the maximum, which is somewhat slow.) I will note, however, that asking it to hold back to its terminal velocity at all points did not produce the best result possible, it would seem; the result was a couple hundred m/s short of making the leaderboard. It\'s possible there\'s some imprecision somewhere, but it would be surprising that I could get 50% constant to within a metre and be out by a hundred metres when only getting less than 1.5 km higher.

The issue currently being faced is to re-do the calculation of optimal with a correct interpretation of what is efficient; ie, a different definition of e. In this case, since we are launching vertically the whole way and then finishing with a ballistic arc, I think what\'s needed is a definition of a ballistic arc in a rectilinear (minimal sideways motion) situation with varying rho, calculating the peak point that will be attained from any given final velocity and altitude. From this, e can be properly defined, and optimising it can be calculated anew. Meanwhile, after speaking with my spacecraft flight lecturer and getting told, in short, 'the calculus way is ... \'difficult\',' I\'m going to attempt the preferred method of brute-force, simulate via scripting for as many thrust profiles as possible, and see what achieved the optimum. Then see if that can be reverse-engineered to a workable equation. EDIT: While I am going to work on the latter solution, I have just found a very interesting solution for if a simple dragless ballistic arc is considered; u^2 = v^2 - 2as being considered, the solution for highest peak with unchanging gravity is s = u^2/2g (taking g as cancelling the original negative). By taking e as a factor that optimises this with respect to fuel spent, I have an interesting situation where above one value of u, optimal reduces with increasing thrust, and below, increases. There will have to be further experimentation into this method (and a better equation for the ballistics). EDIT[2]: More testing revealed the pattern is not as simple as first thought, however it is definitely more interesting than the previous results.

I\'ve noticed an error which resulted in that extra /g term, which results in the equation actually simplifying to just x = 2 v^2 / vt^2. This looks erroroneous, but explains an oddity I was noticing, which is that when calculated for manually-set thrusts, e always peaked for thrust = 0. Always; doesn\'t matter if v >, =, or < vt, and is as independent of a as possible for an equation which involves it. The specific substitution used is just before the final equation used to derive the peak of e being at x = 2 + 2a/g, of a/g = x - 1 - v^2 / vt^2. (This after re-substituting v = Wex, for simplicity.) When rearranged that arrives at the first equation in this post. What I would take this to mean is that the initial assumption of measuring efficiency as e = v/T is probably wrong, as quite clearly once you\'re moving it\'s most efficient not to thrust more, when looking at it intuitively. Also, while yes, in theory having 2/g would put units in the left-hand-side, this is computing; effectively, all variables are fundamentally unitless. (or the computer just doesn\'t care about them.) The programmer can happily multiply acceleration in a given frame by a random planet\'s mass, divide by another\'s gravitational parameter, and then add the acceleration due to gravity of a third, and the only complaint it might have is if for some reason one planet had a gravitational parameter of zero (or mass of infinity, or either of NaN). While holding the unit assumptions is usually useful, there is no reason for it to be true in computing, and it cannot be taken as an axiom.

I\'m not convinced of the assumption that v/T being the efficiency factor is most appropriate, but working with that, you have assumed that a << g is true for the majority case, so far as I can tell, which it isn\'t: substituting back, I arrive at an equation x = (2 - 2/g - (2*v^2)/(g*vt^2) ) / (1 - 2/g), which solves at liftoff ( v = 0, g = 9.8 ) for x ~= 2.25, and at roughly 60-70 km, x ~= 2.33 (due to reducing g and arbitrarily high vt), both of which are slightly (but noticeably) above the assumption of 2, which only holds true when v = vt, or more usefully, when close to max-q, assuming max-q is a high value. Interestingly, the space shuttle acceleration profile appears close to this just-above-2 practice, for the most part, with the biggest exception being the final acceleration when losses are negligible and they want to leave the tank in a lower orbit. While the Saturn V is quite clearly faster accelerating, a quick search finds a mention on the Saturn V\'s Wikipedia article that strongly implies the F-1 engines are non-throttleable; further confirmation from other sources, if it could be found, would say that it therefore is not useful for judging optimal ascent trajectories.

http://kerbalspaceprogram.com/forum/index.php?topic=5506.0 This challenge has already been proposed, in the more generic form of 'launch as many times as you can', and has achieved the three required by this challenge. IE. Already been done, nothing to see here. On another note, you disallow C7 for balance reasons, but allow the RCS from it. The same RCS that very, very easily goes to the moon and back.

Just create two different .jar files and switch when needed. I have three different main ones and many old ones of outdated versions.

In terms of realism, the empty tank is massively heavy. The tank is only around a mass ratio of 8; 10 is considered low-ish for a real rocket. Yes, the weight of decouplers negates the benefit of jettisonning a tank, but that\'s because decouplers and engines are absurdly over-weight compared even to the empty tanks.

Canard surfaces induce the infiniglide bug to a greater extent than tail surfaces. Only way to avoid the infinite glide is to not use any part which uses the 'control surface' module, which means no aerodynamic control whatsoever.

That model also does not consider another factor: the delta-v required to get to that orbit. From a theoretical infinitely distant approach point, while the highest efficiency descent is from a low orbit, that orbit required more delta-v to enter in the first place. If you can enter a free-return trajectory of 10 km, circularise, and descend from there, it would certainly be more efficient than attempting to move up and descend, but if you entered at 100 km? Considering the reduced requirements for circularization, it\'s entirely possible it might not be any more efficient to descend to 10 km before making your final approach. Could be something to factor in there.

Kp is actually the damping coefficient, Kd is damping the damping, due to the slightly odd setup of having ASAS wrt angular momentum, rather than direction * angular inertia.

*Looks at your post* *Looks at your avatar* Seems to fit well enough to me! Plus screw similar dimensioning, that looks too good not to be true.

I was aware of this, and used the perfect gas model due to it being quicker and still demonstrating the disparity we have, which will still be at least present in the real gas model. Regardless, SF6 is relatively inert, and that same article states that the limit for perfect gas is 2,000K; just where the perfect gas estimate lies, with a fast reentry. It also doesn\'t take long to find quotes saying the gas against the shuttle in reentry is at least 7,800 K, which is clearly quite a difference. As I stated, I used an extra factor of 1/2 in my calculations, which I thought would fairly clearly at least imply that I had forgotten that factor in the original equation. As the [tt]maximum_drag[/tt] parameter is meant to be a property of the part, and the / 2 is part of q, it seems fairly reasonable to assume that the /2 shouldn\'t be included in the part parameter. A factor of 10 difference from the ISA seems reasonable also, given everything else about Kerbin is a factor of 10 scale, with the one exception of its moon. Re-entry heating isn\'t as excessive a problem such that a factor of 10 base difference is required for correction. Assuming, quite reasonably, that anything which needs more than 'stick a heatshield on' (which is basically just spaceplanes) will have the option of marking in features such as thermal tiles or actively cooled parts without the months of design work required, only the mass, cost and energy penalties, as is reasonable for gameplay, it would be perfectly feasible for reentry heating to be as extreme as on Earth without being excessive. As for drags of parts being additive - remember that the drag of a part only acts on that one part. That part will attempt to behave regardless; ie, a pod will fall as though it has a drag of 0.2. The parachute on top, as though it has 0.3, which means a slower fall. Once these start behaving differently, the physics system comes in and resolves the forces holding them together, which is the only effect that will be seen. Where has it been claimed the parameters are additive? As an extra on atmosphere scale height, I just tested another property which I recall HarvesteR stating on IRC, but is currently locked in a log on an unaccessible harddrive partition. But this factor was that the atmosphere ends when its density is precisely one millionth that of surface level. Given how straightforward that number is, it would be silly to assume he didn\'t pick this number exactly, also. This is further reinforced by the result of this test. With a scale height of 5 km, this would mean the atmosphere ends at 69,077.55m. To test just how much error I could expect, I went in reverse and found out the scale height that would be implied if it were 69 km exact, which was just 6 metres less than 5 km. So, quite clearly, barring a very awkward and nonsensical cutoff, this test would give a very accurate measure of the scale height. For completeness, I\'ll also state that the next round order of magnitude with decreasing scale height isn\'t reached until 4.3 km, so I didn\'t forget a zero. To test, I then set up my most precise orbit ever. Apoapsis 70,414m, periapsis 69055m. If this entered the atmosphere, it would say the height is at least 4.995 km. Even better if it occurred at the precise altitude. So, I entered time warp, 5x to minimise excess speed, then waited until I was booted from warp. The moment I was, I hit escape to pause and read altitude. The altimeter reads 69077m. Very quick unpause and re-pause to check the map. Precise readout is still on the higher value of 69078 m. If this can\'t settle what the scale height is, I\'m not sure what other than HarvesteR\'s direct intervention can.

One main factor I\'d suggest as a possible source of error is the altimeter. Its behaviour is rather strange - both lagging and predictive. Jumping time warp around in an elliptic orbit can readily show this; at the apses, it\'s easy to see that there\'s a slight delay to its height reading, coming to show the apsis altitude less time before the apsis is reached than it takes to move away after leaving the apsis behind. Jumping the warp down while ascending or descending, it can be observed to jump back a few units, before carrying on as it was. The only explanation I can come up with for the reversal is that the altimeter is moving ahead, trying to be predictive with these high velocities. This can\'t exactly be proven systematic, but is much more likely to be than the other obvious source of error, which is the limited (1 second) time resolution. After going through the maths several times, with an estimated sea-level terminal velocity for a mk1pod of 90 m/s, I get an atmospheric density of ~12 kgm^-3. For this I used the equation in my early post, with a slight modification of being / 2, like the real drag equation is. ( In full, FD = ( ? * v^2 * m * [tt]maximum_drag[/tt] ) /2 ) Equated to mg and rearranged, the equation I\'m working with is as follows: ? = (2 * g) / (v2 * [tt]maximum_drag[/tt]) For v = 90, g=9.81, and drag = 0.2, this works out at 12.1 kgm^-3, again assuming the standard unit is 1 ton, as makes sense thus far. As for that calculation of speed of sound, while that possibly gives a good value for drag divergence with respect to gameplay, a ? that low results in an utterly pitiful stagnation temperature. Reentry is boring now? Adding realistic heating for that value will be almost as boring. Stagnation temperature is proportional to M2, which that value of a makes slightly less than that on earth, and also proportional to the value of (? - 1). Reducing ? from 1.4 to 1.04 means bringing stagnation temperature, and thus reentry heating, to a tenth of what it would be on Earth for the same mach. While that does still mean a fairly high peak flow temperature, at least compared to ambient, and assuming said ambient is about comparable to Earth, peak flow temperature is far, far higher than the heating experienced by a reentering vehicle, due to the sparsity of the atmosphere. For reference assuming ambient in both cases to be 250K, temperature ratio on Kerbin, with a reentry Mach of 20 (velocity 2600 m/s) would be 9, for peak flow of 2,250 K. On Earth, with a reentry Mach of 25 (typical estimate), temperature ratio is 126, for peak flow temperature of 31,500 K. While there will be some inaccuracy in these values due to gamma reducing with temperature, and peak temperature not being reached near vehicle skin, this demonstrates the disparity between the two situations. Summary: It\'s kinda hard to make Kerbin fit realistic properties. It\'s already significantly more than twice the density of lead. This has lead to the theories of Kerbin being an inverted dyson shell around a neutron star, which could also explain the lack of tidal locking. Edit: Slight correction to temperature ratios, which were 1 less than they should\'ve been.

Note the challenge being for solar escape, not solar orbit; the requirement here is ~3 km/s more harsh, possibly more.