mhoram

GoSlash27 provided an intersting method: The reverse gravity turn. While I find that the name is not fitting, the method is good.

Already asked this in the UKS thread, but did not receive an answer. I hope that someone can shed some light on this issue.

For Monoprop: Fuel Lines have no effect on the consumption. However staging has. The early stages are drained first. Yes, Monoprop is drained equally and not procentually from all tanks. For LF&Ox: Don't make loops between tanks. This leads only to problems, because they will get drained asymmetrically. Edit: Might be useful: http://forum.kerbalspaceprogram.com/threads/64362-Fuel-Flow-Rules-%280-23-5%29

You could try http://wiki.kerbalspaceprogram.com/wiki/Version_history and read through the changelog of the releases.

"Strange Sort" is a new kind of sorting algorithm that includes the functionality of delayed sorting and external input. I will publish it soon as a new Wikipedia-article

My three tests with your script resulted in: 62,085; 62,111; 62,126 Mods: AeroGUI, KER, kOS, MJ, MM, Telemachus, Toolbar, my goddard.cfg from the OP. PC: Win 8; i7: 2,60GHz Settings: Default (physics-delta: 0.04) + changed graphics to fullscreen. Yes, MM.physics has the same values, I also verified a few values via alt-f12. --- From now on I will also allow f3-screenshots after reaching apoapsis for determining the final altitude (will update the leaderboard for the entries that are affected by this change).

@Muncrash: Welcome to the forum! Your description is very general and it is unfortunately impossible to guess your exact problem. In order to help you, please provide more details. This can be done by adding a more detailled description (what?, where?, when?, ...), screenshots (so others can see what you have built) or the .craft-file (so others can test it directly).

The orbital velocity of gilly is between 274 and 945 m/s. A gravitational slingshot can change the velocity at most by twice the orbital velocity. Since the mass of Gilly is very low and with a velocity of 6000m/s, a gravitational slingshot around gilly will change the velocity just a little amount. My guess would be that under ideal circumstances the effect would be smaller than 300 m/s. Also in order to get an encounter with Gilly at it's maximum speed, you would need to setup that encounter a long time before entering Eve's SOI. Another idea would be to use a gravitational slingshot around Eve to get an other encounter with Eve in a few years.

Maybe there are simpler methods, but you could try http://forum.kerbalspaceprogram.com/threads/107471 and create your own Navball-Texture. Edit: This thread has some textures that can be uses as a basis: http://forum.kerbalspaceprogram.com/threads/69540-Making-high-contrast-nav-ball!

@ Padishar: I find it sad, but believe that we have to life with the fact that the computer-performance has an impact on the results. In this regard the approach that was made in the game Supreme Commander would have been better, where the computing power has no impact on what happens in a single game-time-frame - it slowed the game down but was consistent over all platforms. For the plugin idea, have a look at: http://forum.kerbalspaceprogram.com/threads/116034#PhysicalTimeRatioViewer - - - Updated - - - So ... some new findings. I used the AeroGUI mod to figure out, when the temperature is the hottest at the launchpad. It reaches its maximum roughly at the time when the sun stands at 45° above horizon in the morning - this also means that the best launchtime is not the same all days, but shifts from day to day. On the first day it is near 5:00h Even at that best launchtime I come only to ~61,6km with Sando Mutt's 62.116km-script. The results with Padishars-script are with 62,010 km(+-) in the same range that Sando Mutt reached. And the script I made for adamgerd also reaches 61,6km. Slowly I run out of ideas for the cause of the discrepancies.

If you mean acceleration by thrust, then the formula is simply Acceleration = Thrust / Mass where g is the local gravity at the location of the ship. g can be calculated as g = PlanetsGravityParameter / distance^2 between ship and Planets Center of Mass Since TWR = Thrust / (Mass * g) you get the acceleration as Acceleration = TWR_at_the_location_of_the_ship * g = TWR_at_the_location_of_the_ship * PlanetsGravityParameter / distance^2 = TWR_at_the_location_of_the_ship * G * PlanetsMass / distance^2 where G = 6.674*10^-11 N(m^2/kg^2) You should be aware of the following additional things: Thrust is not the only force that is applied to the ship. There are also Drag and Gravity. TWR can mean different things: - TWR at the sealevel of Kerbin - TWR at the location of the ship - TWR at the sealevel of the body, the ship is currently orbiting Before KSP V1.0 aerobraking altitude was easy and there were tools like http://alterbaron.github.io/ksp_aerocalc/ or http://forum.kerbalspaceprogram.com/threads/30433 With the new aerodynamic system the periapsis altitude for aerobraking is not easily calculated, because it depends on multiple factors, like angle of attack, form of the ship or lift by wings: so it is mostly a combination of guessing and experience. Now there is this addon: http://forum.kerbalspaceprogram.com/threads/104694 It helps eyeballing the periapsis but can not be exact because of the stated reasons. As an example Returning from Minmus with a Lander or capsule I usually go for a periapsis altitude of around 32-38km. If the ship is not as robust, 45-60km is a safer option with multiple passes. For Drag, there is some information in this thread: http://forum.kerbalspaceprogram.com/threads/119108-Overhauls-for-1-0

