Lt_Duckweed

It is not designed to be used as a part of Eve city lights, it needs to be added directly to the planet you are trying to modify as part of a Kopernicus config. In your above example, you would need to create a config file to edit Kerbin using Kopernicus, and have it set the VertexColorMapEmissive in the ScaledSpace node and the Mods node in the PQS and/or Ocean nodes.

Couple of things: the scaled space mesh for your planet (which is used in map view, or when far away or zoomed out in standard view) is stored in the cache file at BeyondJool/Cache/Kotta.bin. Anytime you change the PQS (such as by adding the oblate PQS mod) you must delete the cache file, so that Kopernicus will generate a new one. Secondly, your current period is too low. Using this google doc https://docs.google.com/spreadsheets/d/1QSUjAmyAIACKAFSL_C8qv5GxYc4YTB1eDBRP4TTUl5A/edit?usp=sharing, I input your body's radius and the shortest possible stable period is 6877 seconds. Any faster than this, and the body, if it were actually being physically simulated, would tear itself apart.

I have not tested with a heavily clouded planet like that but it has seemed to work fine with my planet Cind, but Cind only has very faint clouds. I wouldn't be surprised if dense clouds like you show have a similar issue to KopEx.

It does support both triaxial bodies, and prolate bodies. If you use UniformEquipotental with energyMode High, then for appropriate periods you will get triaxial bodies. For prolate bodies, or in an instance where you don't want to faff about with period for a triaxial body, you can simply use the CustomEllipsoid mode and specify the a b and c ratios.

Yeah with how close the three planets are to Kerbol and to each other, I doubt any orbit for any moons could ever be stable around any of the three. The existence of Geet and Subon are ultimately concessions that deviate from realism for gameplay purposes. Subon exists because otherwise Jot can feel empty and a bit pointless, and to serve as a staging ground for inner system infrastructure. Geet exists to ease the delta-v challenge of leaving Blas, via ISRU (for those who chose to do so). Out of curiosity, what happens to Geet and Subon? I assume Geet is ejected, does Subon also get ejected or does it collide with Jot?

It is very difficult to safely reach and land on Cind, but it is just far enough from Kerbol that with very judicious part selection it is possible to stay within thermal limits and pull off a landing. Here is an example of a successful mission pulled off by @JeDoesStuff

QuackPack v1.2.0 Dead Worlds Changelog Dependencies KopernicusExpansionContinued-er dependency removed VertexColorMapEmissive added as bundled dependency VertexHeightOblateAdvanced added as bundled dependency Blas Dimmer, more transparent rings Redone, less saturated colormap Add height noise for more varied, bumpy terrain Add terrain scatters Tweaked, less saturated Scatterer atmosphere Stock atmosphere redone, will look nicer when playing without Scatterer Jot Tweak Scatterer atmosphere slightly Stock atmosphere redone, will look nicer when playing without Scatterer Subon Use VertexHeightOblateAdvanced instead of oblate heightmap Updated normalmap Add terrain scatters Cind Scatter atmosphere redone, now purple to represent the high concentrations of disulfur gas Stock atmosphere redone, will look nicer when playing without Scatterer Add height noise for more varied, bumpy terrain Add terrain scatters Ocean texture redone, now looks more like lava and less like orange juice All emissive effects redone, using VertexColorMapEmissive Download Github SpaceDock Licensing QuackPack is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)

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. Download GitHub SpaceDock Licensing BetterKerbol is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)

I am actually getting ready to push an update to BetterKerbol pretty soon. I can add an optional patch to revert to the stock light curve behavior.

As of the latest version, the folder should be 001_DuckweedUtils anyways, so you are all good there.

