Lt_Duckweed

With the amount of wing area you have, you should be going MUCH faster than 400 m/s at 15km. I typically don't even leave sea level until past 400m/s and by 15km am well over 1000m/s

You will see this anytime the initial body and final body are not 100% coplanar. It's due to a couple things. The porkchop plot assumes a single ejection burn, and a single capture burn, with no corrections. A perfect Hohmann transfer involves you reaching the target body at 180 around the sun from where you left. AN and DN will always be 180 degrees apart from each other. Thus, if you did not leave exactly at the AN/DN with the target planet, directly hitting the target planet exactly 180 degrees around your orbit involves making the departure point one of the AN/DN. This requires an extreme normal/antinormal burn to do, essentially rotating your orbit 90 degrees Alternately, you just burn prograde to eject, and then do a small correction burn at the AN/DN. It's just that the chart can't capture this, due to the lack of considering correction burns.

This is an example of a 90/10 technique. 90% of the result for 10% of the effort. The lift to drag curve absolute peak when supersonic is remarkably shallow and broad. l/d ratio absolute peak is at an AoA of 3.81 degrees at Mach 2.5 Using a value of 5 instead of 3.81 degrees nets you a loss of efficiency of... 3.46% 5 vs 4 degrees is a loss of 3.33% at Mach 2.5 5 vs 4 degrees is a loss of 1.95% at Mach 6 So yeah, if that 2-3% is super vital, one can feel free to faf about setting up 4 degrees, but most of the time, it just isn't worth it. For what it's worth, I often opt for slightly more wing area at a lower AoI for the superior landing flare and pitch up handling (5 degree AoI with 3 degree flare = 60% more lift, 3 degree AoI with 3 degree flare = 100% more lift)

SMH no Minmus assist.

The poodle has a one bell variant

Once supersonic, lift to drag ratio stays fairly constant, only dropping maybe 10-20% from Mach 2.5 to Mach 5. You cover twice as much ground per second, at only slightly higher fuel cost. In addition, the closer you get to orbital speed, the less you feel the effects of gravity, and the higher you are, the weaker gravity is. Together, this means going as fast as you can, as high as is reasonable, reduces the amount of lift you need to have to continue flying. Since lift to drag ratio is relatively constant, this means less drag as well. End result being that with whiplashes or rapier engines, the most efficient speed and altitude is as fast as you can as high as you can.

