KerikBalm

No, it doesn't

Regarding Junos, I have found an additional benefit for them, only since the update where engineers can add and remove parts. The benefit is simply that they can be added and removed by engineers (and not too many kerbals are needed to assist). I oftne make 2 stage craft, where the 2nd stage craft is a rocket-glider. When it lands, its empty or nearly so, with no really suitable propoulsion system. If I want to move it around to re-dock with its first stage carrier, its a pain in the cheeks when only the 1st stage has airbreathers/ fuel left, and I'm going to need to get both of them to an ISRU fueling station ot re-use them (such as when playing on a scaled up system and/or with alien space programs which move KSC off of Kerbin). Wheeseley are nice for thrust reverse, but I'd rather not use them as they are useless dry mass for most of the flight. Well, now, my ISRU fuel truck/first stage craft/recovery craft can just carry some Juno engines. Upon meeting the glider/craft that I want to be able to back up, I have an engineer mount some Juno engines and small fuel tanks, and now I can move my glider around, have my first stage craft back up, etc. I can also add enough Junos to allow the rocket-glider to fly on airbreathing power, and remove the Juno's before the next orbital flight. Their small size and mass that is compatible with the new engineer construction mechanic make them very versatile. They don't work like that. Air hogging is not a thing anymore. You don't need them to get past 20k without flameout. The benefit of precoolers and engine nacells is their high "static suction". I can use one shock cone intake to supply 4 or 5 rapiers at supersonic speeds, but going fulll throttle from a stop on the runway with such a setup will result in a flameout. Using a precooler/engine nacelle solves that problem. Goliath? tbh, I don't use it except on novelty airliner recreations. TBH, I almost never seriously use the wheesley or panther engine either. THe panther may see use as an early space plane engine before the whiplash is unlocked, and the wheesley may see use on a laythe sub, or some laythe airplanes that I want to be able to back up - where the thrust reverese is convenient for ground handling. The RCS/vernor engines, those are great... for RCS (esp if you don't want to rely on OP'd reaction wheels), they really help with docking larger ships, and are just handy for small maneuvers in space, as well as final maneuvering just before small on spaceplanes landing on Duna for example (particularly control during VTOL landings). tail connector A. I don't use it much, but it gets some use for light kerbin exploring planes early on, can also be used as a very low drag nosecone. The winglet and basic fin are usefull on expendable rockets for stability purposes Extra large landing gear? Oh I use that frequently on my large spaceplanes: The big drogue chute... yea, I rarely use it. Its aesthetically supperior to the radial ones, but really, just one radial chute is almost always enough to slow descent enough to use the main chutes. If its not, you may not want all the force going to one part, and distributed radial mount drogues may be better. Drogue chutes in general aren't so usefull except on Duna, and for stabilizing planes when landing (again, particularly on duna to keep them going straight), and here, the radial mounts are more versatile. Work lamps are useful if you don't want to wait until daylight to do certain things. The lights can be very useful, but are generally redundant with each other. I use the illuminator mk1 the most for landing at night, but the smaller lights could be usefull on rovers... again, if one insists on driving them at night rather than waiting for daylight. They are also just usefull for making your craft look cool.

I won't just tell, but show as well: Mars, but with Oceans, a larger relative size to kerbin than to Earth, O2 in the atmosphere, and some evidence of life: Olympus mons: Olympus mons in the distance: I made it a double planet with Duna: https://imgur.com/8wqyBkD (that one has a terrain "decal" that I haven't been able to remove when using Kerbin as the template, to get the better terrain shaders). Its gone through many iterations, played at different scales (1x, 3x, 4x, 6.25x), with different visual mods and atmosphere colors, in addition to surface G, atmosphere thickness, etc.