@Tecorian @king of nowhere "Orange Tank SSTO" is somewhat more rare nowadays but used to be common shorthand for an SSTO that can take a 36 ton Jumbo-64 tank to orbit as payload. The key for SSTO spaceplanes is: Reduce drag. Make sure any rcs, solar panels, radiators, etc are stuffed inside a payload or cargo bay, and only open it up once in space. Make sure you don't have any flat blunt surfaces with open attachment nodes facing directly into or away from the airstream (you need to cap the node with a part which approximately matches the size of the flat surface (example: 1.25m nosecone on the front of a 2.5m tank won't help much. Use a 2.5m nosecone). If you want to get fancy, try using "Wing Incidence" to build in the angle of attack on your wings. Wings in KSP need some angle of attack to generate lift, but fuselage parts with an angle of attack generate lots and lots of drag, so you want the body pointing prograde and the wings angled up so that you can get lots of lift from them. Proper ascent is very important. Engines are heavy, so you want as few as you can get away with, so you want to add just enough rapiers to take off by the end of the runway (even if that is done by literally falling off the end of the runway), and punch through the speed of sound. If your rapiers can get you to at least ~450m/s at sea level, you are good to go for the rest of the flight. Once you reach ~450m/s at sea level, you want to slowly start ascending, gently nosing up over ~30 seconds up to an angle of around 20-25 degrees. Hold this until you are getting close to 10km altitude, then begin leveling off very slowly. The ideal goal is to hit 18-20km at the same time as you hit around 1400-1500 m/s and finish leveling out. The goal now is to very slowly climb to around 21-22km while you finish gaining all the speed you can on rapier jet mode. You want to get to at least 1600m/s, even better if you can get over 1650m/s or even 1675m/s. Then, you want to turn on your nervs (if you have them) and swap the rapiers into closed cycle rocket mode (if you have oxidizer). You don't really need to pull up here other than a tiny handful of degrees. Your sheer speed and you approach orbital velocity will naturally push your apoapsis out of the atmosphere and raise your nose. Then you just coast your apoapsis and perform a small circularization burn to enter orbit. Some further tips: It may be that the above ascent profile makes you explode from overheating. Generally this is due to one of two things: either you have too much twr and accelerated too fast at too low an altitude, or you didn't use heat resistant parts. Ideally you redesign for lower twr (since that means less dry mass and thus more dv) or use more heat resistant parts in the areas that were most vulnerable. Generally, some good benchmark numbers when starting out are that you should aim for at least 20-25 tons of mass on the runway per rapier engine, and 1 wing area per 4-6 tons of mass on the runway (you can see wing area of a wing part by right clicking it in the part selection menu on the left in the VAB). The engine number can comfortably be pushed above 30, even to 36tons, when you are quite practiced at building efficient craft, and experts can go even higher than that when taking off from the flat area around the KSC instead of the runway, but 20-25 is good to start. As for designing a craft specifically for hauling an orange tank, you have to make a decision early on: will you use a fairing open at one end, or a Mk3 bay, to carry the fuel tank? Using a fairing is a lot lighter, but requires more expertise to build an effective plane, so we can throw that aside for now. You will need a long MK3 bay to hold the tank, and you can probably also squeeze in a reaction wheel, batteries, and solar panels in it on one end. If you don't want the craft to be crewed, we also need a probe core of some kind. We can probably target a total mass of the craft of 120 tons to start, so we will need around 5-6 rapiers, and 20 to 30 total wing area. One of the best wings for the job is the big s wing. It comes with free liquid fuel storage of 300 units in each wing, which saves on tanks, and has a wing area of 5, so you need 2-3 pairs of them. Then we add control surfaces, landing gear, and any other goodies you want. Lastly, we want to pack any remaining mass budget with fuel tanks. As a general rule of thumb, I have found that even with a very efficient ascent, you need at least twice as much mass of lf/ox mix for rapier rocket mode as you need pure liquid fuel for jet mode, but probably at least 3x as much so we have margin for maneuvering is space. Now it's time to test it. Take it out for a spin and see how it performs. Did it do amazing first try and reach orbit? Great, you can either take it as is and start using it, or if you are like me, see what tweaks you can make to make it even more efficient. Did it not do so great, and fail to reach orbit? It's time to debug. Probably if it can't it's an issue with high drag, you can see how much drag each part is producing individually in their part windows by toggling on the "Show aero debug data in part action windows" debug option in the cheat menu, Alt-F12 => Physics => Aero. There is also an option to bring up an Aero data GUI that will show you overall aero stats about your craft. And if you really want to go down the rabbit hole and start your journey to being an SSTO wizard, I recommend watching this video (it's really long but also really worth it): And if you want to take your wizardry up a whole other level, also check out my playlist "Kerbal University". Be warned, it's really dense so only jump in if you really want to go into the nitty gritty:

