AHHans

Hmmm... Nagging @SQUAD to implement one in stock? Sorry, except KAC I don't use (m)any mods, so I can't actually help you here. (But also couldn't resist a snarky comment.)

Sorry, setting locks is bugged, quite often the lock does not get set because "part is moving" (even if you can't see any movement, there are no external forces acting on the part, and the brakes are set). So you can't have a single toggle switch that works reliably. What I do to reliably set the locks, is that I assign the "set lock" to an action and hit that button until all locks are set. (I think you already meant that, but I also put it in my words:) The brakes are also a problem: you can also toggle them (which actually works reliably), but you cannot start with the brakes set or with the rotor power on. So if you toggle both once then the brakes get set and the motor power turned on., and here the brakes win. What you can do there is to keep the brakes of the rotor also in the "Brakes" action group and tap the <B> key when the motor is on. Tapping the <B> key will always set all brakes and then release all brakes, so afterwards the brakes are not set. If you do want the locks, then you can set up a KAL sequence like the one below. That will when going from left to right: try to set the lock a number of times (if it was already set or gets set before the last attempt then nothing special happens) release the lock (this always works) toggle the brakes (see below) turn up the torque limit So once it played from left to right then the rotor should be "on". If that set the brakes then you might need to tap <B> to get it moving... Playing from right to left it will: turn down the torque limit toggle the brakes (I assume it was moving before that, so that should set the brakes) release the lock (well, this shouldn't do anything) try to set the lock a number of times (trying more than once to set the lock increases the chance that it actually gets set, but there is no guarantee!) Depending on the inertia of the stuff attached to the rotor you may need to give it more (or less) time to come to a stop before any attempt to set the locks will succeed. To stop the rotor you can also set the RPM to 0 and keep the motor power on instead of using the brakes. But that will uses the motor torque and not the stronger brake torque to stop the rotor, so I think it won't work as well.

There should be one (ore more?) of the following options in the PAW of the docking ports (when they are connected to something): Undock Make Primary Docking Node Decouple Node If there is only the "Make Primary Docking Node" option available, then clicking on that should make the "Undock" option available. If neither of them is around on the docking ports then that is a bug. (Well, except if the vessels are connected at another point and it only looks as if they are connected at that docking port but in reality they aren't.)

What do you mean with "wobbling"? For general relativity that only happens at a singularity: inside a black hole or at the big bang. I.e. we don't know what happens inside a black hole or before the big bang. An expanding universe is no problem for GR, even an universe in which the expansion accelerates. It get pretty boring after a while (when everything moves away from you faster than light), but the equations work fine. Inspiring people to make great computer games!

I'm not sure that my explanation is better. Right now your explanation seems to be more understandable than mine. (But then, I was never good in theoretical physics! I'm much better in getting useful results out of an actual piece of hardware. ) Well, you can model an expanding universe in GR without the cosmological constant. What it is (or does) is a way of explaining why the expansion of the universe seems to accelerate, same as "vacuum energy" or "dark energy". To a simple experimental physicist like me all three are essentially the same and just a fancy way of saying "We have no clue what is going on. So we give it a fancy name in order to attract more funding." No. In this context "geometry" does not mean "I have some actual point here and there" but a mathematical model of what space looks like. In Newtonian physics space is "flat" and can be described with Euclidean geometry. In general relativity space is not flat and you need something like Riemannian geometry to describe it. One popular example / model is to look at a triangle in 2-dimensional space. In a flat, Euclidean geometry the sum of the inner angles is always 180 degrees. In a curved (e.g. Riemannian) geometry geometry the sum of the inner angles of a triangle is more than 180 degrees if the space inside the triangle has a positive curvature, or less than 180 degrees if the space inside the triangle has a negative curvature. The surface of an inflated balloon for example has a positive curvature, so if you draw a triangle on it(*) and measure the inner angles(**) then you'll see that the sum is larger than 180. If you then inflate the balloon more (i.e. expand your 2d space) then the fundamentals of the space don't change. Also the equations that describe the space don't really change, only some parameters in the equations change. E.g. what is the equation that describes a circle with radius 5? And what is the equation that describes a circle with radius 10? Are those equations significantly different? (*) I.e. mark three points and connect each pair with the shortest path on the surface of the balloon, which will not look like a straight line when you look at it from the side. (**) A small enough section of curved space will always be close enough to being flat. So you can use your usual "Euclidean" devices to measure the angles. Equations don't get "warped". Except when you are commenting on the legibility of the handwriting of the average physicist.

It's a red "arrow" like they are used to show the aero forces when that is active. But I suggest that you activate it while being close to a Surface Feature that you already found and look for yourself.

Oh. That's a teeny tiny bit more complicated than reaction wheels or control moment gyros. The relevant equations are also not special relativity (which doesn't contain gravity!) but general relativity. "Space expanding" means that the distance between objects where said distance is not determined by any of the four forces (the strong and weak nuclear forces, electromagnetism, and gravity) is increasing. E.g. the distances between the molecules and atoms in a piece of solid matter is determined by the electromagnetic force. I don't know how the expansion of the universe would affect the orbits of our / a planetary system if it were in a real(TM) vacuum. But I'm pretty sure that the dense soup of interplanetary space (5 particles per cubic centimeter on average? No wonder that you'll fall into the star sooner or later.) has a stronger effect.

LOL! Edit: If you can survive for 5 seconds, then you are not trying hard enough. P.S. How about separate leaderboards for survivable and not-survivable entries.

Well, it would have been pretty hard for @Capt. Hunt to find Mun Stones and Small Craters if he hadn't.

How about Scott Manley on youtube: Reaction Wheels - Things Kerbal Space Program Doesn't Teach Edit: I can also recommend the other clips in his "Things Kerbal Space Program Doesn't Teach" series.

I don't think that will work. I have the feeling that the surface features are only rendered once you are fairly close and didn't zoom out too much. So you'd have to get so close that the ground just speeds across your field-of-view. My guess is that your problem is the first one on @5thHorseman's list: there just aren't any in the biome you are looking. (Well guess!)

Well whom are you planning to force to learn what?

For me "makes the game more realistic" is good enough.

Some people - me included - like the looks. And it makes the game more realistic. (Check out the shape of the SR-71 wings for comparison.)

Well... I did try... But only managed 1800-something m/s. My last try had an interesting failure mode: once the leading fairing exploded due to overheating, everything else went in an instant due to excessive g-forces. If you are going fast enough even air becomes as soft as a brick wall! P.S. How about moving this to the challenges subforum?

I guess I'm not the only one who doesn't see or understand your question.

Well, for my career game I decided that using the cheat menu for checking the specialization of a Kerbal awaiting rescue is not really cheating. Surely the agency that sent them there know how they were trained, so asking them for a résumé is reasonable.

Hmmm... <copy> <paste> <select "titles only"> <hit search> Seems to be "officially" supported until KSP 1.5. So I guess it will work with KSP 1.7. But you (or your friend) should test it. My guess is that the new features from Breaking Ground may give you problems. Or your friend stays with KSP 1.5.

In the KAL track editor: did you move the play-position slider, or "only" the point on one of the tracks? In the VAB it will only move the servos together if you move the play-position slider or "play" the sequence. But if you essentially only need two positions of the servos, then you can also set the "angle limit" to the two target values and then put "set maximum/minimum angle" onto two action groups.

No harm done. One problem is that I don't react well to people of whom I think that they are blaming the game for their faults. They may not have meant it that way, but what someone writes and what the readers understand is not necessarily the same. I like KSP because it simulates the physics remarkably well. There are many simplifications in KSP but in many scenarios the simulation is close enough to help you learn something about the real physics. It is one thing reading about the 737 MAX and its big engines that cause trouble, but it is another thing building a plane in KSP that flies fine in one situation and tries to flip around in another. And then figuring out why that happens... (One reason is that the center-of-drag shifts when the air is coming at the craft from different directions.) Where KSP does have a big problem is that it doesn't actively teach the physics. It only lets you experiment and shows you what works and what doesn't work. The devs of KSP2 promised that their take will be better at teaching how to get things done, but I'm still skeptical because it is complicated. There is no easy way around that. (Well, except "dumbing down" the physics, which would make me very unhappy.) (And, yes, I react differently to "The game is a jerk because the physics isn't the way I want it to be." and "The game is a jerk because it doesn't help me to understand the physics." ) I'm not sure how you meant that. But keep in mind that the grid-fins that SpaceX uses are folded in during ascent and only unfold for reentry. Engines generate heat when they are running. If they are connected to a big fuel tank, then this tank can soak up the excess heat and radiate it away over time. If they cannot do that (or cannot do that fast enough like the nuclear engines) then they heat up, which will increase the rate at which they radiate away heat. IRL some rocket nozzles are designed to become red hot when the engine is running, so that they can radiate away enough heat. Same as my previous answer: in theory yes, but I wouldn't recommend it. A rocket cannot be aerodynamically stable going forward and backward without moving around the center-of-mass or the center-of-drag. You can do the latter by adding high-drag devices that can be triggered like airbrakes of parachutes to the top of the rocket. Moving the center-of-mass can be done by selectively using up fuel or pumping it around. But getting this right on a rocket is quite hard because the center-of-lift that the editor shows is only close to the center-of-drag in typical airplane situations. (Where there are lots of lifting surfaces, in dense air, and at low-ish speeds.) My suggestion for you would be to leave out most or all of the fins. That will make your craft harder to control during ascent because it will not automatically point itself into the airstream, but it will also not automatically fight you when trying to go backwards during landing. It also helps a lot to not point too much away from prograde or retrograde (during landing) while in atmosphere. That way the turning moment of the aero-forces is small and you need less torque from engine gimbalig or reaction wheels to keep it pointed where you want to.

Oh, yes. The "toggle" action of the airbrakes when triggered by a KAL-1000 seems to only retract the airbrakes, but does not extend them. Bug report on the bugtracker coming up! [Edit:] And here it is: https://bugs.kerbalspaceprogram.com/issues/23819 The "extend" and "retract" actions seem to work fine though. P.S. Thanks for the heads up. I haven't noticed any mention of this before.

If you don't use SAS, or only use the stability-assist SAS mode then it is still that the navball is the wrong side around and that the control is probably inverted to what most people expect. (The navball probably wasn't the OP's problem, because that should have been pretty obvious.) I guess you can see the difference when using other SAS modes yourself. (If not, then please ask!) I believe your confusion is the phrasing "reversed it's reaction wheel". You cannot change the reaction wheel orientation as such, they don't really have an orientation in-game. What you can do - and what I think @Lechu meant - is changing the orientation of the control point that the cupola module provides. That you can set to "reversed" so that a cupola that is mounted upside down will provide control in the direction that the rocket is actually pointed.

As @Laie said: by thinking of their craft as one single tank with both Lf and Ox, and then balancing the ratio of those to match the ascend profile. I personally have a good number of Mk-1 (1.25m circular) tanks in my SSTO spaceplanes, for which both LfOx and Lf only tanks exist. That way I can swap out the tanks as needed. (If I have Lf left over but not enough Ox, then swap a set of Lf only for LfOx, and so on, and so on...) Another comment that comes to my mind is that making a SSTO spaceplane is easier using RAPIER engines, than with a panther / swivel combination. The latter is possible, but I only managed after I made quite a few other designs. (I struggled for quite some time to design a SSTO spaceplane that can get into orbit. At some time I was so frustrated that I stopped trying for a few weeks...)

Do you need to let off some steam, or are you actually asking for help? In case it is the latter: things (planes, rockets, whatever) tend to "fall" (here "flying" just means "falling horizontally") through an atmosphere with their center of mass in front of their center of drag (or center of lift as long as that dominates the drag). So if you have a rocket that has lots of fins at the bottom then it wants to "fall" nose first! (Or more scientifically phrased: the aerodynamic forces tend to turn it nose-first.) This is fine for lift-off when you want it to go nose-first, but not so good if you want to land bottom first. In theory you can counter-act the aerodynamic forces with enough control authority - e.g. from engine gimbaling, reaction-wheel torque, or even aerodynamic control surfaces (as long as they can rotate far enough to actually provide control) - but this is a bit like trying to drive a nail into a wall head-first. My suggestion would be to remove the all (or at least most) of the fins at the bottom of the rocket, add some high-drag devices at the top (like airbrakes as suggested by @Space boy) and maybe change to engines with more gimbaling range. I'd also suggest that you have a look at a tutorial about aircraft design, e.g.: https://forum.kerbalspaceprogram.com/index.php?/topic/47818-basic-aircraft-design-explained-simply-with-pictures/ Yes, I know that you don't want to design an airplane, but the physical realities are the same. If you look at the Falcon 9 boosters, then you see that they don't have any fins at the bottom of the rocket, but do have grid fins (which provide high drag when unfolded) at the top of the booster. In addition the center-of-mass of a mostly empty real rocket is very far at the bottom of the rocket because the engines are quite heavy and empty fuel tanks are lightweight (much more so than in KSP, where many people complain about fuel tanks made of armor plate).

This makes me think that this: is indeed your problem. To get into some more detail: Duna does have an atmosphere, but this atmosphere does not contain oxygen so it cannot fuel a regular air-breathing engine. In game those are the turboshaft engines and all jet-engines. What does work (after a fashion) on Duna are electric rotors, so you can power a propeller with those. (And use solar panels to provide the electricity for example.) An additional problem is that Duna's atmosphere is so thin that propellers don't generate much thrust. Lifting a craft with the stock helicopter blades can be done, but is not an easy task.