herbal space program

Sorry, I did figure out that's what you meant, but not until after I had replied. True, but it also means you can ditch all that extra fuel you needed to power the fuel cells, probably in turn significantly reducing the number of rotors/blades you'll need, not to mention all those batteries! In general, it also looks like your plane has more torque than it needs. When I'm flying the one above, my 10 small rotors don't get near their max RPM until I am approaching the top of my envelope, which is around 20km for that plane. It's able to do that using just the power from the OX-Stat panels you see, although the sun angle does need to be fairly high for that. It also carries only ~6K in electric charge. Of course it is nothing like the behemoth that yours is, but at 82 tons it's no paper airplane either! And although I understand your issue about part count, the small rotors have 20 times less torque than the big ones, but weigh almost 40 times less. I never actually found a situation where the bigger rotors performed better. I'm pretty sure hypothesis 2 is correct. When I had the panels mounted backwards behind the nose cones, I was not actually able to do anything that snapped them off, although I didn't push it all that hard. I imagine a large yaw excursion could be problematic, but OTOH maybe having that nosecone in front just reduces the panels' drag beyond all reason due to how the aero model works. I will see how far I can push it later today. I'll also mention that you don't really need to go all that fast to use props to lift you out of the soup on Eve. I unfortunately didn't take a snap, but I don't think I was flying at even 200m/s when I was at 20 km in that plane. Absolutely! Indeed. You might also consider replacing 2 Vectors and their tank(s) with a Twin Boar if you don't want to move up to 3.75M fuselages, although you'll take a bit of a hit on ISP See my above comments about the rotors. When was making my first prop-driven Kerbin SSTO, I found that 6 large turbine blades on a small rotor gave me the best performance overall, with max RPM happening only near my operational ceiling. Based on that, you should have something like 120 blades on those big rotors! FWIW, I also found that offsetting my blades outwards a bit gave them more lift per blade at the expense of requiring more torque, with the caution that you'll need a bigger nose cone because exposing the blade bases to the wind creates terrible drag. Absolutely!

Perhaps you could mount them to small nosecones embedded in the trailing edges of your wings so that they extend backwards? If they're mounted vertically, then pitching up probably wouldn't snap them off, although turning most likely would. I'm kind of curious about it now, so I might try fooling around with that type of design myself in the sandbox later. One thing I can tell you, although you probably already know it, is that the aero forces low in Eve's atmo are just brutal. I've often snapped off wings that were strutted out the wazoo by turning just a little bit too aggressively. (edit)... And it actually seems to work! I tried mounting a pair of Gigantors to my existing Eve plane, first facing outwards. In that configuration, they caused massive drag and snapped off right at 100m/s: If OTOH I mounted them to the backs of my rotors facing backwards, they caused a lot less drag, and I couldn't get them to snap off even at >140m/s: Teleporting the test to Eve didn't seem to change anything either: So I'm gonna say, yes, you could actually do it that way!

I don't think it's ever good for a rocket to have a TWR of less than around 1.4 at takeoff. You'll just be throwing a bunch of dV down the gravity hole. In fact, I'd say my most efficient lifters generally start at around 1.8. With the aero model as it is, what you shave off in gravity losses that way far outweighs what you'll lose to drag in the lower atmo. If you've hit it right, your limiting factors should be staying in control through max Q, followed immediately by not burning up before you get above 25km. At least in Stock. I have no idea how RSS might alter that calculation.

Making a regular SSTO plane that can fly to Duna and back is actually pretty easy because the low surface pressure and gravity make it possible to take off on just Nervs. The main thing is just to have a lot of wing area: I also found it helpful to mount drogue chutes on the trailing edges of the wings for landing, to mitigate against the high stall speed and the tendency to bounce in the low gravity:

It all really depends on what your constraints are. Early in the (career) game, part count is a major limitation, so landers that can make it all the way from LMO to landing to home are the best. Later in the game, having autonomous transfer stages, aka "motherships", that drop off and pick up landers at various target bodies is clearly the most efficient way to go. When I was milking Mun for all its science in my current career game, I had an orbiting transfer stage/mothership module that refueled the lander module four or five times so that it could collect surface science from different biomes.

