Wobbly Av8r

So the short story suggestion is to add reaction wheels sufficient to overcome the gyroscopic wobble but the SAS mode of those reaction wheel(s) must be one which is aligned with some non-vessel-defined reference, such as Radial Out or Normal, which references the body being orbited. Venturing a guess as to why (longer story) is that, because rotating any mass creates an axis along which the torque is directed, if that axis does not align *perfectly* with coincident forces (direction of travel, for one), it will impart a "divergent" force. Aligning TWO rotating axes would create a situation where EACH rotating body axis creates a feed-back loop with the other, as well as both influencing the direction of travel. So even if your rotational mass balance is identical, my guess is that round-off error might be enough to destabilize things; most folks call this the Kraken because of the way Unity resolves connected, harmonically destabilizing forces: Sudden Unplanned Disassembly. So the bottom line is you may be able to salvage the situation if you have enough reaction wheel force to overcome the imbalance (whether by mass or round-off error) that is externally referenced to the vessel - otherwise you'll just give it yet another feed-back mechanism to summon you-know-who...

The truth of the matter is that, for whatever reason, the Cd of Flea in the tutorial is around ~0.23 and in game (Sandbox), the Flea Cd is ~0.04, a difference of more than 5x. (For those unfamiliar, the amount of aerodynamic drag on an object increases exponentially with airspeed, taking into account air density, multiplied by the Coefficient of Drag (Cd) which is mathematically how the shape of the object influences the amount of drag). This is always good to remember when someone complains such-and-such isn't 'realistic'... it is what the program says it is -- not reality -- despite the attempts to make them similar.