I would suggest that twin engine contra rotators are "simpler". IRL, yesm they are mechanically more complex (2 engines instead of 1, or complex gears to make one engine drive 2 contrarotating props), but in KSP, they are just so much easier. FWIW, I have barely used the turboprops, and instead mostly use the electric rotors. Turboprops just don't seem competitive with turbofans in KSP (haven't compared fuel efficiency, but its so much simpler to use a wheesley/panther/Goliath, all of which already have excellent fuel efficiency). If I'm using props, its for extra-kerestrial worlds without O2, but I also test them on Kerbin, they can go quite fast. Note, I have found that the "blades" give much better performance (at least at high speed) than the "props" I haven't compared efficiency of using fuel cells + electric rotors vs the air breathing turines. One would hope that LF consumption is similar, and its just the Oxidizer consumption that differs significantly, but I have my doubts. Never used it, seems like such a think would be convenient, much easier than manually adjusting blade angle. I suppose it depends what you are trying to do. Maximize fuel efficiency for a moderate speed cruise? or maximize speed - as seen above, you can get to nearly mach 1 with these props, but according to the part window, the blades are going super-sonic, and we've seen thats really load IRL (Tu-95 had prop tips going supersonic, and the XF-84H Thunderscreech was ridiculously loud) Generally speaking, I try to have RPM as high as possible, you can see in my screenshots that i have a rotor window open to monitor RPM. When RPM starts to fall, I increase torque (at least now one doesn't have to match the RPM setting to the actual RPM, before if you set max RPM at 460, but only achieved 230 rpm, it would consume power as if it was at 460 RPM, so reducing max RPM setting would reduce power/fuel consumption without affecting power output). I figure I want the lift vector from my blades to be pointing forward as much as possible for maximum efficiency, and that means higher RPMs (at least at significant forward speed, doesn't neccessarily apply to slow speed planes (helicopters). Also, I noticed that different types of blades have different optimum AoAs. Generally speaking, you want to keep the blades inedned for use in ducted fans to between 4-5 degrees AoA, but the standard propellor blades do better at higher AoA (I forget what AoA exactly, I think its more around 10). Similarly, the Helo blades have a different optimum AoA, I hope the mod takes that into account. You can use helo blades, I tried to use them in tilt-rotor craft: but so far I've had the best results with the ducted fan blades. The downside is, of course, higher part count relative to the massive helo blades.

Started planning for Rald colonization in my 6.25x game: A simple shuttle, with a cargo bay that an engineer can put seats in, extra fuel tanks, science, etc But margins were low, and after I finish modding the system, fueling craft in orbit will come only from Duna or Rald (Ike gets booted to the asteroid belt). Duna is.... not ideal for atmosoheric flight and landing the fueling ships. So I started working on a 2 stage solution for Rald, that can take more mass to orbit reusably: It needs to get over 150 m/s to take off, I'm hoping it will be more docile on landing, when tanks are empty (it does haev a lot of wing area). The thin air required using the closed cycle mode to lift it off the ground after it got airborne a little after a bump. Then I switched to testing on Kerbin, and trying to make a fully reusable (as opposed to recover at 100%, and launch a new craft from the SPH). cargo vessel based on it. Stage separation: Its not really meeting performance goals at the moment.

I've never used the https://wiki.kerbalspaceprogram.com/wiki/R7000_Turboshaft_Engine Generally, I only use the EC powered stuff.

Decided to update my planet configs, particularly Rald, to go along with the 6.25x game I'm playing. Increased Rald's surface G from 0.53g, to 0.637g. I accompanied this with an increasse in the atmosphere pressure at sea level from 0.2 atms to 0.25 atms. I also gave it a higher atmosphere height, so the pressure doesn't fade quite as fast. So... planes fly a bit better now in the thicker air. Rovers handle a little better in the higher gravity, and its generally a little more kerbin like. As its tidally locked to Duna and vice Versa, the days are a little shorter now (they were rather long). I found out that the orbital velocity is now about 4100 m/s (at 6.25x), and only about 100 m/s comes from the planet's rotation. I designed a non-nuclear SSTO crew shuttle with a science equipment bay. It made orbit, just barely, after a few attempts to get the ascent profile right. I may decide to do a 2 stage solution. I also think I want to resdesign it, to have the science bay located at the CoM, and make use of the ability of engineers to build on site to make the bay a bit more modular, perhaps carrying an extra fuel tank one time, a cargo container for small parts another, or science equipment yet another. A funny thing happened in testing the new configs though. I omitted a decimal point in the numbers of the atmosphere curve defining the slope at a certain altitude. I found that the atmosphere abruptly went away and became a vacuum at a pretty low altitude. (this was after I reached maximum airbreathing speed though and had gone closed cycle), I had to pitch up and use engine thrust to maintain altitude, and accelerated to nearly orbital velocity before I started climbing again (and also ran out of fuel). As the plane coasted up to apoapsis from a very low altitude, the atmosphere abruptly came back, and I hit pretty thick atmosphere pitched at like 30 degrees, at nearly 4,000 m/s. The plane disintegrated nearly instantly. Its completely unrealistic, but it did give me an idea for a novelty challenge. A planet whose atmosphere goes from 1 atm, to vacuum, back to 1 atm, then finally to space... Its quite an unusual launch challenge... but not what I wanted for Rald, so I fixed the problem.

No, just no. https://en.wikipedia.org/wiki/Scaled_Composites_Stratolaunch#Specifications_(Model_351_Stratolaunch) Performance Maximum speed: 460 kn (530 mph, 850 km/h) That's a maximum speed of just 236 m/s Well, the Sanger design did propose using ramjets: https://en.wikipedia.org/wiki/Saenger_(spacecraft)#Design The 2nd variant: https://en.wikipedia.org/wiki/Saenger_(spacecraft)#Variants would release the 2nd stage at mach 7 (I suspect the hybrid turbboramjet/air turbo rocket https://en.wikipedia.org/wiki/Air_turborocket would have a closed cycle mode like the SABRE, but without any of that precooler business, or the 1st stage would have rocket engines itself to boost higher).... that works out to roughly 2,100 m/s. That's a whole lot more dV than the stratolaunch gets you. The stratolaunch gets you freedom to launch into different inclination orbits, and simplifies nozzle design allowing one to stick with a more vacuum optimized nozzle without compromizes for high air pressure of the first stage. The 2 stage spaceplane designs like sanger (or even early STS concepts) have the carrier plane contributing large amounts of velocity to the 2nd stage.

Not exactly, I have managed to make 2 stage systems work... but they require getting the 2nd stage to orbit before the first stage falls too far back into the atmosphere. I find SSTOs on stock kerbin are plenty easy, that the added complexity of 2 stage designs is not worth it. On scaled up systems though, I often go the 2 stage route.

Alpha Centauri is 4.37 light years away. This it takes over 9 years Earth relative time at .25c Ship relative time is nearly 97% of that at .25c https://www.omnicalculator.com/physics/time-dilation But a hohman transfer to Eeloo apoapsis takes a similar amount of time, so we only need another 10-100x more time warp for ships traveling at .02 c or even 0.002c

How does this mod work with boats and breaking ground robotics? I want to install this mod because I am now playing on a 6.25x rescale, and, well, flying or driving or boating anywhere on electric rotors takes a long time (6.25x longer, to be precise :p). It's somewhat OK with rapiers and 4x physics warp at 1,700 m/s surface velocity, but forget about boats or planes using electric rotors (they don't work well with even 2x physics warp). Some rovers I made go >100 m/s and handle ok on 4x p-warp on Kerbin with 1 g, certainly not minmus)... But that's like travelling at 16m/s stock. This mod is really needed for the higher rescales It awesome if it could support BG electric planes. I'm imagining flying fuel tankers now going out to a splashed down dropship to refuel it, or a cargo plane going to transfer payload, would be great

