Lt_Duckweed

You don't need anywhere close to this much twr on your nervs. When your rapiers stop being able to accelerate you somewhere a bit past Mach 5, you should still have a lift to drag ratio close to or exceeding 4 if you have paid attention to some basic drag optimizations. You are also high enough that the nervs are at essentially 100% thrust and ISP. At this point a initial twr of 0.3-0.4 will cut it, and as you burn off fuel and also get closer to orbital speed, the needed twr to overcome drag will drop even as your actual twr will climb. It's harder than stock scale sstos for sure, but it's a lot easier than stock part RSS sstos, which have been done before by a number of people.

Is this body meant to represent Haumea perchance? When replicating a existing body with a known shape, it would be easiest to use CustomEllipsoid mode, so you can set the a, b, and c parameters equal to the known real values. Additionally, when using UniformEquipotential or PointEquipotential, the radius and geeASL you input must match the values for the poles. For Haumea this would be something like 525km radius, and a geeASL of around 0.095 Unfortunately this still gives a shortest possible period under the Uniform model that is longer than the actual real period of Haumea. This is because in reality, Haumea is probably not uniform in density but is denser towards the core, and thus would have a shorter period than what the model would predict. In such a case it is supposed to clamp to an oblate value that is within the bounds of the model, but seems like this edge behavior may have a bug I need to fix. All that said, assuming this is indeed Haumea, my recommendation would be to use the polar radius and gravity, and try using CustomEllipsoid to manually set the a,b, and c values (c should be 1, a should be a bit over 2, and b should be around 1.6).

Can you post the config for the planet so I can take a look? Since it tries to be as realistic as feasible on shape, if a planet isn't rotating all that fast it won't change the shape much at all. It's possible that is the issue here. As an example, if the Earth was had a period of 6 hours, or 4x faster than it does now, it would only have a Equatorial to Polar axis ratio of 1.07, which is going to be hard to notice to the naked eye.

Love it! This is exactly the reason I included Blend mode. Pure PointEquipotential just doesn't quite look right for a lot of bodies, but blending with a standard oblate distortion broadens the lens enough to get something that looks really good! Oh and as a side note, for ease of use for end users, it is perfectly acceptable, encouraged even, to distribute the VertexHeightOblateAdvanced dll, readme, and license packaged with Whirligig World in GameData\000_DuckweedUtils\VertexHeightOblateAdvanced\

VertexHeightOblateAdvanced VertexHeightOblateAdvanced is a custom PQS Mod intended for use by planet modders to enable easy creation of oblate bodies via a simple PQS Mod, rather than via a heightmap. Additionally, when in the SOI of a body implmenting VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies. Planet pack developers implementing VertexHeightOblateAdvanced are encouraged to bundle it with their mod, for the convenience of users. Examples PointEqupotential UniformEquipotential Low UniformEquipotential Low UniformEquipotential High UniformEquipotential High Download Github SpaceDock Installation and Use Install ALL listed dependencies, following the links below Download and extract the VertexHeightOblateAdvanced zip file Place the GameData folder into your KSP directory Once installed, simply add a VertexHeightOblateAdvanced node to the Mods node in your body's PQS node Using the following Google Sheet, find appropriate periods for your body to get the desired oblateness, based on body surface gravity and radius. Camera modes: SURFACE NORMAL Functions like FREE camera mode, but with the vertical axis aligned perpendicular to the shape defined by the VertexHeightOblateAdvanced instance. This eliminates the "uphill effect" that oblate bodies have. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. GRAVITY NORMAL Functions like FREE camera mode, but with the vertical axis aligned with the local apparent gravity vector, taking into account the effects of rotation. Surfaces that look flat and level are actually flat and level relative to gravity. Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height. Parameters and expected values: oblateMode: overall controller for type of generation used Values: (PointEquipotential, UniformEquipotential, Blend, CustomEllipsoid) PointEquipotential: Generates a point mass equipotential UniformEquipotential: Generates a uniform density equipotential, either a Maclaurin spheroid or Jacobi ellipsoid deppending on energyMode and period Blend: Multiply a PointEquipotential by a CustomEllipsoid CustomEllipsoid: Generate an ellipsoid based on a, b, and c axis values energyMode : Used with: oblateMode (UniformEquipotential) Values: (Low, High) Low: For the given period, generate using the low oblateness branch. Always generates a Maclaurin spheroid High: For the given period, generate using the high oblateness branch. Generates either a Maclaurin spheroid or Jacobi ellipsoid based on period mass: Mass of the body as set in the Properties node. Optional if geeASL is provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) geeASL: Surface gravity of the body as set in the Properties node. Ignored if mass mass is provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) period: Rotational period of the body as set in the Properties node. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) a: The primariy equatorial axis as a ratio of body radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) b: The secondary equatorial axis as a ratio of body radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) c: The polar axis as a ratio of body radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) Requirements ModuleManager Kopernicus FAQ Q. I'm not a planet modder? Do I need this? A. You do not need to install it manually yourself, but if you found this in you GameData, it is because a planet pack you have/had needs/needed it and so it was either included with the mod or auto installed through CKAN Licensing VertexHeightOblateAdvanced is licensed under the MIT License