Exactly - depending on how you attached things back at the VAB, the nose cone may be acting as the leading edge despite the heat shield (again, I've had similar problems of the same issue and had to experiment with what 'hid' the part getting too hot. I think you're almost at the solution!

One last idea based on issues I've had: Parts that have unnaturally high drag will also incur huge heat penalties on reentry. These are not always obvious - they 'look' streamlined but internally/programmatically, they are very inefficient. One such example I encountered was a thrust plate shroud that allowed the probe core underneath it to heat up even though it was sandwiched between two large fuel tanks and not subjected to aerodynamic forces... supposedly. In your case it could be something like 'because the front of your fairing is not fully closed (terminates against a heat shield) the underlying components are taking the full brunt of the reentry heat', or something along those lines. Just another idea, FWIW.

No problem - sorry I wasn't able to help. Good luck - it'll be interesting to see what you find as the final resolution... [ Edit: Maybe your 'nuclear' parts are internally generating too much heat? ]

There exists the idea of heat transfer between parts - you can read about it in the KSPedia (the in-game instruction 'book'). If that is too much reading, you can prevent your type of problem by ensuring that the part that the heat shields are attached to are rated at, say, 2000K. Typically the parts that fail in the manner you've described are usually only rated at 1200K (sometimes 1400K) which allows the heat transfer between adjoining parts to far exceed that relatively low value even though the heat shield is rated much higher. [ Edit: If the part that is getting too hot must be used, a radiator attached to it can sometimes keep the heat in check, YMMV... ]

IMHO, the reason propellers are so difficult to work with in KSP is due to the designers' attempt to mimic the main physical forces to some level of integrity, which not only is very difficult given the resources available to do so, but is frustrating because it tends to amplify one area of force over others (a similar example is vessels that ignore surface friction and slide all over planet surfaces). So first, recognize that while the implementation is trying to be 'honest' about the forces involved, it accounts for some forces and not so much others - in reality, an incomplete list of physical forces on/caused by a real propeller include torque, pitch, power and thrust, slipstream effect, p-factor, interference drag, blade-tip speed, ascending/descending blade effects and so on. Second, again attempting to enforce the "pure" physics of the simulation requires the user's attention to each and every aspect they DO program into the simulation - nothing can be taken for granted. So that's the why. The how, unfortunately, requires one to delve into many of these forces and the interactions between those forces; @king of nowhere begins to list these but also acknowledges that there are a lot of if's, and's and but's because of the way propellers are implemented in KSP and @Echo__3 has some good videos but due to the breadth of the topic presents a LOT of good information that may or may not be 'absorbed' by the casual viewer. Like any post addressing a 'simple' topic that is actually complex, I'll try to delineate the likely missteps most folks make with propellers based on what I read as well as my own 'A-ha!' moments... Propellers need to be thought of as rotating wings Default placement of propellers does not make them very functional; the default orientation places them at a 90° angle on the motor hub but it should be 0° which can be easily done by pressing the W key prior to left-click placement. This so that when you next select the Deploy button and move the Deploy Angle slider to 0°, now the 0° Deploy Angle coincides with a 0.0 kN thrust in operation. Default motor configuration is also not very functional and the motor Action Groups should also be changed: Select the Actions tab/button to access the Action Groups and left-click on the motor. Select the <Brakes Action Group, then click on the motor's Brake > Group Action to remove it (it will 'jump' to the Selection column and be unassigned). While the motor is still selected/highlighted, select the <Main Throttle Action Group and then click on the motor's Torque Limit% > in the Selection column to move it to the Group Actions column. While still having Action Groups open, click on the <Translate F/B Action Group, then click on one of the propellers, then click on the Deploy Angle > in the Selection column to place it in the Group Actions. Translate Forward/Backward is normally used to control the RCS system, but because most planes do not have this, it correlates nicely with creating more thrust or less thrust - you can choose any axis group that seems logical to you. My suggestion simply assigns the H key to increasing propeller pitch and N to decreasing propeller pitch. You COULD and likely WILL place a KAL-1000 controller on your airplane to control this function but here I try to focus only on what makes the propellers 'do their thing' and not how to program the KAL-1000 to make life easier. Save this configuration and head out to the runway!! On the runway, Set your Brakes to keep from rolling away. If we had not unassigned the motor brake in Step 4, we would be scratching our heads during the next step as to why the propeller won't turn... Right-click on the propeller while it is stationary to open its PAW so you can watch the results of the rest of this mini-tutorial. Opening the motor's PAW is optional but allows you to monitor the Torque Limit with changes in throttle. Press SHIFT a few times to get the propeller turning (remember how we linked Torque Limit to Main Throttle back in Step 5?) and note that even with the motor turning the propeller, while the Deploy Angle of the propeller is 0° no thrust is produced although the effect of torque IS apparent if you accelerate the propeller too quickly with the main throttle as it will cause your airplane to rotate somewhat. Tap the H key once and note the change in Deploy Angle as well as the increase in thrust. You now see how the propeller needs to be both powered and angled properly to produce thrust - from here on its just a few nuances that relate back to treating a propeller as a wing. Intuitively one might think that the more you increase motor torque and deploy angle the more thrust you will produce but this is only partially correct. If you experiment around a little, you will find that when you are static (not moving with brakes set) increasing deploy angle up to around 9° keeps increasing thrust but then beyond that, the thrust begins to drop - this is because, like a wing, you can increase lift by increasing it's angle UP TO the point where it begins to stall and results in less lifting force. ~9° seems to be the magic number for KSP propellers. So NOW you think you've got it wired... set the angle to 9°, you release the brakes, accelerate for takeoff... and the thrust begins to decrease!! This decrease in thrust happens because while the primary speed of the propeller "wing" is the motor torque, as your airspeed increases, the actual angle that the propeller 'bites' into the air is being reduced due to the forward motion! So as you accelerate, to maintain that ~9° angle, you actually need to INCREASE the Deploy Angle - and this is reflected in the propeller's PAW under that label (Angle of Attack); you will see that the actual deploy angle to maintain an optimal angle of attack varies with your airspeed. Keep in mind that the opposite of this is true as well, i.e. after being at cruise speed/high deploy angle, you will lose propeller efficiency and thrust ability as you slow if you don't also reduce your deploy angle as the blade will be stalled at slower speeds with high deploy angle. [BTW, THIS is the reason you would incorporate a KAL-1000 into your airplane so that you can easily change pitch with throttle... but that's for another diatribe, er, I mean mini-tutorial!] Hope the descriptions help. Good luck!