This is the base mod that enables you to edit planet parameters, and make new ones. By itself, it does nothing really. This is the mod I use (which requires Kopernicus) to rescale planets: https://github.com/Sigma88/Sigma-Dimensions It hasn't been updated in a long time (seems abandoned), but it still works (although it does cause a few error messages on loading) Alternately, you could manually make config files changing the semi-major axis and radius of every body in the game.

Now that KSPs development has been finished for a while, all bodies (and thus all templates I may want to use) have high res textures, and no more waiting for mods to update, I wanted to go back and update my "Rald" planet, which goes where Duna is, and has Duna as a moon of Rald, with Ike being a more distant moon orbiting the two of them. First, in my old config, Rald was only 3.5x as massive as stock Duna, 2.79x as massive as my new Duna (which had its surface gravity increased from 0.3g to 0.376g), and 3.35x as massive as Duna with its new properties (surface G increased to .638g) Obviously, this should be a double planet orbiting a barycenter, and I would like to make it so. However, it seems Sigma Binary is defunct: I can't just make one dummy mass that Rald and Duna both orbit, because they need to have the same orbital period, and having them both orbit the same object means that the body closer to the barycenter will have a shorter orbital period. Obviously, as theyaren't the same mass, they can't be equidistant from the dummy barycenter. My solution was to make a low mass dummy planet for Rald to orbit (the "light barycenter") with an orbital period P, and for Duna to orbit Rald with the same orbital period P (so configured as a moon of a moon). Then I'd set SOI boundaries so that the dummy planet's SOI is never dominant overRalds/is completely covered by Rald's SOI (hopefully avoiding a naked singularity). This seems... fine, except if I want Ike to orbit the barycenter... and also for entry/escape into the system If I have it orbit Rald, its orbit will be a bit funky. Also for its orbital period, and also for the orbits entering/leaving the system, only 77% of the mass is taken into account. So... I thought about adding *another* dummy planet, with the combined mass of Duna+Rald (the "heavy barycenter"), but if it doesn't orbit the light barycenter/the light bary center doesn't orbit the heavy barycenter, then the rooting heirarchy is unclear, and I don't think Rald's SOI will cover the singularity. Also, it would involve orbits of miniscule or 0 radius, which I imagine will screw things up (having the rooted bodies orbiting at ridiculous speeds in ridiculously small orbits with ridiculously small orbital periods). So that's out... Maybe I just put Ike as another asteroid belt object ot keep Dres company, and accept the fact that entry/escape only takes into account 77% of the mass, and use the low mass barycenter? Alternately, I see a "barycenter" parameter for Kopernicus (https://github.com/Kopernicus/kittopia-dumps/blob/master/Configs/Duna.cfg ) " // KittopiaTech - a Kopernicus Visual Editor @Kopernicus:NEEDS[!Kopernicus] { Body { name = Duna barycenter = False " Can anyone explain what that does and how I might use it to make a binary system orbiting a barycenter?