QuackPack v1.1.0 Subon bound at the speed of sound Changelog Subon added, a retrograde captured iron-nickel asteroid orbiting Jot Cind atmosphere slightly hotter, molar mass increased by about 25% Cind lava now has HazardousBody config, go swimming at your own risk Jot texture size reduced to 25% of the original value, will reduce stutters when looking at Jot from other planets in the Kerbol system Bugfixes and typo corrections to science defs Download Github SpaceDock Licensing QuackPack is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)

So, QuackPack development, after being dead for a year, is now back. Here is a sneak peek of something coming in the next update.

There are currently some issues with Scatterer and QuackPack when installed from CKAN, something is wrong with the metadata around the Scatterer version required I think. Hoping to have an update to QuackPack out in the next few weeks that will hopefully also address this. If you didn't install via CKAN, unsure what the issue is, and would need you to upload your ksp logs to pastebin so I could take a look.

Yeah I was saying that those ARE the reasons it could end up possible, I went and looked at the cfg file for Valyr. My logic behind each: Flatter means lower gravity losses due to ascending at a shallower angle. Not so much a drag issue as an issue of lift growing with speed. On Eve lift decays with altitude quite slowly due to the large scale height, so you wing incidence will curve your trajectory quite steeply. Here, the flat atmosphere means a lift guided ascent will still be quite shallow. Aero heating matters a lot for an efficient ascent. You want to remain lift supported for as long as possible to reduce twr requirements, but at high enough speeds lift supported flight results in burning up. An extreme example of lift supported ascent is Jool, where the ascent is lift supported all the way to orbital velocity, due to the 0.5 shock temp multiplier for Jool. This results in a atmospheric molar mass of about 19 g/mole, less than half that of Eve (43 g/mole). Additionally, Valyr has a higher adiabatic index than Eve does (1.4 vs 1.2). Since speed of sound goes with the inverse of the square root of molar mass, and linearly with the adiabatic index, this means that for a given temperature, Valyr will have a speed of sound that is approximately 62% higher than Eve. Temperatures are a little cooler on Valyr than Eve for the relevant ranges so we can call it probably 50% higher.

