Thanny

If you plan on returning, Duna, and only Duna. You can aerocapture to avoid almost all of the insertion burn (shoot for slightly above 12km, then adjust and circularize, unless you want to spend another orbit adjusting periapsis and aerobraking further). And you can absolutely land on nothing but parachutes. It adds weight that you'll need to haul back off the surface, but that part is pretty easy, especially since you won't need to burn any fuel on the descent. And if you do your de-orbit burn while attached to the main ship - you are using a separate lander, right? - you can detach and burn the main ship back into orbit, leaving your lander with no fuel loss at all on the ground. Eve is just about as easy to get to, and requires less parachutes to land on, but the high gravity makes landing more perilous for ship integrity (when you're done adding struts, add some more struts), not to mention insane fuel requirements for ascending back to orbit. To mitigate the latter problem, you need to exacerbate the next to last problem by landing on elevated, uneven terrain. My first attempt couldn't land without breaking at least one engine, so I gave up and sent the ship back to Kerbin. Still waiting on my monstrous second attempt to get to its launch window (or fourth, rather, as I had two previous attempts in earlier saves that I pretty much abandoned with KSP update releases). And while Eve requires a ton of delta V to leave the surface, Moho requires a ton to get there and back, whether or not you land on the surface. So I'd say Duna if you intend to land at all.

I did some experimenting in sandbox mode, by launching the same 180t ship over to the runway several times and dumping different amounts of fuel to change the landing mass. It definitely depends on both mass and velocity. In one case, I landed 132t at 4.2m/s with no explosion. I then landed the same mass (actually <100kg less) but with some chutes disabled so the final velocity was about 4.47m/s, and that destroyed the runway. So that's ~554kNs momentum in the first case and ~589kNs in the second. Based on a couple other flights, I'm guessing the line is somewhere close to 580kNs momentum. So if I wanted to land that 382t ship safely, I'd have to drop it to 1.5m/s or below, which would be challenging to say the least. Clearly both the runway and launchpad need to be greatly strengthened. And they need to stop exploding, tossing 382t ships into the air, when they are damaged.

After another tanker run, I saved just before chute deploy to try powered descent. I got the 382t ship in the last video down to 2.4m/s before touchdown, and it still detonated the runway. I might do some experiments in sandbox mode to see just where the line is. In the meantime, I'm killing destructible buildings until they dig the bombs out of the runway.

In the settings of 3.0.0.6, you can't independently change time margins for each alarm type and its quick alarm version. Change the value in one field, and the other is immediately updated to copy it. Actually, it looks like it saves the settings correctly, but you can't see it. So I enter 5 minutes for quick maneuver alarm, and it overwrites the value in the entry field for the normal alarm offset. Then I put 10 minutes in the latter, and it overwrites the value in the quick alarm offset entry field. However, when I add a quick alarm, it's at 5 minutes out from the node.

KSP is contriving to make me a madman. I cannot reproduce that problem now at all. I should have done that before posting in the first place. Got it to reproduce after switching ships a couple times. The screenshot, and KSP's log, which has some KAC/TWP-related exceptions that may or may not be relevant.

When controlling a ship, KAC 3.0.0.6 show 0s for all alarms when this mod is also installed. The correct times are shown at KSC. The correct times returned to the ship view as soon as I disabled TWP.

There may be an issue loading KSC with 3.0.0.6. When first loading a saved game, I get stuck on a zoomed-in view of KSC where nothing is clickable. If I jump to a ship with KAC and back to the space center, it still doesn't work. Furthermore, I can't even click on the menu after exiting that save. This happened twice in a row just now. Then I hid the KAC window and restarted the game, which loaded KSC normally. It could still be coincidental. I noticed this problem starting a couple days ago. I don't recall exactly, but it may have been after both the upgrade to KAC 3.0.0.5 and the installation of Blizzy's Toolbar. I know the latter did trigger a spurious incompatibility window for PreciseNode. My full list of mods (directory name): 000_Toolbar EditorExtension EnhancedNavBall KerbalEngineer PreciseNode ThunderAerospace (TAC) TriggerTech (KAC) If I'm able to consistently tie the problem to the KAC window being open in KSC, I'll post an update.

Same kind of engine is irrelevant, unless you're actively tracking fuel quantity to determine if it will run out before the burn is complete (which is still a tractable problem, but considerably trickier). Thrust and Isp work out the same regardless of fuel type. Correct orientation is another matter entirely, one in which the word "simple" is surely absent. But I don't believe that situation happens at all frequently. No sensible design has simultaneously active throttled rockets pointing in different directions. I would simply add up active engines with a current non-zero fuel supply, and assume they're pointing in the correct direction. This is, after all, just a tool for someone to pick an appropriate alarm offset for a maneuver node. It doesn't need to duplicate the kind of information Kerbal Engineer produces.

Now I understand what you're talking about. I think that rather than try to muck about with buttons on the stock maneuver node interface, it'd be be better to have Orbit+/- on the PreciseNode window somewhere. Probably next to the time change button, but styled distinctively so it's obvious what it does.

I recently worked out the whole burn time calculation for my own purposes, and it's really not that difficult, provided you draw a line somewhere (i.e. base it on the current stage only). Assuming no stage changes and no running out of fuel, you need this information: Mass (tonnes) Delta V (m/s) Thrust (kN) Specific Impulse (s) Kerbal Engineer has all that information, but I've only glanced at the source, so I'm not sure how much is directly exposed and how much requires part iteration. Assuming you have to calculate combined Isp, that's just total thrust of all engines divided by the sum of thrust/Isp for each. First, with the thrust and Isp, you determine the fuel burn rate by mass: Fb = fuel burn rate Isp = combined specific impulse T = total thrust Fb = T / (Isp * 9.82) The time you want for the alarm is when half the burn is complete plus some buffer. And the half that's relevant is half the delta V. Using the Tsiolkovsky rocket equation, the final mass of the ship after the half-burn is this: Me = end mass Mi = initial mass Dv = delta V Isp = combined specific impulse Me = Mi * exp(-(Dv / 2)/(Isp * 9.82)) From that, the total fuel mass consumed: Mf = fuel mass Mf = Mi - Me That means the time taken is: t = Mf / Fb The total burn time can be calculated in the same way by using total delta V instead of half delta V in the equation. That works for any engine type. If you want to look at whether or not there's enough fuel, the relevant values: LF+O = 200 units/tonne Mono = 250 units/tonne Xenon = 10,000 units/tonne With LF+O, LF is 9/20 of the total, and O is 11/20 of the total. You'd need to solve the rocket equation for delta V instead to handle running out of fuel and staging. It's doable, but an added layer of complexity, including knowing how much mass each stage will have. Again, that's something Kerbal Engineer knows, but I'm reasonably sure it iterates through the parts to figure it out.

There seems to still be a compatibility check problem with the latest version. After I installed the Toolbar plugin (as in, quit, install Toolbar, restart), a window started appearing on startup saying that PreciseNode isn't compatible. It still works, however, so it's basically a cosmetic problem.

I think he's making a joke. That it'd be nice to right-click to fix your mistake when you've overshot.

So as I indicated, I added more chutes (744 radials, 8 XL's) to a tanker I sent up to refuel my depot. The result is a 480t lander (versus ~170t for the first one) with a final descent speed before impact of 4.34m/s. I've lazily put together another amateurish video showing the result: Since the game engine is really bogged down by the ship, I started in the middle of the descent, and sped that up by a factor of 10. The rest is running at 1x speed, which is quite slow due to the part count (my subjective impression is that large numbers of parachutes have more of a deleterious effect than any other part type). Unlike the first ship, this one, had it survived intact, would have justified the runway repair, having a value beyond 1.6M (32K repair divided by 2% penalty). I think I'll be skipping the runway for any remotely large ships until they send in the bomb squad to make it safe again.

There are quite a few problems with this statement, not least of which is the fact that the video isn't silent, as anyone who actually watched it would know. Which is a shame, because I'd like to explain why every single thing you've said is wrong.

I decided to try a few tanker designs out to see whether or not SRB's really do beat out SSTO for efficiency. The last tanker I used to load up my fuel depot contributed about 340t of fuel at a cost of about 10.5 funds/unit of LF (plus matching oxidizer). That's the cost of the burned fuel and the discarded SRB's, as the rest of the ship is recovered at 100%. I loaded up MechJeb with my sandbox save just to check if my ascent were reasonably efficient, and it put the same ship in orbit with about 500 units less fuel than I had with my last manual ascent (about a 1.5% difference). I tried a handful of SSTO designs around the same basic shape - a central stack of Kerbodyne tanks on top of a KR-2L, surround by four or eight truss-attached additional Kerbodyne stacks on top of KS-25x4 engines. The number and size of tanks in each stack were varied, which changed total fuel amount and TWR. The best efficiency I got was about 11.9 funds/unit of delivered fuel, with a design that started at a TWR of 1.2. The same design with more or less fuel did worse. That most efficient SSTO design delivered only 120t of fuel, and had about a 35% higher launch cost. I also took one of the designs that ended up at about 15.2 funds/unit (for about 120t fuel) and added a bunch of SRB's. Total deliverable fuel was 410t, at a cost of 10.4 funds/unit. So I'm pretty convinced that chucking SRB's at the problem of large payloads is far more cost efficient than any SSTO. I don't know if I could even build a SSTO big enough to get the same fuel payload. And if I could, it'd have so many more parts that docking would be more painful than it already is.

Each individual part test often doesn't justify launching a whole rocket, true. But take a whole bunch of them, and try to squeeze them all into the same flight. And beyond that, try to make the flight useful for your own ends. You do a half-dozen part tests on one flight, and the rewards add up pretty quickly.

Putting your rocket bits down on the runway is the easiest way to get 100% recovery, so that's what I've been doing since 0.24 came out. It takes a bit of practice (and sometimes a few reloads) to get it right on the runway with no extra burns, but it's a lot easier than trying to hit the launchpad. Today I discovered that since 0.25, there are perils to this approach with larger ships: I'll be sending a tanker up to my fuel depot soon, so I'll see if adding more chutes to bring the descent speed down makes a difference.

My contract history disappeared with the 0.25 update. I don't have any contract-altering mods.

I play on a big screen (2560x1600), where all parts in each section were always visible, so I was caught off guard when the increased number of parts pushed some to different pages. There's a funky arrow at the bottom to go to the next page.

The largest SRB produces a bit more impulse than a Mainsail with 200X-16 and 200X-8 tanks, for less than 20% the cost. That SRB costs about 160% of the amount of LF+O that does the same job with a pre-existing engine, but when you factor in the need for more tanks and engines, as well as even more LF+O to lift the LF+O you're adding, disposable SRB's become quite cost effective. You can tune the thrust to avoid going too far over or under terminal velocity, and if you use enough, you can avoid even firing your LF engines until about 10km, about when you start your turn. That makes it a lot easier to keep all tanks and LF engines, where the bulk of the money is, in stages that make it to orbit so they can be returned for a refund.

Apparently these tiny little programs qualify as an "add-on", so I need to add that they are in the public domain. Anyone nerdy enough to use or modify them is more than welcome to.

The language is called UserRPL. It's basically typical programming language structure combined with Reverse Polish Notation (e.g. instead of doing "2 + 2 =", you do "2 2 +"). I personally can't stand to use non-RPN calculators anymore, ever since I got my first 48GX in 1993. Once you get used to stack-based RPN, everything else becomes inefficient and counter-intuitive.

As many are no doubt frequently aware, the game won't show an estimated burn time unless the engines have been fired in that particular session (i.e. you haven't switched ships or just loaded a game). Probably fewer are aware that the estimate shown is wrong - it's showing a simple F = ma calculation, which doesn't account for fuel burn at all. This doesn't matter much for short burns (say anything under a minute), but it adds up for long burns. While there's probably a mod or two that does this, I decided instead to do a bit of research, and I found the Tsiolkovsky rocket equation. I then created a simple program on my HP 50g to use it for calculating actual burn time. I also wrote a REXX program on my PC that both repeated the calculation and ran a simulation to check its sanity (i.e. do 1000 burns per second using F = ma, deducting fuel at each step). I then thought about it a bit, and wondered whether the burn should be split around the maneuver node by time or by delta V. After a few responses to my question on that topic agreed with my intuition, I had a minor geek out and fancified the burn time calculator for my HP calculator. I also wrote a couple companion programs, one that calculates the combined Isp of a set of engines, and one that calculates the fuel burn rate of a set of engines. If you have no idea what a HP RPN calculator is, you probably couldn't care less at this point (if you've even read this far). I'll simply say to those people that you don't actually need such a calculator to use these programs. You can simulate several such calculators on your PC with a program called Emu48, and at least one of them is available on (probably) any Android device with the Droid48 app. I've tested the programs on emulated 48GX and 50g calculators as well as a real 50g calculator (my two real 48GX calculators are broken, unfortunately). Here's an archive that has all the relevant files. That includes *.rpl source files suitable for use in HPUserEdit, binary program files suitable for import directly on calculators (real or emulated - *.48.hp for HP48 calculators, *.49.hp for HP49/50 calculators), and pure ASCII text files. The latter I'll post here: \<< "KSP Burn Time" { {"Mass:" "Mass of the ship (tonnes)" 0} {"Delta V:" "Required velocity change (m/s)" 0} {"Thrust:" "Total thrust (kN)" 0} {"Isp:" "Combined specific impulse (s)" 0} {"Type:" "Type (1=LF+0, 2=Mono, 3=Xenon)" 0} } {2} {NOVAL NOVAL NOVAL NOVAL 1} {NOVAL NOVAL NOVAL NOVAL 1} IF INFORM THEN OBJ\-> DROP 200 250 10000 9 20 / 11 20 / 0 0 0 0 0 0 0 0 0 0 0 0 0 0 \-> INITMASS DELTAV THRUST ISP ETYPE FUELDENS MONODENS XENONDENS LFRATIO OXRATIO HALFDV HALFMASS FINALMASS BURNRATE HFUELMASS FUELMASS TOTALBURN FIRSTBURN SECONDBURN FUELTOTAL LFTOTAL OXYTOTAL MONOTOTAL XENONTOTAL \<< THRUST ISP 9.82 * / 'BURNRATE' STO DELTAV 2 / 'HALFDV' STO ISP 9.82 * INV HALFDV NEG * EXP INITMASS * 'HALFMASS' STO HALFMASS NEG INITMASS + 'HFUELMASS' STO HFUELMASS BURNRATE / 'FIRSTBURN' STO ISP 9.82 * INV HALFDV NEG * EXP HALFMASS * 'FINALMASS' STO FINALMASS NEG HALFMASS + 'FUELMASS' STO FUELMASS BURNRATE / 'SECONDBURN' STO FUELMASS HFUELMASS + 'FUELMASS' STO CASE 'ETYPE==1' THEN FUELMASS FUELDENS * 'FUELTOTAL' STO FUELTOTAL LFRATIO * 'LFTOTAL' STO FUELTOTAL OXRATIO * 'OXYTOTAL' STO END 'ETYPE==2' THEN FUELMASS MONODENS * 'MONOTOTAL' STO END 'ETYPE==3' THEN FUELMASS XENONDENS * 'XENONTOTAL' STO END END FIRSTBURN SECONDBURN + 'TOTALBURN' STO FIRSTBURN 2 RND "DV/2 (s)" \->TAG TOTALBURN 2 RND "Time (s)" \->TAG CASE 'ETYPE==1' THEN LFTOTAL 2 RND "Fuel (u)" \->TAG OXYTOTAL 2 RND "Oxy (u)" \->TAG END 'ETYPE==2' THEN MONOTOTAL 2 RND "Mono (u)" \->TAG END 'ETYPE==3' THEN XENONTOTAL 2 RND "Xenon (u)" \->TAG END END \>> END \>> \<< 1 0 0 0 0 0 0 \-> ENUM ECOUNT CTHRUST CISP TTHRUST TRATIO LOOPDONE \<< DO "KSP Total Isp - Engine " ENUM \->STR + { {"Thrust:" "Engine thrust (kN)" 0} {"Isp:" "Engine specific impulse (s)" 0} {"Count:" "How many of these engines?" 0} } {} {NOVAL NOVAL 1} {NOVAL NOVAL 1} IF INFORM THEN OBJ\-> DROP 'ECOUNT' STO 'CISP' STO 'CTHRUST' STO TTHRUST CTHRUST ECOUNT * + 'TTHRUST' STO CTHRUST CISP / ECOUNT * TRATIO + 'TRATIO' STO ENUM 1 + 'ENUM' STO ELSE 1 'LOOPDONE' STO END UNTIL LOOPDONE END IF 'TTHRUST>0' 'TRATIO>0' AND THEN TTHRUST 2 RND "Thrust (kN)" \->TAG TTHRUST TRATIO / 2 RND "Isp (s)" \->TAG END \>> \>> \<< 1 1 0 0 0 0 0 0 0 200 250 10000 9 20 / 11 20 / 0 \-> ENUM ETYPE ECOUNT LOOPDONE CISP CTHRUST LFOBURN MONOBURN XENONBURN FUELDENS MONODENS XENONDENS LFRATIO OXRATIO LFOTOTAL \<< DO "KSP Fuel Burn - Engine " ENUM \->STR + { {"Thrust:" "Engine thrust (kN)" 0} {"Isp:" "Engine specific impulse (s)" 0} {"Count:" "How many of these engines?" 0} {"Type:" "Type (1=LF+0, 2=Mono, 3=Xenon)" 0} } {} {NOVAL NOVAL 1 1} {NOVAL NOVAL 1 1} IF INFORM THEN OBJ\-> DROP 'ETYPE' STO 'ECOUNT' STO 'CISP' STO 'CTHRUST' STO CTHRUST CISP 9.82 * / ECOUNT * CASE 'ETYPE==1' THEN LFOBURN + 'LFOBURN' STO END 'ETYPE==2' THEN MONOBURN + 'MONOBURN' STO END 'ETYPE==3' THEN XENONBURN + 'XENONBURN' STO END END ENUM 1 + 'ENUM' STO ELSE 1 'LOOPDONE' STO END UNTIL LOOPDONE END IF 'LFOBURN>0' THEN LFOBURN FUELDENS * 'LFOTOTAL' STO LFOTOTAL LFRATIO * 2 RND "Fuel (u)" \->TAG LFOTOTAL OXRATIO * 2 RND "Oxy (u)" \->TAG END IF 'MONOBURN>0' THEN MONOBURN MONODENS * 2 RND "Mono (u)" \->TAG END IF 'XENONBURN>0' THEN XENONBURN XENONDENS * 2 RND "Xenon (u)" \->TAG END \>> \>> All use the INFORM command to collect input. Burn time asks for ship mass in tonnes, required delta V in m/s, total thrust in kN, combined Isp in seconds, and fuel type (1 = liquid fuel + oxidizer, 2 = monopropellant, 3 = xenon). The mass is available on the map screen with the info button, when the ship is focused. A mod like Kerbal Engineer will also show the mass (more accurately, too), as well as current thrust and Isp. The latter two can be calculated with the Isp program provided here (detail further on). Choosing the fuel type simply lets the program show you how much fuel is required for the burn. The output: DV/2 - time at which half the delta V has been reached, which is how long before the maneuver node you should start the burn. Time - total time of the burn - note that time/2 is less than DV/2 Fuel/Oxy or Mono or Xenon - units of given fuel type required for the burn The time values will be accurate regardless of the engine mix, provided the correct combined Isp is provided. The fuel quantities will only be accurate when all engines use the same fuel type. I decided it would be too tedious to collect engine information for each burn calculation, which is what would be required to show different fuel types. The Isp program asks for one or more engine stats. Press OK after each active engine has been described (thrust, Isp, count, and fuel type), then press Cancel to stop entering engines and do the calculation. The ouput: Thrust - total thrust of all entered engines Isp - combined Isp of all entered engines The fuel program shows consumption for one or more engines. Input is similar to Isp - press OK after each engine, then Cancel to do the calculation. The output: Fuel - units/sec of liquid fuel Oxy - units/sec of oxidizer Mono - units/sec of monopropellant Xenon - units/sec of xenon If you have mixed engines, you can multiply the return values here by the total burn time to figure out how much fuel of each type is required for the burn. Hopefully someone besides me will get some use out of these programs.