This sounds like a reason why the scripts reach different altitudes when started under identical conditions. Sando Mutt found an other reason for the discrepancy: temperature changes during the day-night-cycle. This seems to cause differences greater than 500m. The scripts used so far are available here: http://forum.kerbalspaceprogram.com/threads/128509?p=2085928&viewfull=1#post2085928 http://forum.kerbalspaceprogram.com/threads/128509?p=2155711&viewfull=1#post2155711 http://forum.kerbalspaceprogram.com/threads/128509?p=2158468&viewfull=1#post2158468 http://forum.kerbalspaceprogram.com/threads/128509?p=2159301&viewfull=1#post2159301 Thanks for your insight and fast response! I believe my consistency issues are now resolved.

@Sando Mutt: Thanks for your indepth analysis. KSP 1.0 introduced a Temperature-model: I was aware of that but did not expect the temperature to have such a large impact on the results of this challenge. I find it a bit counterintuitive, that 5:00h Kerbin is the hottest time at Kerbal Space Center, because it is before midday - while in reality the hottest time is in the afternoon. For reference I made most of my flighttests at around 5:45 Kerbin Time. I will test the scripts at 5:00h Kerbin time and try other times and make a note about these findings in the OP. Also I got an answer from the kOS side. This sounds like the reason for the <100m differences when launching at the same time.

Thanks for all the new entries! I have the greatest respect for all of you who push the boundaries even further and appreciate the effort you put into this. @Sando Mutt: I tried your script and came in several tries to altitudes of ~61,6km which also differs from Padishars results of your script. @Padishar: Your script brings me to an altitude of higher than 61,9km and at one try I was at 61,992km. These differences in the results are a great problem for me, because I want to keep the challenge fair and comparable but currently the results are not comparable. That is why I went to seek help on the kOS-thread. I hope, that they can help to figure out a way to keep the results consistent. I will update the leaderboard as soon as I have a bit more clarity. On a different matter I would like to give an overview of the entries so far: We had some entries that have no or just a little description of the ascent path. Some entries throttle down just below mach 1 for some time and accelerate again afterwards. A few do the same just below mach 2. And Nao and Padishar provided entries that throttled down twice just below mach 1 and mach 2. My gut feeling says that the last variant should probably be the most efficient of them. I wonder if a third throttling-down below mach 3 would make sense.

Currently I run the "Goddard-Problem: Maximal launch altitude Challenge". (In short: launch a given rocket to the highest possible altitude around 62km) The scripted kOS-entries of the participants are on the high-end-range of efficiency and it seems like different installations perform differently, which means that I currently have the problem that I can no longer compare the results in a fair way. Even on the same installation a kOS script results on different launches in altitude changes of 50m or more. On different computers the altitude discrepancies were in one instance larger than 500m. By default I have excluded the usage of physics or part changing addons, so this should not be an issue. KER, MJ, Telemachus, kOS do not interfer with the physics so they should be OK to use. One problem we have identified so far was the KSP-bug that causes the creation of a wrong physics.cfg file. Also the "physics delta time" config setting has most likely an influence on the results. There are probably multiple reasons for the variance in results we get on different computers/installations. To be able to support the challenge as good as possible I would appreciate some information about what could cause these different results.

1: How far behind the Center of Mass are your rear-wheels? Try putting them behind but close to the CoM. A good explanation of that effect can be seen here (quite far down in the wheels-section): http://forum.kerbalspaceprogram.com/threads/52080-Basic-Aircraft-Design-Explained-Simply-With-Pictures

I use a combination of RCS Build Aid and a medium or small docking port. First I create the payload and try to build it in a way that the CoM is above a flat surface. Then I attach the docking port on the flat surface and put an engine at the bottom of the docking port. Activating RCS build Aid will show me the torque that is created from the engine. Selecting the Docking port now allows me to move the docking port and engine on the flat surface - and the RCS Build Aid window is automatically updated on every movement I make. So I can move the docking port to a position where the torque is nearly 0 and attach the docking port there on the flat surface. Lastly I remove the engine and build my lifter rocket just below the docking port and can be sure that it is nearly rotation-free.

Patched Conics is the method for representing gravity in KSP. Each Sun/Planet/Mun has an area in which it is the primary source of gravity that affects the orbits if all objects within - these are called spheres of influence or SOI short. When an object travels from one SOI to another SOI, the path it takes is patched together from the path in the first SOI and the path in the second SOI. The paths have the form of "conic sections" which is the reason for the naming. In precise node the conics mode states how the paths are displayed. This post explains the different modes. The conic samples configures through how many SOIs the flightpath should be shown, when the flightpath traverses multiple SOIs.

