Dave Kerbin

Ok this doesn't really 'add' anything to the game, well except for the heavy roleplayers, but from my own Unity knowledge it seems like it might be low cost to add. Basically it's this, right now the doors on the administration building, the scene building, the VAB, etc are all just functionless textures so when you walk up to them it kind of breaks the immersion. Of course the hatches on capsules are just textures but they also have a proximity function so that kerbals on EVA can click the F key to trigger the load-kerbal-into-pod code which removes the kerbal object from the scene and adds the kerbal stats entry to the pod. What I'm suggesting is adding a similar proximity/collision box outside the doors of each building for EVA'd kerbals to interact with. When a kerbal walks up to the VAB door a prompt appears [F]: Enter. As long as the kerbal is in a stable 'landed' position it executes a scene change to the VAB (or whatever building the kerbal is entering), the same as if the player had pressed ESC, clicked Exit to Space Center and then clicked on the VAB/building. A second change would be to remember if the player reached that scene using a kerbal, basically storing a global vessel ID to indicate the player entered the scene from a 'vessel' or null if they came from the space center. If the player uses the exit function at the top right the game will load up the space scene focused on that vessel (kerbal) instead of going back to the space center scene, closing the loop and making it appear seamless.

Treating Gilly as if it was a docking target does work. The low velocities involved make things very interesting, I've been able to capture at Gilly for a reasonable amount of fuel despite being in a retrograde Eve orbit. If all else fails get close like you have already plotted and then treat the navball target indicator and relative speed to target the same way you would when trying to reach a space station.

Yeah, I can see that. If you had some weird potato shaped asteroid (maybe one half is composed of a denser substance) then you might be able to have an orbit that would appear like a halo, though I think it would be a big stretch for all the numbers to fit together and not just look silly.

The simple answer is no, you can't. The part about orbits intersecting the equator isn't important, any line that divided Kerbin into two equal pieces would fill the same purpose. To understand remember that an orbit is just falling while constantly missing the ground. The spacecraft is always being pulled down (where down is defined as a line between the ship and the center of Kerbin) but thanks to horizontal velocity the direction of down is constantly changing, translating the previous moments downward velocity into the new horizontal velocity. If you tried to orbit around one pole (like an angels halo over the 'head' of Kerbin) then the downward velocity would not be completely converted into horizontal velocity, so would continue to lose altitude until you hit the ground.