Two immediate possibilities; the first would be reentry causes comm blackouts option is checked, the second may be that the satellite may be on the other side of the planet blocking a connection.

After re-reading your question, I think what you're referring to is whether to stage SRB's (lots of Fleas vs. double Kickback). First, because of the characteristics of SRB's, their primary use is First Stage optimized and staging ANY SRB for use other than lifting off of the surface is very inefficient although I'm sure someone can find the rare exception. This already precludes using a stack of Fleas in place of, say, a Kickback, even as you decouple them after burn out. And yes, ANY SRB needs to be dropped/staged ASAP after burnout - in terms of a clean separation, maybe even just an instant BEFORE burn out. Because SRB's generally complement your liquid-fueled vessel, your choice of which type and/or how many is dependent on essentially two things: How much payload you need to place in orbit; if your primary requirement is payload, use the largest SRB's that will cutout without shooting through your target orbital altitude. You will still need your On/Off property of your liquid-fuel engines to circularize your orbit. How fast you need to accelerate your vessel in the Kerbin atmosphere; many larger rockets have significant "suction" drag at the base which rapidly decreases after achieving Mach 1 (~330 m/s, changes with altitude) - thus the quicker you accelerate past Mach 1 reduces the drag while conserving the amount of liquid fuel consumed down low and slow in Kerbin's atmosphere.

After re-reading your explanation, @Corona688 I now understand what you meant by "getting my engines to as close to 1.0 local-g as I can manage", i.e. you cancel the gravity well with near exact offset thrust and then you've reduced most of the variables of the landing to make an RCS-guided "precision" landing. Kudos for the technique. I'm still a little skeptical about the applicability to various size vessels (the more fuel burn is a percentage of the lander weight can affect how much time you have to dedicate solely to RCS maneuvering) and the rapid transition from needing high thrust settings getting tweaked accurately to a 1.0g thrust setting as all these events occur, but again, kudos!