You just make a .jpg file with different colors for your biomes. Example for Duna: You can find more here: https://github.com/Kopernicus/kittopia-dumps/tree/master/BiomeMaps In the Kopernicus config (example for duna here: https://github.com/Kopernicus/kittopia-dumps/blob/master/Configs/Duna.cfg ) You just define your biomes, using the Red, Green, Blue, values for the colors on your map: In that example above, the poles are white, so RGB is 1,1,1, The lowlands are orangish, so have high red value, but low green and blue (color = 0.913725495, 0.41568628, 0.192156866, 1). The last "1" is the "Alpha" value I think, IIRC, its basically a multiplier for all the other values, just leave it at 1. So draw your biome map, and use the RGB values (if your color tool gives you values from 0-255, just normalize, ie divide the red, green, blue values by 255). Of course, you probably want to have your biomes match a heightmap, so something more complicated than MS paint would be nice to be able to display a heighmap image in one layer, and allow you to paint a biome map over it in another layer.

IIRC, it only causes problems when one body crashes into another. If an unstable body is simply ejected, I think its fine. That is to say an initial unstable configuration that can stabilize would be tolerated, no?

I agree, they are a pair. I wouldn't complain that one side of minmus looks like the other*, so ditto for this planet pair. The should be broadly similar, but different in details like arrangements of mountain ranges, fissures, craters, etc. Similar to how the minmus flats are broadly similar, but differ in size and shape. *I do think many stock KSP planets are too uniform, one never sees the diversity of features as seen on Mars for instance Sure, Kerbin has a desert, mountains, and some rivers, but where are the canyons, mesas, volcanoes, rift valleys, etc...

Well, that's harder than reality. Engines in reality have much higher twrs, tanks have better mass ratios, hydrolix engines get you 450+ Isp, but in KSP the chemical engines top out at 350 (380 with making history) I use Kopernicus and sigma dimensions to rescale it

