Andersenman

Scott Manley recently had similar troubles encountering Moho, . Possibly, some inspiration can be had from that.Then again, I'm curious to see Dave's own, original progress. I really like this series.

Orbital mechanics rarely favour quick ways, if ever. Pretty much anything else than Warp drive rewards or even demands efficiency and patience. As for EVA … either your remaining RCS or possibly something in conjunction with a life support mod that limits a suit's energy and implies a finite EVA time. Then again there is not much activity on stock KSP that demands significant EVA work where a suit's capacities could run dry … save for "get out and push" shenanigans where you need to concentrate on aiming the Kerbal with the mouse and pressing W to push – looking at your watch would be more hassle than benefit, easily even treacherous … like using your mobile while driving. An example for a modded EVA scenario would be using KAS to transfer the gains from a Kethane refinery to a waiting tanker-to-orbit in Kerbal Multiplayer.

Very nice! Seeing so much commitment is almost like making the trip myself! Also, those mission profile sketches are adorable!

Since obtaining information from a wristwatch occupies your hand and eyes, and both are needed constantly for playing KSP, you would probably want to keep it for use when you are away from your PC. Maybe less so if it can produce audible output, but still. So how does one play KSP away from keyboard? Since space flight is mostly waiting, something that is usually skipped with time acceleration, the only thing I can imagine would be real-time missions. Something like the guys who did the Mun landing. Or perhaps an ISA Mapsat mission that keeps running while you're out and somehow connects to the Pebble to tell you it has found an anomaly. Apart from that, I'm not sure how much the rather specific usability would enhance playing KSP.

Majiir, you've been doing awesome things for an eternity of KSP's existence, have been tending to one of KSP's most popular mods, and have ascended to a recognised fellow within the KSP community … – how do we know you're not actually the same guy behind Istvaan Shogaatsu?

Simple and clear explanation, Alistone! I especially like this part: Rules-of-thumb, scientifically sound enough and easy to grasp at the same time, making KSP enjoyable to play!

I have tried, but never had a hit. On many attempts I couldn't even hit targets in orbit from orbit within default loading distance. I presume that Lazor Missiles are not designed to follow orbital mechanics.

To clarify this: I did not mean to refer to high-Ap sub-orbitals alone, but ANY sub-orbit that ends in a full burn and a touchdown without unnecessarily extensive lingering, and also why the node system isn't always accurate enough to be considered helpful in planning such landings.

I like that you keep this craft updated!

This is what the node system has been helpful with. It only starts to make me stop short the higher and faster I'm coming in. Put a node above the target, guesstimating surface rotation as needed, pull retrograde until your new orbit drops you steeply onto your destination, then burn like in the video (ie. ignoring the blue node marker), starting at time-to-node minus burn time. So far the node method had been making me stop short while Kosmo-not's method looks like it takes ages to stop laterally – I wouldn't be surprised if both together would cancel out somehow and make for a half-accurate landing after all. Try it! (While I'm sitting at work.) Oh, and please do tell how it went.

Just to confirm: "Gravity loss" is essentially the decrease in speed I see along a non-circular orbit on the way from Pe to Ap? And likewise, the increase in speed from Ap to Pe would be a "gravity gain"?

I'm trying to understand, but you're confusing me: As I understand, I always have to counter gravity, regardless of my radial movement: If I hover, I have to spend full dv against gravity. If I'm flying sub-orbitally, I have to spend some dv to prevent "not missing the ground while [not quite] falling". Only when I'm truly orbiting, I don't have to counter gravity with thrust. ... with these three cases applying at any altitude, and any change in altitude. Right? So why are you saying that I wouldn't need extra fuel to counteract if I was maintaining altitude? Also, I am trying to understand landing (and launching for that matter) as an orbital change that moves the apoapsis from one altitude to another by burns roughly around the point where the orbit happens to intersect surface. Is this wrong somewhere? And just to make sure, I'm not arguing for a particular landing method, I'm trying to understand where I might be wrong; and ultimately, what fudge factors I need when interpreting the manoeuvre node system's burn times and times to node. (I believe that it should work somehow as I have seen that it becomes more and more accurate the shorter the burn time, the flatter the trajectory and the smaller the time to node.) Seen and marvelled at. Higher algebra is sadly not one of my strengths which is frustrating knowing that Maths never lies ...

All good! Easy does it!

Many thanks for all your input. I will try some more landings, including said old challenge to get some comparable results. Safe landings! A.

