Lt_Duckweed

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

We do actually have examples in real life of extremely large, volatile poor superearths. https://en.wikipedia.org/wiki/Mega-Earth. Kepler-10c was originally thought to be one before its radius and mass were more accurately measured, but there are a few other examples with more rigidly constrained masses and radii. To be fair though, these usually orbit their stars in very tight, hot orbits that drive away volatiles.

FYI you can't actually cheese reentry/ascent with radiators anyways. Anytime the external plasma temperature (note this is not the same as the current part skin temp, which will be significantly lower) exceeds the radiators max temp, the radiators are hard-coded to shut down. The end result is that by the time you would want them to be helping cool the ship, they are shut down, and rather than radiating heat away they are absorbing heat. And also making lots of drag.

This will NOT work for higher speed reentries. This only works for relatively low drag craft on low speed entries, where the limiting factor over a long entry is the internal temperature of a weak part getting too high due to heat bleed. For high speed entries (well over 3000) you are instead limited by the maximum skin temperature of the weakest part. Often this entirely prevents you from dipping bellow 40km, as any lower and your craft turns into a meteor shower as parts instantly turn into flashpaper. For these types of entries you are forced to stay high, and need to generate as much drag as possible using an extremely high AoA. If my ssto design can't sustain at least 40 AoA from entry through to sub Mach 3, I redesign it. As an example, on a recent mission I hit atmosphere at 4300 m/s. Any lower than 44km and the craft burns up due to exceeding skin temp, so it has to scrub over 1000 m/s in a single pass at 44km at 90 degree AoA. As a matter of fact, I have NEVER had a craft that dealt with problems with internal overheating on reentry. The only time I have ever had an issue with that was with a craft that needed to do an extended hypersonic glide halfway around Kerbin post reentry, and one of the science parts (1200 internal temp max) got close to blowing up. TL:DR - A properly designed spaceplane is going to be able to generate enough drag that it can scrub speed fast enough for skin temp to always be the limiting factor, not internal temp.

Please reread my post. I said an elliptical orbit BELLOW your current circular orbit. Moho is in an elliptical orbit BELLOW your current solar orbit when coming in from Eve. The most efficient way to reach it is to lower pe to match near Moho Pe while also matching planes in the same burn. Since Eve-Moho Dn is quite close to Moho Pe, you want to do your Eve assist at Eve-Moho An. Off the top of my head, to properly match planes and lower pe takes 2 assists because relative velocity to Eve is too high to do it all at once.

This isn't actually true. A normal rendezvous/transfer has the same properties as this Moho transfer. When transferring to an elliptical orbit that is bellow your starting orbit, starting from a (mostly) circular orbit, you need to: Drop your Pe to touch the target orbit. At your Pe, reduce speed enough to match the rest of the orbit. When you do this via transferring to target Ap you essentially: 1. Hohmann transfer to target Ap. 2. Circularize at target Ap. 3. Perform the Pe lowering of another Hohmann transfer to lower your pe to match target pe. When you transfer to target pe you: 1. Perform a Hohmann transfer to target Pe. 2. Abort the circularization burn at Pe partway through, when the Aps match. Perhaps after work I can work out the math on this to provide a proof. Edit: another way to think about it, when transferring to an elliptical orbit, you want to match your Pe vs its Pe, or your Ap vs it Ap

When descending to the surface from a low orbit, you should not be doing a pure retrograde hold descent (aka a suicide burn). Instead, you burn at an angle between retrograde and vertical, so that retrograde is always pointing directly at the horizon (ie, near 0 vertical speed) and only let the craft start to descend when you are nearing the end of the burn and are approaching your landing site. This is called a constant altitude descent. Ideally you start it at the lowest possible altitude that does not result in you smashing into the terrain surrounding your target landing site, and come screaming in just above the hilltops. Done correctly, this actually uses even less fuel than a suicide burn.

