Lt_Duckweed

With the altitude you are at I wouldn't worry about this. While the speed of sound is around 250m/s up at the altitudes where I was flying in my example, down where you are it's going to be closer to 285m/s. So your props have gone slightly supersonic, however, slightly supersonic is ok, as the ducted fan blades don't hit their performance wall until around Mach 1.2 You could extract a bit more speed with more tweaking of the prop, but if you are happy with what you have, its a pretty good result.

229.4m/s (approximately Mach 0.9) in level flight at 13.7km A few tips: For whatever reason, for the 2x4 fixed panels, long side edge on into the airflow is lower drag than any other setup, especially the left long side (going by the default orientation when attaching it to a forward facing part in the SPH). For the size rotor you have, 6 panels is massive overkill. 1 2x4 panel is more than enough for a single small rotor. Ducted fan blades are better than propeller blades in pretty much every conceivable metric (and shrouds are cosmetic only, you just need the blades) Due to lower speed of sound on Eve, I get better results limiting RPM to 400. If you offset the base of the fan blade directly inwards towards the axis of rotation, it will improve the thrust to torque ratio on the blades, so you can run more per rotor. The farthest you can go is one shift tick past the axis of rotation (so the base of the blade is on the other side from the rest of the blade). This should let you comfortably run a pair of large ducted fan blades on the smallest rotor Run a pair of two blade rotors, with two solar panels. This should get you a lot more thrust and greatly increase top speed, but will not effect your overall mass much since you removed the extra solar panels. In low light conditions where 2 panels may not be enough, simply lower the torque limit on the rotors a bit. This will lower your top speed a bit, but it will still be a lot faster than you are getting right now.

The key is setting the deploy limit on a service bay to one of the axis groups in the action group configuration. While you cannot deploy a service bay while it is shielded, you can adjust the deploy amount, which results in it deploying. The setup goes like this: You have a root fairing whose base is shielded from solar heating by some other part that is larger than the base, but smaller than the overall fairing, so it can shield the base and be shielded in return. In front of this, a structural plate or multiple structural plates have all drag cube faces fully occluded, creating perfect shock shields. A service/payload bay is positioned such that the center of the bay is considered "inside" the fairing, but a substantial portion of the bay volume is actually located outside of the fairing. A flag or flags of the largest size that the bay can shield are located in the portion of the bay that is outside the fairing. If the flags are not located in the shock shadow of the main shock shield (as is the case for the main station) then a smaller shock shield(s) is constructed that sits immediately in front of the flags, but is also still outside the fairing. Finally, the axis group chosen to control service bay deploy limit is adjusted to open/close the bays as desired. Interestingly, there are a few other scenarios where you can use axis groups to perform actions that are normally forbidden via action groups. Some examples: Actuating service/payload/cargo bays when they are shielded. Deflating an inflatable heatshield after it has already been inflated (can be done as many times as you like) Deflating an inflatable airlock that already has a kerbal inside it.

Are you using grandparent autostrut? It's practically useless for stiffening in cases like this. Autostrut a few parts on the payload to heaviest, and a few of the parts on the rocket/side boosters to root.

Yes the the mults and clamps are just dimensionless constants. You start with a value of 1, then take the density and velocity mults and go from there

The actual trueThrustMult you get once above the flowMultCap is: trueThrustMult = flowMultCap + (thrustMult - flowMultCap) / (flowMultCapSharpness + (thrustMult - flowMultCap)/flowMultCap) By default, flowMultCapSharpness is 2 and no stock engine has an alternate value Working an example, the Whiplash has a flowMultcap of 2 and the default sharpness of 2. So at a normalized density of 1 (for example, flying at sea level at 30 degrees latitude at "3 am" or 45min after midnight under Kerbin time) at a speed of exactly Mach 3, the supposed thrust mult of 5.8 would get transformed like so: trueThrustMult = 2 + (5.8 - 2) / (2 + (5.8 - 2) / 2) = 2.97 EDIT: As an additional note, the atmCurve is not based on pressure, but on normalized density, with a normalized value of 1 = 1.225 km/m^3, which is the sea level density under the ISA (International Standard Atmosphere) and occurs at a temperature of 15C. Interestingly, this results in jet engines not providing their full advertised thrust on the runway, as it is significantly warmer than 15C on Kerbin's equator, and so the atmosphere is less dense.

VertexHeightOblateAdvanced 1.1.1 What's new: Fix for NullReferenceException and broken camera when in the SOI of a body without a PQS (Stars and Gas Giants) Download Github SpaceDock

unfortunately no And oblate SOI would be cool but also difficult to implement in code.

@Whirligig Girl I believe you will find this quite interesting. I have updated VertexHeightOblateAdvanced with two new camera modes, one of which aligns normal to the shape defined by the PQS mod, and the second of which aligns with apparent gravity:

VertexHeightOblateAdvanced 1.1.0 What's new: When in the SOI of a body implementing VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies. 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. Download Github SpaceDock

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 both radius and geeASL are provided. Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend) Value: (greater than 0) radius: Mass of the body as set in the Properties node. Optional if both mass and geeASL are 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 both mass and radius are 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 provided radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) b: The secondary equatorial axis as a ratio of provided radius. Used with: oblateMode (Blend, CustomEllipsoid) Value: (1 to infinity) c: The polar axis as a ratio of provided 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