The higher dv requirements along with the higher twr requirements cause me to want to lean on the side of impossible with a "conventional" ssto, ie: limited to standard wings. Eve already chews through lf/ox mix before you get to a high enough speed to make finishing the burn with nervs viable, and Valyr is going to require even more, with higher twr to boot, as well as more prop mass and wing mass. The saving grace it might have is that the atmosphere is: Much flatter than Eve, with a more reasonable scale height than Eve. Templated off of Laythe, making heating gentler. (Eve, Duna, and Eve/Duna templated bodies have 20% higher shock heating external temp. This doesn't necessarily translate to exactly 20% part temps, but it certainly does not help) A light atmosphere by molar mass, raising the speed of sound. I still think it's probably impossible, but if it ends up being doable, those three factors will be why.

I'm honestly quite impressed you made it into orbit carrying so many Mk2 parts on your first Eve SSTO. Bravo! If you are looking to improve what it is able to take to orbit andor cut down on mass, I would recommend swapping those mk2 side stacks out for regular 1.25m tanks, and using 1.25m payload bays to hold your propellers instead of the cargo bays. You will get the same amount of fuel storage for reduced dry mass and reduced drag. I would also consider swapping from mk3 parts for the center stack to 3.75m parts, they tend to be a little lower drag as well thanks to having a better ratio of fuel mass to surface area. They also have a little bit lower dry mass as well I would also recommend seeing if you can replace the big s tails with smaller control surfaces to save a bit of mass. With all those changes made you can see if you are able to then remove the aerospikes. They have a lot worse twr than a vector, meaning more dry mass, so if you can get away without using them, it's generally a good idea. All that said, great work! Eve SSTOs are a beast to design, and ANY design that works is one to be proud of!

Fortunately, this math is pretty easy. For every 1 unit of xenon consumed, 18 units of electricity are consumed. For every 1 unit of lf/ox mix consumed, a fuel cell or fuel cell array produces 400 units of electricity. Thus, each 1 unit of lf/ox mix provides the electricity needed for 400/18 = 22.2222.... units of xenon put another way, for every 1000 units of xenon you have, you need 45 units of lf/ox mix

I've not tried it with either but what I would expect to happen is that true volumetrics and parallax features just don't show up on the QuackPack bodies.

The actual bug is that they aren't all saying 65% load. In a situation like this where you have enough ore to feed all of them, they will all run at the same speed Yes, 65% is the capacity it should be running at. And this is why. With no engineer, they will run at 5% load, and you get +20% load for having an engineer on board, and another +20% load for each level the engineer is. 5 (base) + 20 (engineer) + 40 (lvl 2) = 65%

I actually did a few years ago! We did a collab project for the Jool SSTO video on his channel

Naughty Kerbals get banished to the Sun

The vector will indeed be shielded by the fairing. But the fuel tank is not "in" the fairing, nor is it node attached to the fairing. Thus, from the perspective of the fuel tank, the fairing might as well not exist. As for the vector being node attached, keep in mind it only reduces the exposed area commensurate with the size of the vector. Since the vector is about 1/2 the radius of the fuel tank, it reduces the exposed area of the fuel tank rear face by about 25%

Fairings apply all their body lift and drag at the base of the fairing, so that front fairing facing backwards is applying most of your fuselage lift and drag far forwards of the CoM. As for the high drag of the fuel tank generating high drag. You mention that the tank doesn't have an open back, but the thing is, it does. Attaching things to nodes reduces area of the associated drag cube face based on the size of the drag cube of the part you attached. In the debug data in your screenshot, the drag vector is (0.1 , 1 , 0) which means YP is the frontal face. This has a OccA of 0, and a WDrg of 0, so all good there. But your rear face, the YN face, has a OccA of 3.73 and a WDrg of 0.92. Comparing the OccA of 3.73 to the WArea of 4.85 means that the attached vector reduced the OccA by only 1.12 (4.85 - 3.73). On top of that, a WDrg of 0.92 is really bad. That's pretty much indistinguishable from a flat plate. Thankfully this is a rear face, so by the time you are approaching the speed of sound it will reduce quite a bit (rear face drag falls off substantially above ~Mach 0.9) EDIT: to add on to this, I would highly recommend installing the mods "CorrectCoL" (take all parts into account for CoL indicator, not just wings, and also gives stability graphs) and "RCSBuildAid" (see separate indicator for dry CoM) as they provide invaluable help when designing planes.

Note I did not dispute the authenticity of your statement as it regards cargo bays, I am well aware of the ongoing revert bug with root cargo bays. I disputed it as it regards fairings. I have tested this many times, as recently as today. Root fairings do not suffer from the same revert bug as root cargo bays. I have spent quite a lot of time testing and reverse engineering the KSP aero model and looking for edge cases. I have spent a lot of effort to make sure the information I distribute is accurate, and have a series of well respected deep dives on the aero model posted on my youtube channel. However, I have always encouraged others to independently test my results. So, feel free to install KSP and find out what has changed in 3 years.

Fairings shield parts from drag just fine when the root part. As a matter of fact, they do better than that. Fairings that are the root part do not themselves generate drag with their fairing panels, only the fairing base. So an arbitrarily large root fairing can shield as many parts as you want while itself having nearly 0 drag. The last time root fairings didn't shield parts from drag was update 1.4. Spreading bad/outdated info while speaking as if from a position of knowledge is a huge problem in the KSP community and is in large part responsible for why so much inaccurate or outright false information still circulates even many years after it ceased to be true.

Das me.

Using a 0.625m nose cone on the back face of a rapier will only partially remove the back face drag, since it only occludes 1/4 of the back face area. To fully remove it you have to use at least a 1.25m nose cone.

Based on the images of the deconstruction it looks like you attached the whole isru kit to the bay end node and attached the cockpit to the isru setup, then offset. This means you have spindly, offset joints, which can be prone to breaking. Attach the Cockpit to the cargo bay directly, then attach the isru to one of the nodes on the inside of the bay. Also, for what it's worth, your current radiator setup is extreme overkill. Since the drills are attached to the fuel tank, and the isru to the cargo bay, a single large fixed radiator panel on the bay and 2 on the fuel tank is plenty.

Might as well throw this into the ring:

The key here is that when a fairing is the root part, the fairing panels do not count for drag. This means that making it pointier does not help. What you have to do is occlude the fairing base via node attachment. In your screenshot, the YN face OccA value is almost 0, as that is the bottom of the base and is attached to the fuel tank, which almost fully covers it. However, the YP face (which is the top of the base) OccA is 1.03, which isn't very covered at all, and the Wdrg value is 0.91, which is very blunt. You can fix this via enabling interstage nodes on the fairing and attaching parts to the forwards facing interstage nodes until the YP face OccA and Wdrg values are down to reasonable levels (a Wdrg under .4 should be the minimum target). This can be many small parts, such as cubic struts, or one larger part, such as a 1.25m nosecone.