To get more realistic payload fractions and ship performance, you need to rescale the system by 3-6x. I currently play at 6.25x with stock parts. It's hard, but doable.

If you want the fastest jet speed possible, use rapiers, not a whiplash. >1700 m/s easy. Those planes weren't meant specifically for high speed atmospheric flight, but rather for lofting a 2nd stage up to high altitude and high speed, so that the send stage can get to orbit (on a 3x or more rescaled Kerbin) before the 1st stage falls back in the atmosphere. The 1st stage does end up having a lot of wing area, and a lot of jet engines, and minimal fuel, so it ends up cruising fast and high on kerbin, but obviously if optimized for just fast flight on kerbin, it wouldn't be carrying around empty LFO tanks

May I suggest that you are just building your airplanes wrong? ^note the above is a 100% stock craft on a 3x rescaled Kerbin^ Here's stuff at 1x (from a while ago now): Payload fraction I said. They do have a problem with that, especially at larger scales, you did ask about mods. Yea, recovering only the upper stage doesn't help much. You've implicitly conceeded that you are throwing away all the lower stages... which are much larger and much more expensive. With a spaceplane, you don't need to do that. In stock KSP, you can fairly easily go to from the surface of kerbin, to the surface of minmus, and back to kerbin, for 100% recovery (just the cost of fuel). The same can be done for Mun. How much does an entire Mun or Minmus mission cost to you? because in stock KSP, with planes for me, its dirt cheap. Its really really easy to get spaceplanes to orbit in stock KSP. and they don't have large dimensions unless they are taking large payloads. As they have much higher payload fractions than rockets, they are smaller than a rocket for the same payload size. Reentry is easy, the spaceplane parts have a high enough heat tolerance as it is. Heat shields aren't needed for reentering from low kerbin orbit. They are usefull for plowing into Kerbin's atmosphere from an interplanetary trajectory, or for plunging into Eve or Jool or direct aerocapture at Laythe, but just returning from Kerbin orbit? just pick parts with a decent heat tolerance. Relatively easy, they land real slow once the payload and fuel is gone. I can do 100 tons to Jool intercept fully reusable in stock. How much would sending 100 tons to jool intercept cost you with rockets? A pittance? well then everything in KSP must be a pittance. Its still vastly cheaper than rockets, because as I said, they have a much higher payload fraction. Of course, I agree that the stuff you mention is mostly useless mass in space, which is why I leave them in Kerbin orbit, and don't pursue Single-stage to anywhere designs like some people do - Instead I pursue cargo capacity to orbit. Going up to larger scales allows you to make recoverable 2 stage to orbit designs practical, in which case, one doesn't even take most of the wings and engines to orbit (just on a suboribtal trajectory). The 2nd stage can have tiny wings and landing gear (as for the "fusalage" its just a normal fuel tank, same as that used on rockets), as it only needs to be able to fly and land when empty. The first stage has most of the wing area (and airbreathing engines) to support flight when full. This thing is fully recoverable at 100%, even at 6.4x Kerbin, when orbital velocity is over 6,000 m/s It also works for making reusable Eve shuttles. Couple it with ISRU, and you can have free trips back and forth down to the surface of Eve. Do that without making a plane...

