Hesp

Updated my plane with the Whiplash engine and a new revision of control surfaces to guarantee stability at Mach 3+ Test was concluded successfully after hitting Mach 4.5 and not burning up with Deadly Reentry

The best way to check is to put on a PresMat barometer on your craft and fly up there Anyway AFAIK FAR doesn't change pressure values or scale height, and the threshold for 0.3 bar should be around 8000m altitude.

Near the end of the discussion there is a link with a 1.2 compatible version

Mission update: Asteroid captured. It's on the upper limit of the B class (40 tons), so I had to plan carefully the burns to relocate it in equatorial orbit. Exploration will follow.

Thanks! Yes, B9 Procedural Wings.

I made a Kerbin research plane that I'm really proud of: It can fly easily all around Kerbin at Mach 2.7 and 23km altitude, probably the most efficient way I ever used a Panther. It keeps that speed and altitude without corrections at 6.7° pitch and full afterburner (means 4x warp and no supervision during flight). It is also very manouverable at super- and subsonic speeds and can land at a reasonable speed (75 m/s with full tanks, 60 m/s empty). Mk1 cargo bay holds all the science instruments I could fit into - including DMagic ones. More pics in the spoiler

Found a B class asteroid with an orbit very suitable for capture (400km Pe, Ap right out of Kerbin SOI, almost polar inclination)... So I decided to launch the first asteroid mission of the career save The capture ship is unmanned, basically a big tank with a 455s isp Lox/LH2 engine, RCS and reaction wheel. Timed launch was nominal, after a couple of small corrections I matched planes and asteroid periapsis. Now I'll wait some days for a final periapse kick to reduce relative velocity at rendezvous. Approach manouvers are planned to use 420m/s of deltaV, so depending on the asteroid mass (still unknown) I will have between 1830 and 716 m/s available for capture and orbit modification. Should be enough to obtain a stable equatorial orbit with Pe 500km and Ap lower than Mun SOI.

Actually, this is the most efficient way to launch if you don't have to perform operations in low orbit. Just look at the latest Soyuz launch profile to GTO https://spaceflight101.com/soyuz-vs16-launch-success/ It could be harder than it looks for the software, since a variation in TWR will lead to different gravity turns and ejection trajectories...

Hi, I've been using the dev version for the last month. Everything worked seamlessly, but yesterday i found a small problem. Not sure if FAR is involved in this, though. Maybe you can help me sort this out. Premise: it's an experimental career game with lots of mods installed. Got a contract for planting a flag on the Mun. Got there, and during the planting animation the flag was not visible and there was an explosion. The kerbal was stuck in place. I had to reset the input locks and change scene. When coming back, everything was fine except no flag present, of course. The contract was marked as completed anyway, so that's just a minor annoyance. I ran through the log and the last thing happening before the explosion is a voxelization operation. I'm not home now, but I can attach the log extract later this evening. FIrst flag planting of the career, so I couldn't notice this problem before.

I had a surplus Duna rover and decided to misuse it by landing on Minmus. It was designed for a remote chute landing, so I had to use the deorbit stage throughout all the powered descent. With almost no attitude control I had to slow it down to a safe speed and cross my fingers.. tumbled a bit before reaching a complete stop without damages. Time for some exploration!