While this is technically true, there is a way around it, using messenger assists, also known as a Vinf leveraging manuver. on your first encounter with Moho you simply fly past, bending your orbit slightly radial in/out (if you are coming in tangent which way only matters in terms of lining up your future periapsis with Moho's pe). This reduces both your periapsis and apoapsis somewhat. Then, at apoapsis, you raise your periapsis such that your orbit and Moho's orbit are once again tangent at their intersection. Then a few orbits later you encounter Moho again. The amount that your Moho relative velocity decreased by will be significantly greater than the cost of the pe raise. From an Eve flyby, a fairly optimal set of flybys is 5 flybys with 5 dsms and then a final encounter and capture burn. Done this way, you can reach low Moho orbit from an Eve flyby in under 600 m/s

In terms of game mechanics, no, they don't really serve any purpose. They just look nice.

Today, I flew a very small ssto to Duna and back. As far as I am aware, this is the lightest flown Duna ssto.

This is actually the issue. Deeper in the atmosphere = higher atmospheric density Eve = higher pressure, CO2, both mean higher atmospheric density Eve = higher gravity, meaning you need more lift to fly, so for a given speed you must fly in denser air than on Kerbin Eve has 70% more gravity than Kerbin, so you need 70% more lift, which means, with the same plane, roughly 70% more drag. This means 70% more thrust, which means 70% more torque needed. If the torque needed is higher than the rotors can supply, the rpm starts to bog own. The inconsistencies of KSP building can mean that the two rotors have different torque to thrust ratios, so one bogs down slightly earlier

If you tie thrust limit to a axis group, and then turn on fine adjustment mode with caps lock, you can get very very fine grained control, allowing you to use a very very small thrust limit.

The mod CorrectCoL is useful for many other things, but it has one esoteric use that is likely unintentional. When you update the CorrectCoL window with a new altitude and speed setting, all the parts on the craft update their debug data as if they were actually traveling at that speed and altitude, even though you are in the SPH. Though for whatever reason it always simulates as if the airflow is coming from the left of the root part, so to get accurate values you have to rotate the rest of the craft 90 degrees to the left relative to the root part. It's the only way I've seen to do anything like what you are looking for.

Sounds like you are on 1.12.1 or 1.12.2 In those versions autostruts could not span across docking ports, thanks to unlocked rotatable ports technically being robotic parts. In 1.12.3 docking ports are locked by default, and autostruts work as per normal.

Too long has stock Kerbol gone unloved. No longer will it sit at the center of the solar system, ugly and drab. With new high resolution textures, Scatterer support, and custom light curves, BetterKerbol attempts to remake Kerbol as eye candy worthy of pretty screenshots. Towards this end, the radius has also been tweaked by an imperceptibly tiny amount, to get around a quirk in KSPs engine. This change does not effect the orbits of the planets, as Kerbol's mass is unchanged With additional configuration, experience the searing light of Kerbol as you approach the corona, watch is it dims to a pale flicker as you travel beyond the orbit of Eeloo, and resize it to align better with the scale of the stock system. Changelog v1.1.0 New photosphere texture for Kerbol. Brightness curves and optional rescale replaced with configurable options New configuration file at GameData/BetterKerbol/settings.cfg useBetterSize Default value: false Expected values: true, false Effect: Reduce Kerbol's radius by a factor of 4.24x to match scale with the stock system. useProximityBrightening Default value: true Expected values: true, false Effect: Increasing brightness curve when closer to Kerbol than Kerbin SMA. useDistanceDimming Default value: false Expected values: true, false Effect: Decreasing brightness curve when farther from Kerbol than Kerbin SMA. Features Base 8k Photosphere and Corona textures A visual surface that aligns with the true surface, opening up the possibility for spectacular close passes Scatterer configs for close up corona glow and sky tint when in the Kerbolar atmosphere Configurable Reduce Kerbol's radius by a factor of 4.24x to match scale with the stock system. Increasing brightness curve when closer to Kerbol than Kerbin SMA. Decreasing brightness curve when farther from Kerbol than Kerbin SMA. Notes Due to a long-standing bug in the way KSP calculates solar heat, temperatures near the surface are extreme, with radiant power density approaching infinity! Bring your exploit shielding or it's a one way trip! No sunflare is provided. If using Scatterer, pick your favorite sunflare mod. Gallery Download CKAN GitHub SpaceDock Installation Extract the zip file Place the GameData folder into your KSP directory Configuration BetterKerbol has a few configurable settings, located at GameData/BetterKerbol/settings.cfg useBetterSize Default value: false Expected values: true, false Effect: Reduce Kerbol's radius by a factor of 4.24x to match scale with the stock system. useProximityBrightening Default value: true Expected values: true, false Effect: Increasing brightness curve when closer to Kerbol than Kerbin SMA. useDistanceDimming Default value: false Expected values: true, false Effect: Decreasing brightness curve when farther from Kerbol than Kerbin SMA. Requirements Kopernicus ModuleManager Provided Compatibility Scatterer Known Issues Certain TUFX settings (especially TAA and HDR) can occasionally cause a ring of flickering black pixels between the limb of Kerbol and the start of the corona. Licensing BetterKerbol is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)

Not to toot my own horn too much, but if you want to learn nor about how lift and drag is calculated, and how wings work in ksp, I highly recommend you check out my 2 videos: Then, you will want to check out F00FlGHTER's ssto tutorial: Between the 3 videos, you will get a pretty solid understanding of how the KSP aero model works, how to optimize for it, and how to implement those optimizations into a spaceplane ssto.

One big-s wing is .5 tons, 5 wing area, and 300 fuel storage. 5 big-s strakes is .5 tons, 5 wing area, and 500 fuel storage. In other words, each pair of big-s wings that you replace with 10 strakes saves you the need for either: 1 mk1 tank (250kg dry mass) or 8 mk0 tanks (200kg dry mass) Another way to think about it, each strake replaces 2 mk0 tanks (the absolute best liquid fuel tank) so it is essentially 2 mk0 tanks (50kg) + a half mass wing (50gk per area instead of 100kg per area)

You can change the number of engines the engine plate can hold, up to 8+1. Any engines attached directly to the plate nodes are shielded from drag while the engine plate shroud is still attached. The engine plate is a decoupler. It's a multiadaptor, interstage fairing, and decoupler rolled into one part. If you need to mount a cluster of engines, for example nervs, they save on part count, and can save on mass as well, depending on what exactly they are replacing

Imagine that the planet has 10km/s orbital speed, and is traveling from left to right. Further, let us imagine our spacecraft has a relative velocity to the planet of 2km/s In A and C, the spacecraft has an orbital velocity that is faster than the planet, 12km/s. It then catches up to the planet, wraps around, and heads off back the direction it came. Instead of 2km/s faster (12km/s orbital speed) it is now going 2km/s slower (8 km/s orbital speed), so we lost speed overall. In B and D, the opposite occurs, we are going slower, the planet catches up to us, then flings us forwards. So we gain speed. The way I like to look at it is this: Compared to the orbital path of the body we are assisting off of around its parent, was our trajectory bent so that it is closer to prograde than before (ie, did the angle between the bodies prograde, and our prograde, get smaller)? If so, we gained speed. Was it bent closer to retrograde than before (ie, did the angle between the bodies retrograde, and our prograde, get smaller)? If so, we lost speed.

Yes it is intentional. Notice that your heading marker is above your prograde marker, this means that some portion of the airflow is impacting the underside of your fuselage, which in ksp generates a lot of drag. The best way to do this is to make sure the body of the craft points prograde. But, you need angle of attack for the wings to make lift. The way to solve this is to "build in" angle of attack on the wings by angling them a few degrees relative to the fuselage. One tick of the rotation tool while holding shift and in snap mode should do the trick, this will give 5 degrees, which is very efficient at supersonic speeds. This is called angle of incidence.

Kerbol space low is actually at 1 million km, not one thousand. With perfectly ordinary heatshields and radiators, you can get to about 200,000 km. You can go progressively lower with more and more esoteric heating exploits and get as close as the edge of the atmosphere itself (600km)

If you look carefully in your screenshot, it says in the top middle of the screen "physics easing in progress". This means the crat does not weigh the full amount, as it was trying to ease the physics as you landed, but presumably you never touched the ground.

You have plenty of lift. Your issue is that your Center of Lift is very very far from your Center of Mass. This means the plane wants to nose down very strongly, and you do not have enough control authority to bring the nose back up. You need your wings farther forwards, and/or larger pitch control surfaces, and/or pitch control surfaces that are farther from the Center of Mass.

Even for stock LKO, liquid fuel only Rapier-Nerv spaceplane SSTOs enjoy a performance advantage over pure Rapier LFO SSTOs. As you go upwards in scale, they lose performance at a much slower pace as well, due to the much higher ISP. The end result is that the hit to performance going to JNSQ is not as harsh as many assume. Of course, special attention needs to be paid to the harsher ascent and entry heat (especially on ascent, as ascent is lift supported nearly the entire way to orbit), but this is ultimately manageable via smart design, and payload fractions near 30% should be achievable.

They are much more difficult, but by no means impossible, and can still be very effective and carry payloads to orbit, and go interplanetary. However, JNSQ SSTOs are much less forgiving. I would describe SSTO building as following an curve with skill that has a very sharp inflection point. That is, for a very long time, even as you get better at making sstos the overall quality of your craft doesn't get that much better, but once you hit a certain point, it explodes very rapidly. For usable stock scale SSTOs you don't have to have found your way past the inflection point. For JNSQ SSTOs you do. In other words, for a very long time JNSQ SSTOs just don't really work, and then suddenly at a certain skill level they work just fine.

Been a while since I fooled with Eve, and since then the devs nerfed the mass of the mk3 crew module, so I figured it was time to take another look at it and redesign my old gross Eve crew SSTO: Into a new, sleeker craft