Taking these one at a time: Could you accelerate half way then decelerate for the other half? This is a complex question. Delta-v is not constant time wise, meaning that you could spend 1000 m/s of delta-v in 10 minutes or 10 seconds depending on how powerful your engine is. So in theory you could fit a very weak engine and burn it at minimal throttle the whole way (turning around at the half way point) but it would be far less practical and no faster then just using a proper engine and burning for a few minutes in Kerbin orbit at a much higher thrust, coasting, and then braking at Duna or whatever planet you are flying to. If you are trying to get to another planet faster then burning the whole way is still not practical in KSP - any practical burn will easily be done while still inside Kerbin's SOI. Burning a realistic engine longer then that would fall over into the realm of using cheats or exploits to gain infinite fuel or abuse massless parts and at that point it's still more practical to use those cheats or exploits to make a burn inside Kerbin's SOI and then coast for the few seconds it takes to reach your destination. This does not even get into the fact that you'll likely break the game (Kraken) because of how the floating point numbers work (if you move too fast the numerical precision isn't high enough to keep up accurately) I'm guessing your question comes from several futurist plans where a nuclear powered probe would fly to another star by accelerating to a significant margin of the speed of light in the first half and braking on the second half of the journey. This does not apply to visiting other planets in KSP, the distances are just so small (and you are still heavily influenced by the gravity of the sun) and the attributes of the engines aren't right for that kind of journey to have any benefit over a 'normal' transfer. Could just go any time and not worry about launch windows This is easier to answer. Yes you can go at any time (though in a few isolated cases it may be a shorter trip to wait a short while because a planet is blocking the ideal path and a trajectory around it would take longer then just waiting for the path to clear). The only consequence of going at a different time is the delta-v cost. In fact even leaving at the same time you have a choice in how much delta-v you might trade off to reach your destination faster. You can explore this by looking at the launch window planner. Once you enter a destination and click Plot It you'll get a colored graph showing from lowest cost (blue) to highest (red) departure times and desired travel times. If you move your mouse over the graph you will see how much delta-v that departure time will cost.

To explain this in full lets examine how efficiency is calculated. It is assumed here that efficiency = delta-v. The more delta-v you have the farther you can go (unless you are trying to take off/land, in which case you'll also need a certain minimum thrust otherwise you won't go anywhere). In car terms delta-v is your range, so for example I can drive 350 miles (560 km) on a single tank of gas, or my spaceship can produce 350 m/s of delta-v with the fuel on board. Delta-v is calculated from three numbers: ISP. This is the specific impulse generated for each unit of fuel burned, essentially how much 'push' you get. It is similar in a way to the MPG (L/100km) of your car but ISP does not yet take into account how heavy your ship is. Fuel mass. This is how much fuel you have to burn, more fuel means more impulse adding up. Like with a car if you take your fuel tank size and multiple it by your MPG you'd have an idea of the range of your car. Payload mass. If you load up your car with lots of weight then your MPG will go down because there is more to push. The same happens for spacecraft - your actual range depends on how much weight is stacked up against your ISP. The actual formula looks like this: Delta-v = LN(WetMass / DryMass) * ISP * 9.81 Now the engines you picked actually have very similar ISP (360s, 370s and 390s) and only differ by weight and thrust (how fast they accelerate). To help illustrate how weight and ISP work I've got a little chart here showing how these engines would perform if their ISP values where changed. 300s is very poor, while 800s is very good (same as a nuclear engine). However you can see that even given the poor ISP the very light engine will still get the ship farther. This is because even if the engine is twice as efficient at burning fuel, if you need to carry 3 times the weight it will have less range then the lighter craft. [table=width: 800, class: grid] [tr] [td]Capsule & Fuel Tank[/td] [td]Fuel[/td] [td]Engine[/td] [td]Total Weight[/td] [td]300s ISP[/td] [td]390s ISP[/td] [td]800s ISP[/td] [/tr] [tr] [td]1.1 tons[/td] [td]2 tons[/td] [td]9.75 tons[/td] [td]12.85 tons[/td] [td]497 m/s[/td] [td]647 m/s[/td] [td]1327 m/s[/td] [/tr] [tr] [td]1.1 tons[/td] [td]2 tons[/td] [td]1.25 tons[/td] [td]4.35 tons[/td] [td]1812 m/s[/td] [td]2355 m/s[/td] [td]4832 m/s[/td] [/tr] [tr] [td]1.1 tons[/td] [td]2 tons[/td] [td]0.5 tons[/td] [td]3.6 tons[/td] [td]2386 m/s[/td] [td]3102 m/s[/td] [td]6364 m/s[/td] [/tr] [/table] Now there is a reason these different engines exist in the game, even though the last one is in theory the most efficient in any situation (it has the highest ISP and the lowest weight). That reason is thrust. Thrust is the amount of force being applied by the engine at once (kN). In a way it is related to how quickly the engine is burning fuel and how fast it is applying the delta-v. If you had two engines with the same ISP but one had twice the thrust of the other then it would burn it's fuel twice as fast. In car terms thrust would be speed - both cars might have the same range of 300 miles but one has a top speed of 100mph and the other one can only do 50mph. Once you are in orbit speed (thrust) doesn't matter as much. You aren't going to fall back to the ground so you have lots of time to get where you want to go which means if the slower car has a longer range you can take it. However when you are trying to get into orbit (or land without crashing) you need a certain amount of thrust because you are fighting gravity. Think of it like trying to drive up a hill - that slow efficient engine might not have enough power and it just falls back down. The 3rd engine you picked, the LV-909, has a thrust of only 50 kN. That is very weak and it means that it can only lift a small amount of weight in Kerbin's gravity (9.81 m/s). The actual amount can be easily found by dividing: 50 / 9.81 = 5.81 tons. So if your total mass is more then about 5.8 tons your rocket will just sit on the launchpad because the engine can't get it off the ground. By comparison the largest engine you picked has a thrust of 3200 kN. That means it can lift about 326 tons off Kerbin which is much more useful if you want to build something bigger.

Efficiency is a balance between ISP, fuel and mass. Having the highest ISP engine won't help if the engine contributes too much extra mass. The Rockomax 48-7S is a good example of this. Despite having an ISP of only 350 it is still more efficient then the popular LV-909 and LV-N for many small ships simply because it weighs so little. You can see an example of this here, where the 48-7S can take a little 3 ton ship to Duna and back for less fuel then an LV-909 or LV-N. In fact the question being asked, which of the three designs is most efficient, is answered not based on their ISP but on their weight. The last design, the one with the light LV-909, is the most efficient (>3000 m/s). However it's not because it has the highest ISP. Even if it's ISP was the same as the second one (I'm assuming that's an LV-T30) it would still have about 500 m/s more delta-v just because the engine weighs less then half and that is a significant part of the spacecrafts dry weight. For the same reason the first one, even if it had the same ISP as a nuclear engine (LV-N) would still be last by a huge margin.

The larger icons in stock are very useful for players to learn the game. I think it would need to be a toggle (I think it might be time for the UI size slider in settings to get split into several options - overall size for UI, size for just navball and option for large or small app icons). Of course offering two sizes might require some additions to help authors know where to position windows in relation to the icons size their size might now be variable. Press 'Go Advanced' to switch from the quick edit to full sized edit/preview/etc.

About 500 but it only shows the names of the last 15.

BTSM 1.62 is out and there was a question about how to return Goo using just the tier 4 techs and the heat shield from tier 5. This is how Goo can be returned from Mun orbit using the heatshield for proper reentry rather then any tricks. The first stage requires some more attention throttle control to balance everything since TWR changes by a good margin when the solid boosters cut out and overheating must be managed too. As the gravity turn starts the first stage is released and it slides out from between the side engines which still retain 2 of the control surfaces so that they can still be used to aid in the turn (though I really needed those engines because of the limited fuel tank selection, it was the best way I could find to save weight and add more fuel without breaking my TWR). RCS is activated at this time as well so that we can remain stable on the other axis as well. With orbital speed at 1.4km/s the 2nd stage is released and the third stage takes over. TWR is low at this stage, barely over 1 until some fuel is burned off and even then it's not going to reach 2 during this burn. That means the first burn will need to go on for a while, shooting for a long flat trajectory to put all the thrust into increasing orbital speed. When the AP reaches 74km the PE has already appeared on the other side at 38km. It's a further 6 minutes of coasting before a 31m/s burn to circulize. The ship carries 7 of the type 2 batteries along with a special 100em, 0.5t model in addition to the probe core for a total of 3000em or 5 hours of operation. My estimated requirements where for 1200 m/s of delta-v to complete the orbital portion of the mission and I appear to have 1210 m/s so things are going as planned. An 890 m/s (budgeted 900 m/s) course is plotted to swing close to the Mun with about 10 minutes of battery power to spare. Since it is already on a free return I should need less then the budgeted 300 m/s to correct it into a suitable/survivable return trajectory. Flying to the Mun both Goo containers are exposed in high Mun orbit and low Mun orbit respectively. At the lowest point over the Mun a planned 73 m/s burn is made to alter my return trajectory so I don't slam straight into Kerbin. After the burn is made I have 6 minutes of battery life though I won't be using it, instead the return capsule is released and the probe left to die. The return capsule comes in to 35 km and passes over a familiar location but it wasn't actually enough to stop it (22 units of shielding are depleted). The Orbit has lowered to 437 km and the second time around the capsule makes a successful stop and splashdown in the ocean south of the desert 501 km from KSC. We have successfully return Goo from Mun orbit using tier 4 plus the heatshield (about 2000 funds are refunded for recovery of the craft, mostly the cost of the two goo containers).

If you want to play it through Steam then you need to download it. Steam will let you play your games* on multiple computers as you are only using one at a time (though there is some new sharing/family something feature that I haven't look at yet). Once you download Steam (it's not very big, especially compared to the size of any game) you can choose which games from your library you want installed on that computer. Maybe you can explain what situation exists where you are willing to download and install KSP (>1000mb), enter your Steam login but have a problem installing Steam (<100mb) *Check the information panel on the right side of each game's store page to ensure there is no extra DRM. Some games from publishers like EA may include additional DRM that restricts how many computers you can install the game on.

Given that the game has the Vernor Engine now there isn't a reason we couldn't have the same thing for xenon thrust too, with a radially attached ion engine that is linked to RCS controls like the vernor. It can be lighter and require less power, but produce much less thrust (0.1 kN) at a lower ISP (2000s), making it more useful for satellites and small probes.

I want to draw a simple informational window tied to the application bar (something like the resource, contracts or notification bar app). To the best of my knowledge using the post-drawing queue is the correct way to do this so that it will be drawn along with the other UI elements and be automatically excluded when the user toggles the F2 key. However I don't know what queueSpot represents - is it supposed to be a unique value, is it a depth sorting value, or maybe something else entirely? As a result my current function for determining a 'valid' queueSpot value is a complete stab in the dark.

I want to find out what the queueSpot parameter represents in the RenderingManager.AddToPostDrawQueue method. public static void AddToPostDrawQueue(int queueSpot, Callback drawFunction); All the examples I can find seem to use arbitrary values (0, 1, 3 and 5) without any explaination. I've experimented and found that apart from 0 (which results in my window being drawn even when F2 is pressed) they seem to be the same. I'm not very comfortable just passing in a random value and not knowing what I might be doing. I have seen one mention made about how the RenderingManager class has a field called postDrawQueue which is an array of callbacks and a theory that the queueSpot parameter might be linked to this array. public Callback[] postDrawQueue; Following that logic I tried out this code and it seems to work, but I'd still really prefer to know what the parameter is supposed to be for instead of going on a hunch. queueSpot = RenderingManager.fetch.postDrawQueue.Length; // get next available slot? RenderingManager.AddToPostDrawQueue(queueSpot, DrawFunction); ... RenderingManager.RemoveFromPostDrawQueue(queueSpot, DrawFunction);

With a 50 ton payload you have a little over 3000 m/s using just the orange tank. That would get you to Jool though getting into orbit of anything but Laythe would require a lot of skill. A couple of things: Are you reaching Jool orbit at all? You should have around 800L of liquid fuel left once you reach Jool orbit. If you can't reach Jool with just the orange tank then you may need to examine how you are getting there. Do a search for Launch Windows and Hohmann Transfers. Reducing your payload would help a lot. If you must you can add additional drop tanks with radial decouplers and fuel lines.