Oh there was definitely some discussion about it. It's absolutely a problem, especially with the legs since you can't tweak them like the wheels.

How do you make those rotors without the BG DLC?? (edit)...So each propeller is a separate craft that you undock into some kind of cage and then switch to and spin up with reaction wheels? Boy that must have been hard to get working. I'm impressed!

I spent some time trying to make a propeller-driven SSTO plane that could operate on Duna and ended up scrapping the idea, mostly because the operational ceiling on Duna is too low for the props to make much of a contribution. Just making something that can take off and land on props is not so tough however. Just keep it light and have lots of wing area. As to how to get it there, landing it from orbit should not be a problem. It's putting enough engines and tanks on it so that it can get back to orbit and still fly reasonably on props that's pretty tough.

What I call a transfer stage is the whole part of the ship that does all the pushing from LKO to low orbit of whatever the target body or bodies are. It can have any number of engines, but they will always all be firing together, as that is clearly the most efficient way to do things. As my TWR gets higher than what I need, I'll generally drop them in pairs to trade that excess TWR for more dV. So if I have a core stack surrounded by three pairs of asparagused side boosters, is that one stage or four? I think what you are talking about only really applies to stages that are stacked on top of each other, which is quite clearly not the most efficient way to do things in general because the upper stages are all dead weight until they fire. Which raises the question of what exactly do you mean by maximizing performance anyway? What I am talking about is optimizing the tradeoff between having enough TWR to get off the ground and do your other burns relatively efficiently, and also having enough dV to get where you need to go. Any other measure of "performance" is pretty much only of academic interest in my book.

The first part of this may be roughly true for ascent stages, but I think transfer stages with their much lower TWR requirements should pretty clearly have more dV than the ascent stages for best performance. As to the last part, it kind of depends on what you consider a stage. Asparagus staging is pretty clearly the most mass-efficient way to get to orbit, because it allows you to shed superfluous dry mass at the highest rate that your constraints of TWR will allow. My ascent stacks therefore typically have 4-6 side boosters that are dropped in pairs from a core stage so that the overall TWR starts pretty high and gets lower as the ascent progresses and gravity losses become less of a factor.

I'm not really so keen on having everything be scalable, as that's not particularly realistic wrt real world rocket engines/pods, and it would also be a huge headache (i.e bugs, delays) for the devs to implement. Procedural wings and control surfaces OTOH are something I would consider a must-have. I am tired of all my planes looking like they were slapped together out of stuff found lying by the side of the road! I think also that letting the user change just the length of the tanks of different cross sections, perhaps as well as being able to freely distribute their available capacity between LF and Ox, would neither be very hard to implement nor unrealistic. Similarly, allowing the lengths of different adapters and girders to be user-adjustable seems reasonable to me.

Uhhhm, don't build such a ridiculously gigantic ship? But seriously, the same rules of thumb wrt TWR and dV apply on all scales.