Okay, okay... a disclaimer: yes, I can occasionally put myself in a scenario that requires me to take measures to avoid my other-vessel target (but again, getting to this point would be nigh impossible if I didn't have KER "Show Target" enabled to determine when and how long to make my burns) so I willingly admit returning to the same general geographical area is doable with *some* effort, but despite the well-north side of 1,000 hrs of "practice", my SOP is unforgiving in its requirement for generous F5/F9 applications, and _uuuuusually_ a few "warm-up" attempts... Now, I'm willing to pay penance by becoming one of the monkeys in @linuxgurugamer's basement, but even with that training regimen, hand-flying to the exact same "landing pad" and "sticking the landing", with identical orientation would still be a hill too far... While I am impressed that you have been successful essentially combining the docking and landing maneuvers @Corona688 I'm assuming you do that with some level of modding and/or automation? I would be happy to know how to just accurately judge height and closure rate in the stock game much less deftly touching down at a rate that doesn't trigger a bounce off the target dock while fighting the local gravity well... And I do appreciate your relating the story of the navball - as someone who used to be tested in a real "full motion" simulator, prepping mentally with these types of simulations is actually a bigger help than some might imagine! Kudos to the trainee!

Going to Minmus efficiently is about 930 m/s dV. To get to the Kerbin SOI is only another 30 m/s dV - it seems more daunting than it really is, and the only thing you need to do is recognize that the *moment* you "pop out" of Kerbin's SOI, you are in Kerbol orbit. If you were to approximately reverse course by a few dV, you'd suddenly be BACK in Kerbin's SOI and, presumably on your way home.

Indeed... You don't happen to have a room full of monkeys on typewriters clicking away in a room of your home, do you? Having great respect for your contributions to this entertaining venue, I'll defer to your expertise! In virtual reality, anything is possible - its just that some things are more possible than others. As far as the OP is concerned, yes, building bases has been / surely will be possible, but given the known constraints, I'd anticipate having the ability to move any modules AFTER arrival, rather than plan that you'll be able to land them *accurately* into position...

Not trying to be a pessimist here - I'm all for the gung-ho, "let's kick some interplanetary butt here!" gameplay - but insinuating that using ~8 buttons (W,A,S & D, Q & E, along with Shift/Ctrl) loosely arranged into a logical flow pattern to enable precise three-dimensional maneuvers while utilizing a two-dimensional screen is, dare I say, "not likely to occur with any consistency". The unmodified/lightly-modded gameplay pits the intense reality of orbital mechanics and precision maneuvering against the virtual reality of controlling the universe with a common keyboard. I wouldn't take anyone's stories of heroics in replicating accuracy of landings as anything more than a "Well, that's nice". Kerbal's didn't get their reputation for "on-the-fly engineering" for nothing, you know...

My two cents (because most of the issues have already been hashed above): There is not just one issue causing your problem - its a little bit of many issues which contribute to your instability problem;you have the unfortunate accumulation of destabilizing problems... death by 1,000 paper cuts, as it were. It's confusing to the experienced player because, each taken by itself, we know how to compensate for each issue, but the "perfect storm" of so many contributory factors can seem perplexing. The good news is that if you only eliminate one or two of them adequately, you probably don't need to deal with them all.

According to Wikipedia, the "Starship Super-Heavy" anticipates using ~28 Raptor engines, each of which produce ~2,200 kN of thrust in order to place a 100,000 kg payload into orbit from a lift-off weight of ~5,000,000 kg, so assuming these are the milestones defining what you are attempting to reproduce, I would approach the problem like this: While KSP may not be completely realistic, one of the ideas it replicates with reasonable integrity is the idea of compromise depending on what's important to the designer. The reason you see so many answers is because there really are a large number of ways to do this, but each has its strengths and weaknesses, implementation-wise. If part count (computer performance) is the primary issue, the Mainsail will give you the most thrust per single unit for lift-off, although the less "packageable" Mammoth (which is a single part by count but is essentially a bargain package of 4 Vector engines with cost and weight savings) would be your likely candidates. Because the Mammoth form-factor has many TWR advantages, the creators made it, like the Twin-Boar, difficult to make clusters out of, but of course, anything is possible in KSP if you know the right tricks.... If cost is the primary issue, a cluster (more like "swarm") of cheaper engines like the Reliant are commonly ignored but possible; roughly speaking, 7 Reliants = 1 Mainsail in lift-off thrust but 7,700 Kerbucks =/= 13,000 Kerbucks (but part of the trade-off is 8.75 tons for the cluster vs. 6 tons for the single Mainsail, and so on...) If efficiency is the primary issue, it'll be hard to beat the Mammoth but is compromised by the form factor; using the Vector individually helps solve the form factor issue but is hugely expensive. So you see, there are any number of ways depending on what is most important to you.

"Planes" are typically powered by air-breathing engines, because they generally travel in the atmosphere where oxygen, necessary to support fuel combustion that results in propulsion, is readily available. "Rockets", which travel outside the atmosphere where there is no external oxygen available, must provide their own oxygen in the form of an "oxidizer". Thus a "RocketPlane" is, in the most strict sense, a vehicle which flies in the atmosphere but is powered by rocket engines (like an X-15). In the less strict sense, but commonly accepted, a rocketplane use its wings to create lift in an atmosphere as well as using air-breathing engines to propel itself, but is also equipped with rocket engines so that it can continue to propel itself after it leaves the atmosphere.

If it helps to understand the situation, here's a post from awhile back about the issue....

You may be referring to the PC's version of using the "Alt-" key before selecting a stack of components, which selects the stack and allows new placement without removing the original parts. All that said, I have no idea which button on the PS4 maps to the Alt- key on PC, but that might be what you're looking for...

Without any other consideration (aka time, hair available to pull out) I would think the "most efficient method" would be repetitive shorter prograde burns at the game calculated "in game, instantaneous" maneuver node - at least until you escape the local body's SOI, which would make every dV expended contribute to the most efficient trajectory (while keeping in mind that you need to be exiting the local body's SOI when the transfer window arrives). But like all things astrophysical, the caveat is that the point in the orbit where you perform these intermittent burns would change slightly each orbit according to the distance the body travels around Kerbol. I think a reasonable compromise would be to, say, burn for 1/4 of an orbit, (1/2 before the node, 1/2 after) which would minimize cosine/wrong way losses to an acceptable point, and repeat in the next orbit with only an adjustment for the ejection angle change due to movement of the body you are orbiting. [ Looking at some of the images, it appears that the burn might take, say, 3 orbits? maybe 4? ]