Well, if I were going to make a ground relay network, I would use something like this: The DNS lvl 3 is just 250G strength, but this guy, with 25x RA-100s, has a strength of 100G * (25)^0.75 = 1118G, over 4x the power of the lvl 3 DSN (resulting in over double the range). Keeping it on the ground is much easier than launching something similar into space. But in space, you only need one (on a very highly elipticla orbit, it essentially has line of site to 99% of the time. An alternative is to put your first uncrewed rocket directly into a geosynchronous orbit. The mechanics should work out that you end up with line of sight to KSC

You seem to have zero AoA, meaning that your wings are producing no lift on the runway. That will make it very hard to lift the nose up with just the force from the elevons. Try using the offset tool to raise/lower landing gear as appropriate to that your nose points up a bit when on the runway. Also consider just giving your wings some incidence,

How is that a problem? you think it negatively affect performance? they are all in one tab, so it doesn't really evenclutter your part selection Airbreathing planes get the best payload fraction to orbit. How is that not useful? If playing career, a winged vehicle is much easier to get back to KSC for 100% recovery than a non-winged vehicle relying on parachutes or a retroburn after just decelerating in the atmosphere along a mostly ballistic path. Wing parts can also be useful for extra drag for aerobraking when going interplanetary. The same parts are also useful for rockets to keep them stable. What part don't you have a use for? I'll bet I could think of one

They aren't great... but they are good for "fun" small single kerbal planes, small explorers on laythe for surface feature hunting/biome crossing. They can even be used to make 0.625m SSTOs, but just barely. You can send up small SSTOs with a Juno engine to gather missing grav data, or to funtion as a quick relay... but yea... they aren't great. They are niche, rather like Panther engines. The panther is generally inferior to the whiplash, and only has a niche for "fun" designs"... but you can then make the argument that all the jets that aren't rapiers are useless, because they are all inferior when it comes to getting things to space. Yea, I use it to make pilots obsolete. Probe cores have issues with plasma blackout and signal loss. I forget what happens when you have a kerbal and a probe with SAS but no signal. I think you retain control and SAS function, no? I don't use them for the perpetual mining machine thing... but they are more mass efficient than batteries and RTGs. I have used them with robotics on some Eve ascent vehicles that eat up a lot of power climbing through the atmosphere. Solar panels break off, or overheat on reentry (or just don't face the right way). I use many batteries as a buffer (since their output is instnataneous, but RTGs can only supply so much power per unit time), but they start to add to much mass. RTGs just don't put out enough power. Fuel cell arrays fit the bill. This particular design is a fully stock reusable Eve cargo shuttle. The prop+rocket carrier goes on a suborbital trajectory, the 2nd stage carries the payload to orbit: I can switch back to the 1st stage before it falls too far into the atmosphere, and fly it back to its launch poing, to be refilled by ISRU Of course, the fuel cell arrays didn't produce enough power at the end of the climb (power consumption increased as I got higher and the blades had to spin faster to keep it in the air in the thinner air). Yes, it had a lot of batteries (it also needed mass upfront to balance when fuel tanks were empty), yes, when fuel is gone, they stop supplying EC. Yes, they cannot be "recharged" by a solar panel like batteries. However, that's all fine. This design has a large battery buffer, but not large enough when the plane is fully loaded. With fuel cells, it has enough power to reach its maximum altitude. When EC is gone, it lights rocket engines, whose laternators refil the batteries. It can also land and slowly recharge batteries. That means it can fly back to its launch point, where an ISRU miner waits to refuel it... allowing the fuel cells to do their job again (after the orbiter comes down and redocks with the 1st stage). Without the robotics though, the fuel cells didn't have much use.... the only designs I remember using them on, were rovers like this: (although the fuel cell is not visible there, the LFO tanks for it are). Similar designs: that went along with a mining base, but also fit in a mk3 bay so the rover could be transported by dropexcrements (the rover is 2 parts, docks inline for transport, side by side for more stability when roving). I admit, solar panels are adequate, but like that, it could also rove around at night, using headlights, transmitting data rapidly, etc. Fuel cells get my stamp of approval, I actually use them.

Is G on an island? E? A? Do you have any floating relays. I see F on the coast. Do you deviate a bit from the cuboctahedron a bit based on Geography? If so, have you looked into optimizing it a bit by making use of mountains? A 0.85 occlusion modifier means that signal is only blocked at 85% of the planet's radius, no? Doesn't this mean that the signal line has to pass within 510km of kerbin's center, instead of 600km, to be blocked? That should allow much more than 60km line of sight. Kerbin's radius is 600km, so its circumference is almost 3,800km. to just get around the planet with a ring of stations, each only would need to be able to see about 500km. Did you drop a zero did you mean 600km, not 60? FWIW, I play at 0.95 atmospheric occlusion, and 0.99 vacuum occlusion. This setup wouldn't work for me.