herbal space program

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.

The easiest way I know to get captured in the Jool system is to come in so that you encounter Tylo while going nearly tangent to its orbit and in the same direction as it is. That should be pretty cheap to set up from >100 days out, and can be used to go directly to a Laythe encounter that will allow you to set your Jool AP pretty much anywhere you want.

On a PC, what you would do is alt-right click on each of the destination tanks as well as the source tank, and once they're all open, click on the "out" button below the source tank's LF/Ox sliders. That should send the resources flowing evenly into all the destination tanks.

You are very welcome! I'd love to see what your mission looks like when it's done. One thing I didn't mention before is that if you're going straight to the ~2:1 orbit like Juno, you won't need to do quite as big a retrograde DSM burn at AP as I did just to get to Jool. I deliberately sent myself to a higher-than-needed AP to maximize the amount of solar retrograde motion I could get out of my Jool encounter. You could probably get to Jool with only a ~150m/s retrograde burn there, but I have not personally tested that, at least not recently enough to remember the numbers.

I've resisted getting something like this in the past because I got a kick out of trying to figure these things out in a more seat-of-the-pants way, as if I were Jeb. It almost certainly never created the most efficient solution, but my sense of accomplishment about it was greater. It's the same reason I never really used MechJeb. I wanted my designs and mission plans to be robust enough that I could fly them with my own hands. But at this point, I feel like learning how to use a tool like the above-linked to plan long chains of assists could be a new frontier for me.

I've had exactly the same problem with a little rover that I'm using a hinge/docking port arm to deploy and stow. To my knowledge, I was not using autostruts on that craft. Like @Dientus said, turning off SAS immediately after docking was what fixed it for me. Adjusting stuff about the motors no doubt could work as well, as does turning off all the reaction wheels in the smaller craft, but those maneuvers are more cumbersome and not really doable after the fact when everything is flopping about. The SAS code has never been all that good at damping rather than amplifying oscillations around wobbly joints like docking ports, especially if what's on one side has a lot more control authority than what's on the other. If you think of it as riding a playground swing, it tends to stick its legs out when it should be pulling them in and vice versa, especially if the lag time between applied force and motion is different between different reaction wheel modules.

Your problem in a nutshell is that your plane is too nose-heavy. To fix it: 1) Move your engines downwards , so they are closer to your center of mass and therefore not pushing your nose towards the ground all the time. 2) Move your nose wheel as far forward as you can, and displace it downwards a bit, so that there is less weight resting on it and your nose is a bit higher than your tail. By the looks of it, you could actually displace your rear wheels downwards a bit as well to give your tail more ground clearance. In any event, the rear wheels should be fairly close to your Com and the front one as far forward of it as possible. I'll bet if you just do those two things, your plane will take off and fly a whole lot better. Just make sure also that the CoL indicator in the SPH is just a bit behind the CoM indicator. If it's not, offset either the wings back or the engines forward to get it there. I say that because it could be that your CoL is ahead of your CoM the way the plane is now, but the resultant tendency to pitch up is being offset by the high placement of your engines. ....Oh, and disable the steering on your nose wheel if it's on. That usually responds so strongly to control inputs when you're going fast on the runway that it's more likely to put you in the ditch than keep you going straight. Lowering the friction setting as suggested above will largely do the same thing by nerfing your steering authority. ...Lastly, putting a tail fin on it couldn't hurt, as you have nothing but your cockpit right now to give you any yaw authority.

I'll have to check it out then. I'm able to manage these types of one-body resonant ladder ascents/descents with Excel, a calculator, and a scratch pad, but I have no clue how to really optimize them.

Does this actually tell you how to plan these Juno/MESSENGER-type DSM's to get one or more assists from the body you just ejected from? If it does, I want it!

Looking up the Juno mission, I see it did only one Earth gravity assist to get to Jupiter. I've done something similar before to get to Jool for ~1380m/s dV from LKO, but I used two Kerbin gravity assists instead of one. I first ejected to a roughly 3:2-resonant orbit, lowered my PE from the AP of that by burning retrograde for about 80 m/s, then did another another ~37 m/s burn at the second Kerbin orbit intersect of that orbit to set up my first Kerbin gravity assist 1.5 years later. I used that to put me up into a 2:1 resonant orbit, from which another AP DSM of ~207 m/s allowed me to set up my second Kerbin gravity assist, which was more than enough to get me to Jool. The process is reasonably well-documented in the first few images of my Retrosolar Rescue challenge album here: https://imgur.com/a/5URWb. If you want to do it that way, you should launch around 5.2 years before a regular Jool transfer window. The first of these which you can use for this happens on Y6, d413 by my calculation, and then another will occur about every 472.5 days after that. So your first launch date should be somewhere around Y1, d 327, or any integral multiple of 472.5 days after that. If you really want to do it with just one assist, then you'll have no choice but to boost directly to the Kerbin 2:1-resonant orbit (i.e. a period of ~852 days), and then do what was my second DSM from the AP of that. For that you will want to launch around 2.2 rather than 5.2 years before a regular Jool launch window, since you'll only be doing the one orbit before your gravity assist. For that you could actually use the third Jool transfer window in the game, which happens on Y3, d275, for a launch date around Y1, d190. These numbers may not be 100% accurate, because my estimate of an extra 0.2 years is unfortunately just that, but there will be a decent amount of wiggle room on your second gravity assist if you find yourself coming in ahead of or behind Jool. Anyway, that was probably a fairly bewildering explanation, but if you look at my pix and then fiddle about some, I think you'll find its not as hard to work out as all that made it sound. Just make sure to fly to LKO like 40 days ahead of the launch dates I suggested and quicksave as soon as you get there, in case you need to move your ejection burn forward or back. You probably won;t need to, but if you do, whatever the phase angle is between your Jool orbit intersect and the target position marker from your best gravity assist, just move your ejection burn that many degrees forward/back in Kerbin's orbit on the next attempt and it should work fine. Good luck!

Yeah, after I made that comment I went ahead and played around with some of those older weapons, and they're quite a pain to implement by comparison.