As has been said several times, every stage you add will increase overall dV unless it has a TWR <1 for its full burn while still on the ground. For my part, when I'm designing rockets I have two key considerations in mind: the ultimate dV required to deliver the payload to all its destinations and the TWR required to get through each of the phases of that process efficiently. In general, the more TWR you have in a given stage the less dV that stage will have, so I try to only have a high TWR when I really need it, which is for takeoff and landing, and use a lower TWR for all other phases of the mission. So to illustrate, let's say I'm doing a Tylo flag-planting mission with a Tylo orbit rendezvous design. I'll start by building my lander ascent stage so that it has a TWR of around 1.4 (on Tylo) at takeoff, maintaining that or higher TWR for at least the first third of the total dV required to reach orbit, which for Tylo would be something like 800 m/s . For the second third, I would start at a TWR of around 1, topping out at maybe 1.4 again, and for the last third I might start with a TWR as low as 0.5, topping out around 0.8. To this I would then add a descent stage that has the same overall dV as the ascent one, but starts at a TWR of at least 0.5 and ends at a TWR of at least 1.4. Once I have that built, I would assemble that package to a transfer stage that has enough dV to take the full lander from LKO to LTO and then just the empty ascent stage from LTO back to a Kerbin encounter, with a TWR that remains somewhere between 0.2 and 0.4 for its whole journey. Usually I'll do this by assembling my near-empty Tylo ascent stage to the 2.5m core of the transfer stage with enough tanks and Nervs on the bottom for a TWR of 0.25 and something like 2.8 km/s dV in that configuration. Then I will fill the tanks and add my descent stage to that, and take note of the dV with those added. I'll then start adding paired, asparagused side stacks of Mk1 fuselages and Nervs to this, until I've added another 2.8 km/s of dV to whatever the display showed before I started adding them. In this process, I'll try to keep the TWR between 0.2 and 0.4 for the whole burn time of each asparagus stage, setting it up so that each stage will run out of fuel right as the overall TWR reaches 0.4. Once all that's built, I'll usually mount it on top of a 3.75m core stage with a Mammoth engine that has a starting TWR of right around 1 and maybe 1.8km/s total dV. I will then put an asparagused pair of Mainsails on the sides of that, so that I'm adding another 700 m/s or so of dV at a starting TWR of maybe 1.2, and then finish it with a pair of giant SRBs to add another 700-800m/s of dV at a starting TWR of >=1.4. Anyway, that was rather a complex narrative, but if you follow that sequence you should end up with a vessel that can get the job done with a reasonable if not perfectly optimal level of both efficiency and flyability, and without getting fancy about gravity assists.

I'm not quite sure exactly what you mean by this, but certainly (especially earlier) versions of the contracts system had you doing the same stupid stuff over and over again ad nauseam, and that really must be avoided going forward. I do think they've already improved it significantly however, based on my current career game, where my objective was basically to do everything exploration-wise as quickly as I could and not let the available contracts dictate my agenda any more than necessary. I still ended up having to do some fairly tedious stuff though, so there is obviously still plenty of room for improvement. IMO, like websites and search engines these days, the game needs to sense what you are most interested in doing and try to serve you contracts that are in line with that. It seems like maybe it's doing that a little bit now, but it could definitely be doing it a whole lot more. There also seem to be big holes relative to what people frequently like do in the game, like for example why are there no SSTO or K Prize or other aviation-based contracts? And I spent almost a whole year with a full Jool 5 mission in-system before I got a single Jool-related contract. And perhaps all this would all indeed be better if there was just some sort of mission tree, where you have to accomplish certain things to unlock its different branches, but then that runs the risk of becoming too repetitive.

I'm not sure the overhaul needs to be quite that radical in practical terms, but in philosophical terms the whole idea of calling them "contracts" speaks to something that has little to do with how the real-life early space program worked. What we should be working to get should be more accurately defined as "appropriations", which are money that is granted with certain objectives in mind, but can also be used for side projects if the core aim has been satisfied. Notable accomplishments beyond the objectives of the specific appropriations should give you reputation currency that betters your position for future rounds of appropriations.

I definitely don't want weapons, at least in the stock version, and I most definitely don't want DLC that lets you pay money to avoid having to solve problems yourself. Beyond that, I don't want the same dumb organization that the KSP1 tech tree has. You have to upgrade the tracking station before you can get out of your capsule, even if you're sitting on the ground? You need fourth-tier tech before you can even have a bleepin' battery on your vessel? They really need to rethink all that nonsense.