@Gkirmathal: A single Kerbal consumes 0,00005 units of supplies per second or 1,08 units per day. Supplies have a density of 0,001 meaning that a Kerbal consumes 0,00108 ton = 1,08 kg of supplies per day. You could take these numbers as a baseline for your MM-config depending on how many days you want to keep them alive.

Thanks for the clarification of #1 - misunderstood that part. Sounds like an interesting concept and would differentiate the missions more based on their duration.

@adamgerd: I tried to replicate your results with the following kOS-script as best as I understood your description. SET THR TO LIST( 1, // 0 1, // 1 1, // 2 1, // 3 1, // 4 1, // 5 1, // 6 1, // 7 1, // 8 1, // 9 1, // 10 1, // 11 1, // 12 1, // 13 1, // 14 0.26, // 15 0.26, // 16 0.26, // 17 0.26, // 18 0.26, // 19 0.26, // 20 0.26, // 21 0.26, // 22 0.26, // 23 0.80, // 24 0.80, // 25 1, // 26 1, // 27 1, // 28 1, // 29 1, // 30 1, // 31 1, // 32 1, // 33 1, // 34 1, // 35 1, // 36 1, // 37 1, // 38 1, // 39 1, // 40 1, // 41 1, // 42 1, // 43 1, // 44 1, // 45 1, // 46 1, // 47 1, // 48 1, // 49 1, // 50 0). LOCK THROTTLE TO 1. // 1.0 is the max, 0.0 is idle. LOCK STEERING TO HEADING(90,88.125). WAIT 1. // give throttle time to adjust. PRINT "Launch.". STAGE. // same as hitting the spacebar. declare i to 0. UNTIL STAGE:LIQUIDFUEL < 0.001 { print i. LOCK THROTTLE TO THR[i]. set i to i + 1. wait 1. } PRINT "Fuel Depleted @ ". PRINT i. declare maxalt is 0. until maxalt > SHIP:ALTITUDE { lock steering to SHIP:SRFPROGRADE. set maxalt to SHIP:ALTITUDE. wait 0.1. } log maxalt to alt.txt. log i to alt.txt. PRINT maxalt. print "Ending". However I was unable - just like Padishar - to get close to 62k altitude. I was able to get consistent results in the 61.3-61.4 km range - perhaps you can test this script and point me to where it diverges from your ascent profile. I would be happy if we were able to find the reasons for the discrepancies between the results and offer any help I can provide, but until then I am sorry that I can not accept your entry for the leaderboard. :-/

Done. #1 interesting stuff, since it involves more planning how much spare parts to bring with. #2 This would encourage long-term-trip-ships to become more massive because of additional needed parts. My first thought is that there are probably better ways to encourage this kind of playstyle. I am rather inclined against this. #3 Sounds fine, but please use as a radius one of the ranges already available in UKS since there are already a lot of different ranges for different purposes - and adding an additional different range would complicate your mods at a point where in my opinion no one would benefit from. (perhaps even put the ranges-definitions into USITools)

Wow ... a week of vacation and lots of new entries came in. You are great! Thanks for your entry - added you to the leaderboard! And enjoy your time on the forum! Good launch! Also added you to the leaderboard! From what I read about the atmosphere, I gathered that the differences are not that large. And you are free to chose your launchtime as you wish - the "revert to launch" functionality even keeps the time identical. This is a tough one. While I want to believe that you managed to beat 62k, please give me a bit more time to test your ascent profile and rate your entry. @Padishar: Thanks for your trial runs and explanations. I appreciate it.

he got it probably here: https://www.reddit.com/r/KerbalAcademy/comments/1qu5jv/deltav_charts/

The formula you use is the right one: TWR = F / (a * m) and I also arrive at the same TWR of 4.9 for your example "ship" A sealevel-local-TWR > 1 is always enough to land a ship on the planet, if you have enough fuel. You just need to adjust the flightpath in such a way that you have enough time to decelerate. A few things to consider: - engines use up fuel so you get lighter with time and the TWR at the time of landing is the TWR to be taken for the question "it is possible to land?" - the gravity gets lighter the higher you are above the surface so only the surface gravity is essential to answer the question "is it possible to land?" - the pre-landing orbit has no influence on the question "is it possible to land?" - The higher the TWR the less fuel you need. (Link to a forum post by tavert detailing this with pre-v1.0 engines. This link also contains a nice video showing how to land with very-low-TWR ships) This affects how much fuel you need to have on board - Picking a landingspot on higher altitudes (like on a mountaintop) will reduce the TWR-requirement a bit, because the local-TWR on the mountaintop is higher than at sealevel on that planet because of the lower local gravity. edit: As a side note TWR>1 is always enough because at this point your thrust is larger than the gravitational force of the planet on your ship, so you can decelerate.