pincushionman

Banking turns have been a thing since forever in KSP, so I din’t see what is the suggestion? Is this a gameplay question or tech support request instead?

Try setting the “turn wheels” controls to something different from the yaw (they are the same by default). Wheel steering is usually fine for taxiing (when rudder is next to useless), but once you’re at speed it’s dangerous for even the best analog steering setups. You should be relying on rudder at that point. This, of course, is easier said than done, especially on keyboard setups, so a feature where wheel authority is cut off or ramps down at a certain speed (selectable in the tweakables?) would be welcome. In the meantime, though, you can also try using Docking Mode to use the steering keys for wheels only, while removing the wheel steering from Staging Mode entirely. If you want to get really fancy, you could use the two Docking Mode sub-modes as a sort of “plane mode” where you switch between rudder and wheels with the spacebar. But that’s kind of playing with fire if there’s no indication of which sub-mode you’re actually in.

Now, @The_Cat_In_Space, we know you wanted a short, simple answer, but the reality, like everything else in rocket science, there's actually a lot going on. The previous posters have already given good descriptions of what it means in terms of describing what a rocket can do, but I'm going to go at it from the other direction - describing what your rocket is attempting to do. Orbits are paths of constant total energy within a gravity field. We know that energy is a function of mass and position (potential energy) or mass and velocity (kinetic energy). However, because the mass of an object doesn't change throughout an orbit, and because of how gravity works, the mass terms actually "fall out" of the orbital math and we're left with position and velocity being the only important variables. When we describe orbits in KSP, we usually use orbial elements to do that job, since they're easier to digest. But an orbit is equally a set of positions and the velocity vectors at each point. And we don't need the whole set - it is sufficient to use only a single location and the associated velocity vector to uniquely describe an orbit. KSP, in fact, does have to use this formulation - in order to do patched conics, you find your xyz position and xyz velocity vectors at the SOI boundary, transform them into the new reference frame, and then derive the new orbital elements from that information. And if you're doing N-body physics, you don't have true orbits, you only have position and velocity. All right, this is getting long, but stay with me here. So when we compare two different orbits, we need to compare both the position vector and the velocity vector for each. However, when we're trying to describe a maneuver, we're not describing any two old orbits - we're describing intersecting ones. We're moving from one orbit to another where the position is the same in each orbit. Since the positions are the same, the only difference between the orbits is their respective velocity vectors. And the math you need to do those comparisons isn't calculus, you only need arithmetic. In terms of describing these maneuvers, delta-V (change in velocity) is exactly that - the vector difference between the two velocity vectors. Note that I didn't say speed, but I emphasized vector and velocity, because that's important. Most maneuvers are of the increase/decrease speed variety, but if you've ever done a pure plane change, you'll notice your starting and ending speeds are the same. The velocity change is due entirely to direction change. We normally assume that pointing your vessel in the correct direction is a free action. And to make things more confusing, this has absolutely nothing to do with the fact that you'll be moving at different speeds at different times during an orbit (fast at periapsis, slow at apoapsis). That's a whole different thing. So the delta-V of a manuever is the cost of doing that maneuver - how much do I need to be able to change my speed and direction to get to that new path. The delta-V of your rocket (described by the other posters) is a measure of how-much-maneuver-can-my-rocket-do-before-I'm-out-of-gas.

If you already have the monoprop onboard AND you have enough time to make your burns AND you make sure you retain enough for your other maneuvering needs, there is no downside to it. Un-burned…un-shot…un-disassociated? Un-used monopropellant is dead weight. A mixed LFO/MP burn is less efficient than an LFO-only burn of the same tonnage of fuel. However, you’ll have two things going in your favor. First, you will shed more mass during the burn, so all subsequent burns will be more efficient. Second, you’ll have more thrust, so the maneuver will take less time, meaning you’re closer to the theoretical instant maneuver and you’ll lose less to cosine loses. Of course, the efficiency thing is most true if the monoprop is used first, while the thrust part is only true if you burn both fuels sumultaneously. How much will it help? That we can’t tell unless you give us more info on your craft. You’re transporting a load of fuel, which is a heavy payload. Unless you way over-budgeted your MP, I’m guessing your MP is actually a small fraction of your mass, so the actual efficiency gain will be minimal. Likewise, unless your LFO engines are small (less than, say, 200 kN of thrust), the extra thrust isn’t going to be all that helpful, either. But you’ve already got it there, so you might as well use it. If, on the other hand, you haven’t launched yet, you’d be better off putting in a smaller MP tank to begin with.

Not exaclty the question, but Kurde…Kiuzedg…Kurzgemahhozit…these guys touched on the “would it change the Earth’s orbit” question in this video. Didn’t go into any of the details the preceding posters touched on, though.

Regardless of whether you use merge, subassembly, or build in situ, you may need to re-think how your wings are built. Attaching wing sections to the fuselage ahead of/behind existing wing parts will continue to make “strips” of wing parts like you do now. If, however, you choose one wing part to be the “wing root”, so to speak, you can build a whole wing like a tree branch, adding more wing parts to existing ones (which may mean parts are put on “sideways”), able to pick it up and move it as a unit as long as you remember which root part to grab. This will, however, change the distribution of forces within the wing. Instead of a number of wing strips each cantilevered off the fuselage, you’ll now have the entire wing force being beamed through the network of wing parts back to the root, which may introduce deflections and moments that are significantly different than what you’re used to. In the past, this has required (for large wings) extensive use of struts to re-distribute the forces back to the fuselage components along the entire chord. Someone with better recent plane-building experience will need to weigh in on how autostrut and rigid connection change things (that is, I could be full of … from being out of the plane-building game).