How about Gilgolly: a slow-motion concretion (ala Ultima Thule) of 4-5 roughly spherical, Pol-Gilly sized Kerbuiper Belt objects, each with different colors and compositions. It has recently been captured into a highly eccentric and inclined orbit by one of the gas giants, and is now early in the process of getting turned into one spherical object by tidal flexing and heating. The fissures between the separate bodies have several large, continually gas-venting openings that lead to a system of massive internal voids, at the center of which is a growing spherical body of liquified material. Evaporation from the developing liquid core generates a ~15kPa internal atmosphere that is half oxygen and half nitrogen, and thus supports air-breathing engines. Some of the individual bodies can be mined for LF/O with very high efficiency. ....or perhaps Oy: an Io-like body that is in a super close, tidally locked orbit around its gas giant parent and has an SOI that actually penetrates into its parent's upper atmosphere. This would perhaps make it possible to fly from the depths of the parent body and then get a gravity assist to orbit entirely on wings. ... or maybe Pip: A small but hyper-dense body, with a surface gravity like Eve's but little/no atmosphere. Very hard to land on, but resource-rich, perhaps even a unique source of some key resource like metastable metallic hydrogen. Can also be used for insane gravity assists. I would find that fun just about anywhere.

I totally like the idea of making rescues get more complicated somehow, beyond just making the locations more remote. I'm not sure if this was an artifact of updating to the new inventory system in the middle of a game, but my last Kerbal rescue contract was around Duna, and when I finally got around to picking the stranded Kerbal up from his dead capsule, it turned out he didn't have an EVA pack in his inventory, and neither did any of the crew of the rescue vessel. That sure made things more difficult, especially given the large size and docking port wobbliness of the rescuing vessel! It ended up taking me almost an hour to finally get a hatch close enough for him to grab. I can't say that I found getting blindsided by that particularly fun, but if I had known that was the situation, I could have planned for it. As to your idea, I don't know so much about the whole injury aspect, but making it harder to find them in later rescue contracts sounds like a great idea to me, as does immobilizing them somehow. For example, they could be in a lander that's on its side, with its antenna broken off and its exit hatch obstructed by the ground. The game would give you a general area of where the crash happened, but to actually find the stranded Kerbal, you would have to get within some range like 10km to get a navigation signal from their EVA suit radio, and then within physics range perhaps to actually be allowed to switch to the stranded vessel or Kerbonaut. Then of course you would have to figure out how to right the vessel to do the rescue, and then perhaps even make some repairs to it so its occupant can fly/drive it to some predetermined location themselves. There would be a lot of possibilities in that vein.

There definitely couldn't be a black hole in the middle either, but I really like the idea of having a low-gravity body with big voids inside it!

In fact, once you're done with that, you might try rolling around the KSC a bit and seeing what other science you can pick up!

Every time Squad says it's fixed the wheels, what it really means is that it's broken them differently. There have been several bug reports about this, so hopefully they will fix it in the version that they'll release when KSP 1.12 is actually ready rather than this ambitious but hasty pudding prepared for the 10th anniversary of the original release. I was in the middle of a sprawling late career game when I installed the update, and there is stuff broken all over the place now. The new maneuver node/ transfer planning feature doesn't seem to work at all either, although that doesn't really matter to me.

This is true except with the proviso that if you come into a body's SOI parallel to its motion and with more orbital energy than it has, you can only lose energy from the encounter. Hence my recommendation above for the initial Tylo assist.

I don't even really know how I pronounce it, since the only time I ever talk about Duna is in writing, here in this forum.

This is obviously a very open-ended question, but as a rule of thumb I would have the first ~2,000 m/s of dV that my stack has at a TWR of >1.4, and the next 1,000 m/s or so at a TWR of >1. That should be plenty to get you to LKO if you follow an efficient ascent profile. After that, unless I plan on landing anywhere, I find that a TWR of 0.2-0.4 is sufficient to do all necessary orbital maneuvers without it becoming too tedious. Making a transfer stage with Nervs that has that sort of TWR and upwards of 5km/s dV is pretty straightforward, and with that much dV you can get to pretty much anywhere and back without getting fancy about gravity assists.

If what you want to do is an easy flyby/return mission, Duna has the very useful feature that a Kerbin-Duna Hohmann transfer orbit also happens to be almost exactly a Kerbin 3:2 resonant orbit. That means you can set it up so that you just graze the Duna/Ike SOI's and then return more or less automatically to Kerbin 2.25 years later, after two orbits all told by your vessel and three by Kerbin.