You can push off water with a propellor. Its called a boat.

It is due to the drop in the speed of sound. The temp difference is enough to cause this issue. Remember, your total blade apparent speed is a vector sum of the craft forward motion, and the blade rotational motion. To decrease blade apparent speed by, say, 20 m/s (the approx drop in speed of sound going from 4km at the equator to 4km at lat 60) requires 1 of 2 things: A decrease in forward velocity of greater than 20 m/s. (Your case) Or, A decrease in forward velocity of 20 m/s and a reduction in blade rotational speed via reduced rpm. Basically, as speed of sound changes, ideal blade rpm must change. Which is why at high altitudes on Duna for example, you get better performance running your blades in the mid 300's rather than 460 rpm.

Today, I flew into the Sun: The exact techniques and exploits used for something like this are a bit complicated to explain, but I have a couple tutorial/explanation videos in the pipeline that will cover them, among other things.

Lift induced drag is the very bottom value in the aero gui, and for this craft looks to be pretty small.

Open and then close your service bays. For whatever reason, when you close service bays, the gui glitches out and keeps using the last drag value for everything in the bay, in this case, your props. They don't actually contribute any drag, but the GUI will still add their "drag" to the total value. That makes up for a large portion of the drag. The rest is lift induced drag, because the lift from wings in ksp is perpendicular to wing surface, not to velocity.

This is amazing! You have single handedly made 1.12.2 playable for me, as I like building craft out of sections in orbit, and the drift bug was killing anything that landed on the surface afterwards.

Why would you be discussing rocket engines though? Every rocket engine in the game produces 0 thrust when near Jool 0 altitude because the atmospheric pressure is so high. Also, you can belive me or not. But I have had 0 issues with controlling throttle and all other functions of a craft at Jool 0 altitude. This is across multiple varying ssto designs.

It was already posted earlier in this thread

I have not experienced this at all when doing Jool returns. Are you sure you didn't lose connection to the ksc or something like that?

Quick question, does anyone know if it is possible to put clouds on a star? I have been trying with no success so far. Here is the cfg I have so far: @EVE_CLOUDS:NEEDS[EnvironmentalVisualEnhancements] { OBJECT { name = Sun-MainClouds body = Sun altitude = 600000 speed = 0,4000,0 settings { _Color = 140,55,155,255 _DetailDist = 2E-15 _DetailScale = 4 _UVNoiseTex = Lt_Duckweed/Textures/uvnoise1 _UVNoiseScale = 0.0999999998 _UVNoiseStrength = 0 _MainTex { value = Lt_Duckweed/Textures/eve1 } _DetailTex { value = Lt_Duckweed/Textures/detailthicc } } layer2D { macroCloudMaterial { _RimDist = 9.9999997E-15 _MinLight = 10 } } layerVolume { size = 5500,2 area = 16000,4 visibleRange = 3000 particleMaterial { _Tex { value = Lt_Duckweed/Textures/rgb } } } } } I don't get any clouds showing, and instead, anytime I leave the map view while near Kerbol I get 5-6 of the following errors: Other than the clouds not showing, and this error, the game seems to continue to work perfectly fine. As for "why are you trying to put clouds on a star?" . Because it would be neat. But also, Kerbol looks pretty boring, I think adding closely spaced cloud layers could give it more depth when viewed from close range.