VertexColorMapEmissive VertexColorMapEmissive is a custom PQS Mod intended for use by planet modders to give more control over planetary emissives than can be achieved with the current alternatives: EVE CityLights and Kopernicus Expansion EmissiveFX Planet pack developers implementing VertexColorMapEmissive are encouraged to bundle it with their mod, for the convenience of users. Examples ScaledSpace: Place a VertexColorMapEmissive node in your ScaledVersion node PQS and/or Ocean Place a VertexColorMapEmissive node in the Mods subnode of your PQS Node and/or the Mods subnode of your Ocean Node Download Github SpaceDock Installation and Use Install ALL listed dependencies, following the links below Download and extract the VertexColorMapEmissive zip file Place the GameData folder into your KSP directory Once installed, simply add VertexColorMapEmissive nodes to the Mods subnode of your PQS Node and/or the Mods subnode of your Ocean Node, and to your ScaledVersion node Reasoning behind creation Qualities I believe an emissive mod should have It should cover ScaledSpace, PQS, and Ocean emissives with a single unified and coherent format. It should allow the use of a full color texture with transparency. it should not have visual artifacts with stock ScaledSpace, PQS, or Oceans. Features and comparison to alternatives VertexColorMapEmissive Pros Full RGBA colormap support Unified solution for ScaledSpace, PQS, and Ocean emissives No ocean z-fighting Cons No detail texture for close range variation Kopernicus Expansion EmissiveFX Pros Supports ScaledSpace, PQS, and Ocean emissives Cons Flat color value Map controls only alpha and brightness Ocean z-fighting EVE CityLights Pros Detail texture for fine detailing up close Cons Flat color value Map controls only alpha and brightness Detail texture tiling can become apparent when map covers a large contiguous portion of the surface Does not support Ocean emissives Parameters and expected values map: The RGBA texture to use as the emissive map brightness: global multiplier to the color channels of the map default value: 1 values greater 1 increase brightness, values less than 1 decrease brightness transparency: global multiplier to the alpha channel of the map default value: 0.5 values greater 1 decrease transparency, values less than 1 increase transparency 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 your 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 Q. Is this compatible with Parallax? A. In all honesty, I have never downloaded Parallax before, so I do not know. Q. Is this compatible with Scatterer oceans? A. No, it will not function with Scatterer oceans, only stock oceans. Licensing VertexColorMapEmissive is licensed under the MIT License

VertexHeightOblateAdvanced 1.1.3 What's new: Tweak folder structure to fix mod load order conflict Download Github SpaceDock

VertexHeightOblateAdvanced 1.1.2 What's new: Fix for VertextHeightOblateAdvanced using terrain altitude instead of radius for deformity calculations. VHOA should now behave consistently independent of load order when used alongside other PQS mods. radius parameter depreciated, radius is now directly inherited from parent PQS. Download Github SpaceDock

It should be possible I think. For more lava-ey lava from far away you will want to edit CindOcean in GameData\QuackPack\textures\pluginData CindEmissiveDetail in GameData\QuackPack\EVE\Textures When actually sitting on the ground near an ocean, there are issues with z-fighting between the emissive texture and the regular ocean texture I never really figured out how to resolve, but to make the ocean texture look better while sitting close to it you will have to change the Cind config to replace the default "water" textures with brand new textures (currently it uses build in KSP textures), which will be more difficult. When I next get around to updating QuackPack, better Cind lava is pretty high on the list.

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