pincushionman

I was going to add a Kopernicus-file reader into KOMET once I get the patched-conics thing working (so not until next year sometime), but an editor/writer wouldn't be too much of a stretch once I get that far. I've already got it plotting an arbitrary number of bodies as long as you have the spreadsheet columns filled out correctly. featurecreepfeaturecreepfeaturecreep

It looks like you have…lots of booster for that payload. Are you firing all the strap-on boosters and those three big cores at liftoff? If you are, you may well be hitting max-Q somewhere below 10 km or so, which is bad news. If your pad TWR is more than about 1.5, you may need to dial it back some. Also, you said you put decouplers on for drag? Are those the devices on top of the side cores (I can’t see very well in the picture)? If they are, they may still be ahead of the center of mass, given how bottom-heavy that vessel is. The best drag-producing devices are always fins, and always waaaay at the back. One other thing I notice is your top stage looks like four short tanks in a row. More joints = more flexibility, which will tend to exacerbate any bending going on in that portion of the stack, especially since your control point is at the tip of that spring, with the lower stages being much stiffer. You may want to replace that with a single long tank, or autostrut through it.

Well, the most straightforward way to leave a structure on Mun is to integrate the structure into a landing stage, with an ascent stage perched on top. When you leave, all that stuff stays behind. But it won’t be ring-shaped. It could be ring-shaped with a plug in the middle. If the ring is a firm design requirement, things are about to get complicated. First, you need to understand that the “tree” structure of vessels makes rings notoriously difficult to build. You can build parts into a circle, but the ends that come together won’t be connected even if they look like they are. You have two options to close the shape: struts and docking ports. Struts will simply connect, but docking ports at each end will still be unattached until physics loads. Search on this forum for more details on building rings.

@ElWanderer is right, the tricky step is the mean anomaly -> eccentric anomaly conversion; everything else is plug-and-chug. But if you have the current Excel, I’ve got your back. Just follow these three easy steps: 1. Use the spreadsheet 2. … 3. Profit! …Actually, that’s a lie. There’s more than three steps. But you’re a smart dude (I mean, you play KSP, right?) Just read the instructions first so you know how to set the time. You’ll find the anomaly values and radial positions for all the bodies on the “Body Info” tab on row 24.

Is there structural deformation? Yes there is. The physics engine KSP is using simulates structures as a number of rigid bodies connected together, but the joints between them are allowed to be flexible. The vehicle you’re showing here is very long, but the parts making it up are individually quite short. Therefore, there are a lot of segments, and by extension, many joints, which makes the whole structure quite flexible. This has an effect on early-tech-tree gameplay - all you have at your disposal are short parts, so you’re forced into building small rockets until you can buy the ability to build something not so wobbly and noodle-y. EDIT: Welcome to the forums!

Somethimes the game forgets to make the whole spent stage go all ‘spodey when it should. I’ve found mostly-intact Mun ascent stages on the ground after I’ve ditched them and left their physics bubble before they hit.

Update 2019/09/25: Version 0.4 is available! Download it here! Changelog: WELCOME TO KOMET! Or, Yet Another Third-Party Orbit Simulation! They seem to be pretty popular. KOMET is a simulation of the Kerbal solar system implemented in Microsoft Excel 2016. I wrote it to help me plan my missions better. Specifically, I wanted three things: Orthographic views. Since KSP is a game, it makes sense that there is a perspective view in map mode. But I find perspective makes it more difficult to see what's going on in the big picture. KOMET displays orbits in three orthographic views instead, like an engineering drawing. Views of SOI. I still get surprised when I make an encounter with...well, pretty near anything. KOMET draws the spheres of influence around all bodies so you have some idea how precise you need to be with your orbits. Time control. The maneuver node system is very useful, but it has some limitations for several orbit segments ahead; and of course you can't see your past track at all. KOMET allows you to view the state of the system at any arbitrary time. Here's a comparison of KOMET and the in-game map: In addition to showing you the state of the solar system, KOMET allows you to enter a user-defined orbit and follow the position of that object through time. As of version 0.4, both escapes to a higher SOI and captures by another body within the same SOI are simulated. Please see the Readme tab for more details on current limitations. KOMET is implemented in Microsoft Excel 2016, and is not guaranteed to work in earlier versions of Excel. This spreadsheet also relies heavily on macros and user-defined functions. You will need to enable these in order to interact with the tool. For those of you who are wary of macros in files you get from a stranger (and good on you for that!), Excel will disable macros unless you press the "Enable Macros" button when you open it, or place it in a Trusted Location. I encourage you to open the macro editor (Alt+F11) to inspect the code. The code is found in three places: Forms: Right-click on any form and select "View Code" to see what makes that form tick. Modules: Double-click any module. This is where more general-purpose code goes. ThisWorkbook: Double-click this object. A short code snippet is here which controls what happens when you select different tabs. Download KOMET here. KOMET is licensed under the BSD 3-Clause License. Hope you enjoy, and don't forget to leave feedback! - Dan B. (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.