You can use docking ports for staging AFAIK, with the in-flight staging that you have, the nuclear is set up to burn all the liquid fuel in the ship (that's why KER says 4845m/s > 4220 in VAB). When you stage it, the sparks are stuck with only oxidizer and the remaining dV is zero. Try to disable the docking port crossfeed.

Oh haha sorry for that!

Probably yes, I didn't consider the 47 extra days. Changing subject, the manouver node didn't appear during reentry but I noticed an Astrogator spam in the alt+F12 console: http://imgur.com/a/WvLKc

You're welcome! I'm using it in career, so as soon as i have a rocket on the launchpad I'll check also the node spawning bug The game date is Y1D235, so 4 days past the "sweet spot" to Duna from Munar orbit. The main issue was that the generated node was completely off. Looking at the screens it was ejecting me 90° from prograde. Just tried to set up a Mun-Minmus transfer from retrograde: the main ejection seems right-ish - no encounter but after few small corrections I got it.

For the suboptimal transfer, ok! Just wanted to be sure The orbit raise and circularization would be more efficient with the nuclear, actually The only difference I see between the VAB and the flying ship is in the staging - check it!

1st point: are you in the correct transfer window for Dres? Using this tool https://alexmoon.github.io/ksp/#/Kerbin/100/Dres/100/true/optimal/false/1/1 the optimal dV for a Dres encounter should be around 1800 m/s 2nd point: making your transfer burn so far away from Kerbin will make you lose way more dV (lack of Oberth effect). People more proficient than me with orbital mechanics will explain better for sure. All that matters is finding a reasonable orbit for your ejection burn. 100km with your TWR is giving you huge steering losses. Just circularize it higher (500 to 1000km) and then send a small tanker to refuel!

First feedback for the new version: dV for retrograde orbits are calculated correctly: I got 422 m/s for a Mun-Duna burn that matches my previous launches in the current transfer window. There seems to be an issue with node placement though: the final trajectory is nowhere close to a Duna encounter. Screenshots attached: http://imgur.com/a/yFdcC Actually it places the manouver 2y, 47d in the future while the correct timing (due to Mun position around Kerbin) is in about 2 days. Thinking a bit more, 2y47d is the next Duna transfer window. This could leave room for improvement. What about an option like "calculate dV for a transfer within X days" instead that giving only the best dV attainable?

As @Streetwind and @Rhomphaia said, the manouver node is calculated for an istantaneous burn, so that all your dV burned is oriented prograde. Let's make an example with your final 10-min burn (i'm approximating values) During 10 mins in LKO your ship sweeps about 120 degrees of the orbit. This means that you start the burn pointing 60 degrees away from prograde. Trigonometry says that cos(60°) = 0.5, so only half of your dV goes prograde. During the burn your angle to prograde decreases till you reach the node (cos(0°) = 1), then increases again. The 26.8% loss is perfectly understandable. As i said before, try the burn starting from 1000km orbit. The total swept angle for the same 10 minutes manouver will be 30 degrees, and cos(15°) = 0.966. I would expect a loss around 2-5% accounting also for human inaccuracy.

The wasted dV is caused by burning off-prograde. (damn trigonometry!) A reasonable limit for long burns is about 1/6 of the orbital period (about 5 mins in LKO) Try to raise your departure orbit to 1000km, with an orbital period of 1h52m you will be able to complete the burn just fine. Anyway, there is a topic about Oberth effect that introduced me to the concept of Gate Orbits. Have a read at all the discussion:

Regarding the high inclination orbits, I totally agree with you. They can be ignored when looking for transfer windows. The manouver node still pops up as soon as I hit spacebar for launch, even with the new release. It appears also when: - your Pe gets inside atmosphere - you actually reentry in the atmosphere I tried to take a series of snapshots while performing the reentry burn, hope it helps: http://imgur.com/a/Wrfsv

Excellent tool, thanks! Is there any software limitation in computing nodes while in retrograde orbit? Looks like you have to be within 30° from a prograde orbit for it to work. Yesterday I launched some vessels from Mun station (retrograde orbit) to Duna, and I'd like to check the tool's efficiency with these transfers vs. manual node placement. As for the reported bug, I saw a node spawn also during a manual deorbit burn (definitely not a big issue, but maybe is useful for tracking down the problem). This evening I'll try with the new release.

Probably I need to review the calculations, I got an ejection burn Mun-Duna of 413 m/s. Better than expected! http://imgur.com/a/Yb5Us

True, but usually acceleration capabilities of the ship improve when the propellant gets used (assuming it is a significant fraction of the ship weight, of course)

Sorry for digging up an old topic, but I did some calculations for my possible Mun Fuel station and something interesting came out: Mun Altitude [km] Dv Jool Dv Duna 25 1958.8 456.3 50 1974.8 454.4 75 1989.0 453.3 100 2001.7 452.7 150 2023.7 452.9 200 2042.1 454.0 300 2071.3 457.8 500 2111.8 466.9 Reference Kerbin 75km 2002.8 1070.3 Kerbin-Jool GO 1992.6 965.6 Kerbin-Duna GO 2321.8 636.4 GO stands for Gate Orbit The main assumption is that the ejection is performed prograde from Mun orbit, but it results in a smaller burn even compared to Kerbin gate orbits.

Actually, I think SpaceX must design, build and validate a system able to land on another planet and come back to Earth, let alone payloads and colonies. After doing that, they might raise interest of other companies to develop all the visions they have. But without an operative transport system (no need for it to be cheap at the beginning), it's just sci-fi.