So the maneuver nodes work on the premise that you're velocity is changing instantaneously. Hence the advice to straddle the node, doing half the burn before, half after. But half of what? Half of the total burn time, or half of the delta V? For a long burn, those will be two notably different answers, as the acceleration is higher near the end of the burn than near the beginning, on account of fuel mass being reduced. As an example, consider a 350 tonne ship that needs to do a 2500m/s burn using twenty nuclear engines (thrust = 1200kN, Isp = 800s). The total time of that burn will be 624.53 seconds, making the time midpoint 312.27 seconds. However, the delta V will reach the halfway point of 1250m/s at 337.06s into the burn. So which do you think would provide the least deviation from the intended maneuver node result, starting the burn at -05:12 or at -05:37?

I'm not so sure that it's all that rare. Due to some glitch I have to attribute to 0.25 coming out while I was loading the game (I launch outside of Steam), I found myself losing a ship due to a spurious missing part. After going back to a previous save, I found that the ship in question had actually missed a maneuver node. In going backwards previously to reverse an orbit change bug, I went back far enough to undo that node for that ship, but because KAC stores its alarms in a separate file, the alarm didn't come back with it (which will be a problem of the past when I switch to v3). So now I had to go back further, and the first save I found before that maneuver node (3h+ before it) had the orbit bug. That is, the orbit for that ship was off where it was, and it would no longer intercept Kerbin after the maneuver. The next nearest save was 60 days previous, where the orbit was on track. So that's three cases of a changed orbit in this career that I noticed. The best strategy I can see to avoid it is to always do high speed warps on the map screen, and look for screwed up orbits afterwards - the ones that matter will typically be obvious intercepts that no longer reach their targets.