Are you talking about the interior views from the Kerbals’ perspectives, or are you talking about seeing into the pods from the outside?

Before dismissing the thought of professionally-installed or -monitored systems, check with your insurance. Not only is it their business to be able to make reccomendations on such things, it may result in a reduction in premiums, especially if this would fall under an existing business/farm policy.

There is a map on Reddit of the minibiomes, but it only shows the locations on the fully-upgraded KSC…and certain biomes are available at certain levels. Does anyone know of a better set of maps that has all upgrade levels?

There used to be a popup about that. But it’s been so long since I’ve seen it I don’t remember what it was or exactly what kind of data it was asking about.

Are you in the VAB? Because something is not right with the aero center - and that could be hiding additional problems.

I’m looking at Shovel Knight and Hollow Knight, myself. I would consider Making History as well…but I’m waiting for the whole GPDR/analytics/Red Shell thing to be addressed first.

The reason most people don’t do it is threefold (and the first two…folds have been mentioned already): 1) The precision needed to use it effectively makes it difficult for most players. 2) The ammount of dV saved is marginal compared to said effort, with the exception of Jool-system gravity braking. Jool assists would be more useful (as we use Jupiter in real life), except there aren’t any more outer planets to go to using it. 3) Most importantly, it’s astonishingly easy to over-dV your ships in KSP, and outside of self-imposed low-dV challenges, there’s little incentive to do otherwise.

It’s not entirely clear, but while the exposed kraken is seen entering a Science Jr., the “hazardous material” may in fact be Goo.

It’s not possible to use that information outside of data-mining the game state. But if there were an option to have the celestial axes drawn on the focused body - or better yet, a grid - the data would immediately become relevant and useful.

Not sure what you’re trying to accomplish with the MIRV configuration, but if it’s “get multiple Kerbals to space and back simultaneously for level-up/contracts” you’d be better off keeping all three pods connected. Or better yet, use one command pod and a crew cabin. Only one craft, so no physics-range problems - note that if you do a more-horizontal flight as suggested, your draggier capsules will go out of range and be destroyed. I myself use such a craft in my save.

Slightly unsymmetric stiffness has been a longstanding bug in the game. The two wings deform differently under load (twist and bend), causing the difference in lift and a roll (usually to the left in my experience, but that’s not a certain thing). It’s also the source of the imfamous “why does my plane veer to the left on the runway?” behavior. Stiffer structure (struts, autostrut, KJR) helps, but you can’t get rid of it completely.

I thought this was “polar runway detonations” when I first read it, and to be totally honest I was a little disappointed. But I’ve got to agree with the others, naming them for the meridian they lie on makes the most sense.

There was in the past a mod that would allow you to break symmetry. It may be Editor Extensions.

It’s what should happen. As long as you’re going a reasonable time warp, if you have a long enough stretch of orbit below 23 km, the game should eventually notice and delete the craft. …I say “eventually” because of time-warp quirks. TW is essentially dropped frames, so at high time warp it’s entirely possible to end one frame prior to crossing the magic line, and the next [evaluated] frame finds the obcect on the other side, safely traveling up away frome the planet. With sufficiently high-energy or -eccentricity orbits, you can (or could; I haven’t checked whether that’s been fixed) even teleport ships through planets.

The specific details are that debris is unloaded, but continues to be tracked if it is “on rails” or is landed once it gets further than 2 km from you. If you turn on the debris filter like @bewing described, you can see any debris on the surface (*if* it survived), spent stages left in orbit, or anything on an impact course. This debris will eventually get cleaned up automatically depending on the max debris setting you’re using and how dilligent you are about manual recovery/deletion. Now, stuff on an impact trajectory is a different story. The debris, like any vessel, will be tracked on rails until it is below the surface of the body, whereupon it is assumed to have crashed and is deleted. Atmospheric bodies have an additional check - if the pressure is above 1% of kerbin sea level pressure, it assumes either burn-up or crash and deletes it. On Kerbin this corresponds to about 23 km altitude. The mod @Gargamel noted intercepts this check and does its own to decide whether to destroy or automatically recover.

This is probably the problem. Tweakscale modifies all the properties of a part based on some rules - tank capacity, mass, thrust, etc. Capacity is easy; it scales with the cube of the (linear) scale change. All the other properties are probably less straightforward, and the assumption made by the mod for motor torque could either break down for extreme scale changes or be flat-out wrong. I’d check that mod’s forum thread for help there - but I’d suggest doing some experiments first with a simple buggy and tracking what changes about the behavior as you change the wheel scale and nothing else. That would help identify whether it’s actually a problem with Tweakscale, and if it is, knowing what it is doing would be helpful in figuring out what is should be doing and how it should be changed.

You can set the other rotations with keys too, but I’ve had bad luck with it actually working right. Camera+space is much better.

You can should always copy your current install to a new folder as a backup, then you’ll have 1.3 to fall back on if 1.4 doesn’t work right! If it does work well for you, though, is there any reason not to? Well…there’s always the mod support issue. That could be a deal-breaker.

Will it even work in that kind of atmosphere? And would the battery last more than about 15 seconds?