I've had very good success docking ports and klaws on the surface. Given the issues others are experiencing, this could be just lucky happenstance but after looking at the various configurations, I think the answer is (short version) docking ports should be mounted so that only horizontal forces are involved, NOT vertical forces. This solution, however, does require some level of pre-alignment during construction. I've included a shot of one of my implementations... The not-so-short version reasons like this: When docked, what was two vessels are now considered a single vessel and the forces upon the docking port or klaw appears to be mostly shear and/or torsional (KSP parts don't crush or stretch apparently). However, *AT THE MOMENT* you undock, the interaction of forces between two vessels is *immediately* calculated and, given that wheels and landing gear have springs/dampers that store energy/force, Newton rather accurately predicted that your lighter 'm' will succumb to your accumulated 'F' with a significant 'a'. The solution is to prevent those forces from accumulating in the vertical plane (the plane through which gravity acts - and increases with load/mass) which is easily achieved with horizontally mounting docking ports. This does, however, require some alignment during assembly which you don't want to do, but in reality is not too difficult but does require some planning. Even with construction alignment, the ports will likely not mate perfectly as illustrated in my image - but by adjusting the spring strength of the landing gear and/or deploying/retracting drills a slight movement typically allows the docks to merge - heck, sometimes just the little bounce you get from switching from one vessel to another is enough to trigger the docking completion...

So the reason the heat shields help reentry stability is due to two properties; 1) They are relatively heavy in comparison to the pods they are attached to, which shifts the CoM close(r) to the heat shield, and 2) They are slightly convex which causes them to be aerodynamically self-correcting, within reasonable limits, including the CoM location. When you look at the image, the normal flow and CoM of a command pod with convex heat shield is displayed. In B the pod starts to tip and the more flattened in-to-the-airflow side creates greater drag while the side more tilted produces less drag creating a rotating moment at the CoM that corrects the tipping. However, if you make the vehicle long as in C and thus move the CoM far enough from the heat shield, because the CoM will easily exceed the point of the 'corrective' force of the heat shield, they will actually cause the vehicle to rotate around the CoM more and create instability. With situation C, the only hope is to keep the CoM within the angle limits that allow the corrective action of the heat shield to maintain stability - and as the vehicle gets taller, the angle gets smaller.

FWIW, a Service Bay can have a lot of your external components included within and allow a more traditional configuration; while 'unique' configurations are indeed a hallmark of KSP designs, the functionality of a traditional design will allow for a higher rate of success. When push comes to shove, while you may think you are being spartan and minimalist in your design, you may instead realize you are making things more difficult to achieve... Fair skies and following winds, sir - Good luck!

I'm not sure what your other limitations might be (cost? part availability?) but it really isn't so hard to include the Science Jr with your command pod for reentry - maybe put a Service Bay between the Science Jr and the heat shield if the low heat rating of the Science Jr is a problem, or something similarly more heat resistant. What's the issue of using another parachute or two?

I think the biggest problem you'll have with this plan is the game dynamic which only allows you to focus on one object that is operating below 70,000m at a time - if you're under 70km, you will be 'stuck' monitoring the progress of the focus vehicle and as soon as the other component is beyond the ~2.5 km distance from the focus vehicle - if it is within the atmosphere - it will vanish into the Kerbal Ether, n'er to been seen again... The only way this kind of situation works out is when you can 'usher' each part of the vehicle from above 70,000m to the surface, or with a mod, AFIK.