But if it didn't, why does the half-half burn work for other orbital changes? If the burn calculator couldn't work with variable TWR, the actual burn time would ALWAYS be less than what was calculated. But that's not the case: When the node says, "Burn X seconds", the orbital change is done after X seconds regardless how much TWR changed during burn - if at all, since it works with Infinite Fuel, too. But don't those apply to movement in straight lines in a force-free space only? Starting to brake early should solve that. I don't mind suiciding to a few metres above ground. Plus, since I have always been coming in short so far this hasn't become a problem yet. I know, but again, shouldn't the node system already be factoring this in when giving me a simple burn time for my current craft and the point on the current orbit?

Hello, I am trying to perform suicide burns in a stock game. I figured, if I place the node right onto the surface and pull retrograde, it would eventually show me the burn time needed to stop whatever speed I would have where my original orbit would have intersected with the surface; but instead of performing the burns half-half around the node, lithospherical reasons would dictate to perform the entire burn before the node. This is (generally) what I'm trying to do. However, this doesn't work and I don't understand why. I always stop much earlier, canceling ALL orbital speed far above the ground. The discrepancy is larger the higher my vertical speed at the node, and possibly the more my current speed differs from the speed at the node; ie. it appears to be worst when I'm coming straight down. Also, it is always much larger than the orbital speed on the surface due to rotation. Please help me find the mistake in my reasoning. Many thanks! A.

Funny enough, that was the "accidental" functionality of the Timer in the first release: Slap it onto the stage of choice and it fires the AG when the stage is activated. The problem was that you couldn't use it for delayed chute deployment, so this "feature" was "fixed". Granted, it is a rather specific application.

Many thanks!! All the best, A.

Maybe not quite. Instead of not activating at all during staging, maybe it should merely start listening for AG events? That way one wouldn't need to waste an action group to trigger the timer for something that is being dropped by staging anyhow - this, and binding the timer to Action Group "Stage" would fire the countdown during ANY staging even when the timer isn't needed until much later. So, the default behaviour could be "Start listening upon staging", and a Tweakable switch could offer the two other possible modes "Dont' react to staging at all" and "Start countdown right away".

How exactly is this supposed to work? I am having trouble replicating just that functionality: Decouple spent boosters and have their chutes deploy with a delay. Problem: The Timer starts running when the stage is activated where it is attached. However, if the Timer is attached to the NEXT stage, it cannot trigger the action groups of the detached boosters. [table=width: auto] [tr] [td]Steps to reproduce: 1. Launch game, visit VAB. 2. Pick any probe body 3. attach an SRB underneath 4. attach a radial decoupler to the SRB 5. attach an SRB to the decoupler 6. attach a chute to the radial SRB 7. attach the TIMER to the radial SRB 8. grab decoupler, use Symmetry to multiply them to have at least two strap-on boosters. 9. assign action group 'ABORT' to chutes 10. make the TIMERS trigger action group 'ABORT' 11. move all chutes to separate stage 0 so that they are not opened by regular staging 12. leave other staging at default (should be: 3. strap-on SRB, 2. radial decouplers, 1. center SRB) and launch vehicle 13. note chutes triggering after strap-on boosters have ignited 14. Revert to VAB 15. remove TIMERS, attach them to central SRB 16. leave staging unchanged and launch vehicle 17. proceed through staging until central SRB lights up 18. note TIMER activating after set time (see light) but booster's chutes remain closed[/td] [td][/td] [/tr] [/table] So how do I do this exactly?

Hello Romfarer, Could you please add a button to collapse and expand the info section for the Target Cam? I rarely have the need to see the info at all times, and the huge height severely limits placement of the cam feed on the game window. Also, would it be possible to save window arrangement and default values (eg. for the proximity fuzes) somehow? With all the options, using the Lazors often starts with quite the clickfest at every launch, so anything to reduce that would be most appreciated. Finally, in what order need Lazors, Sunbeam and Missiles installation? I have sometimes seen differences in dll date but not version between those mods. Many thanks! A.

Ohh, this opens worlds, thanks! I shall, however, paint some blue over the orange casings to be more stock-alike; my Kerbals fear change. Something like that could be useful as a simple SOI change detector when someone doesn't want to use kOS or the like.

Would you mind explaining such a calculation here? Thanks!

Aside from Tony Probe, this is easily the smallest interplanetary craft I have ever seen!

If Eve ever DID get a Venusian atmosphere, with all consequences and implications, those panels would do jack-all under those impenetrable clouds. You would have to stay high enough and never land without humongous EC capacities.