To me this indicates a gap in understanding of how wing incidence is best used. I fly to orbit with 5 degrees of incidence, 1650m/s at ~20,000m, with angle of attack of less than 0.05 degrees. I generally expect my craft to maintain a L/D ratio of near to or over 4 from Mach 2 to Mach 6, with minimum transonic L/D of at least 2.5 or so as I cross Mach 1.15 (point of highest transonic drag). When using a plane with wing incidence, for a given atmosphere, each altitude (well, technically density) is tied to ONE unique optimal speed. The correct flight profile is to stick as close as you can to prograde flight, managing vertical velocity as needed to climb through altitude at as near to the same pace you climb through velocity. In practice, I accomplish this by barrel rolling anytime vertical speed climbs too high. If you ever reach a point where you are flying with your prograde vector significantly above your craft attitude, you are going too fast in air that is too dense, and should have climbed faster by holding prograde. You fix this by letting the craft pitch up towards prograde a bit to gain altitude faster, then as you approach your ideal altitude, barrel roll to arrest vertical speed. If you ever reach a point where you are flying with your prograde vector significantly bellow your craft attitude, you are flying too slow in air that is too thin, and should have climbed faster by scrubbing vertical speed with a barrel roll. You fix this by letting the craft pitch down towards prograde and lose vertical speed and altitude, you will initially overshoot, and "bounce" off of thicker atmosphere, then on the way back up barrel roll to arrest vertical speed at ideal altitude.

Just tested, regardless if orientation, gigantors break when dynamic pressure exceeds 16kPa

Panels cannot produce ec while shielded. Even if extended and shielded they will display a message that they are blocked by aero shielding. As for blades, I have found that offsetting blades inwards rather than outwards significantly increases performance. Due to the way ksp handles prop blades, the reduction in torque needed is a lot larger than the decrease in blade speed. Normally the reduction in blade speed is a downside and means less thrust. But this isn't really a problem on Eve because the lower speed of sound means you want a lower blade speed so you don't exceed the fan blade's efficient region. The end result is the number of blades you need to power the craft stays about the same, but the ec and rotor counts are reduced by a large amount.

I mean, it's pretty obvious he's using batteries. They are either in the fairing or under the skin of the craft. In the initial launch from Kerbin you can see that he has 48000 electric charge.

With a sufficiently optimized ascent, you don't use rtgs. Prop ascent phase should only take 12-15 minutes. If you run the math, rtgs only beat batteries for ascents taking at least 35.5 minutes. So if you use batteries you are looking at 2-3x less mass and about 7x lower part count vs rtgs. As for payload fraction, even with relatively small designs (2 vector, 4 nerv) payload fractions of about 5% are achievable, so with the much larger scale, and the greater skill (Brad is better than me at optimizing sstos) I can totally believe that Brad was able to reach 6%

Uhh, stratz is a grown ass adult lol. I actually independently discovered the heatshield glitch at about the same time stratz did. And I also discovered some heating exploits related to the aero model, allowing entering Kerbol's atmosphere, which have since been built upon by others. There have also been found in the last few months, glitches that allow permanent floating bases, including on Jool, based partially on the work Stratz did for his Dres bridge. Finding all these bugs is fun and exciting. But at the end of the day they are bugs and exploits, they need to either be removed, or replaced with functional gameplay mechanics. New players shouldn't have to take a college course on ksp exploits to even be able to understand what a high skill ksp vet is even doing in a mission. It's ok to have a high skill ceiling, but it needs to be based on clearly designed and laid out game mechanics, not strange arcane exploits that live only in the minds of vets and in secluded discord servers.

2 wildly different aero models supported at the same time has a pretty much 0% chance of happening. 1. Developing 2 different models costs dev time (and therefore money) 2. 2 different methods have to have all their interactions regression tested with every release (costs money) 3. 2 different methods means twice as much surface area for bugs. More bugs to fix, harder to diagnose (costs money).

One situation where high/low CoL matters is high angle of attack stability for reentry. Having CoL above CoM means that as AoA increases more and more and the wings transition from being lifting surfaces to dragging surfaces, you end up with a CoP (center of pressure, both lift and drag together) that is now behind the CoM. This can result in a "pinning" effect, where the craft is fully stable in a range of 30 degrees or so off of prograde, but outside of that it has a preference for fully stalled AoAs. Sometimes even as high as 90. With careful adjustment this can be exploited to create a craft that is very neutrally stable over a huge range of angles of attack.