Snark

Correct. ModuleManager doesn't actually add any functionality to the game. It's not what it's for. All it does is provide a way to do "patches" to config files-- it doesn't have the power to make those config files cause special effects in the game. Code is what provides functionality-- whether it's stock code that comes from Squad with the game, or mod code that adds new functionality. Config just tells the code where and how to apply that functionality. (You can think of the code as being a car, and the config as being the driver of the car. Driver doesn't go anywhere without a car.)

Because if you look at those .cfg files that come with the mod, you'll notice that they all use a PartModule called ModuleDefaultActionGroup, whose implementation lives in DefaultActionGroups.dll. In other words, the .cfg files won't work without the DLL. The DLL is where the mod's custom functionality is implemented. The .cfg files then connect that functionality to the specific parts involved. It's how part-affecting mods work, generally.

Nothing wrong with discussing this project here in this thread... just a gentle reminder, though, that the thread is from nearly four years ago, so do bear that in mind.

Well, sure, but if you're gonna go there, let's talk about how you could never get Dres in that stable position relative to Kerbin, or how it would be essentially impossible for the Mun to be in an orbit like that (and never mind the fact that it's probably past the Roche limit, and what its tides would likely do to Kerbin even if it's not). Or the impossibility of getting a planet spinning as fast as I've got Keelon doing, without disrupting its structural integrity. And so on, and so forth. And never mind the utterly implausible densities of KSP planets in the first place. This mod isn't even slightly about "realism", and never has been. It's about deliberately arranging things in a novel way to present some interesting navigational challenges and add variety to the game.

Hello, and welcome to the forums! Moving to Add-on Discussions, since that's better suited to this question. There are, of course, tons of good mods out there. Which ones are most appealing to you will depend a lot on your play style, what about the game bugs you or seems "missing", etc. Got any guidance on areas of the game you feel could use some improving or altering?

I know, and I totally sympathize. I get that it's hard to understand this stuff, if you're not a programmer-- you'll recall that I pointed out that very concern at the start of all this. Executive summary is that "there are good reasons, and KSP 2 will have to solve many of the same problems that KSP 1 did, so it's not surprising that they'd have similar algorithms." Folks in the few posts above have already provided a lot of good explanation of why a lot of these things are the case. If you're having trouble following along, I'm sure folks would be happy to provide references for specific points that may be puzzling. Sure. Because the space colonies will likely only be on the order of hundreds of meters in size, not hundreds of kilometers, meaning that they oughtn't need new algorithms to model them. Because O(N2). Because it's a good optimization and is necessary unless you want to force people to have a supercomputer to run the game. Because it was a good idea when KSP 1 was written, and is still a good idea today. Computers have gotten more powerful... but N is also getting bigger, and the fundamental issue with O(N2) remains. Folks have already given a pretty good explanation of this in the posts above this one. If you're still having trouble grasping the concept, here's a handy reference. I recognize that that's a lot of technical detail to wade through, and I wouldn't blame you if you don't have the patience for it-- but if you'd prefer not to wade through it all, then about all you're left with is "people who have been doing this sort of a living for many years think it's a good idea", which I suspect would not be a very satisfying answer. Sure. And I didn't say that it would be "unbearable". Simply that it would require a lot of specialized UI that would only be necessary for skyhooks, and which they wouldn't have to implement if skyhooks weren't in the game. Implementing a complex feature is expensive. It's just how software development works. And resources are very finite, and there's never enough time to implement all the stuff one wants. All I'm saying is that this would be an expensive feature that wouldn't provide benefits to other, non-skyhook stuff, so it would be a poor use of their resources to implement unless it were a really important feature with extremely high demand. Which it doesn't appear to be. Because of the finite resource in software development, it's always really important to try to get a whole lot of "bang for the buck". And this feature would be a lot of bucks for not very much bang, that's all. I expect that it'll do better at optimizing a lot of places where KSP 1 has rough edges-- for example, improving the physics engine to run more efficiently, so they can support higher part counts. But the fundamental computational challenges remain the same, because 1. math, and 2. physics. Math is math, and physics is physics, and these things don't change with new software versions. That's why some of the basic simplifying assumptions-- such as patched conics for orbital mechanics, or the physics bubble-- will likely still be with us. Unless you have some suggestions about how to turn craft physics into an O(N) problem?

So, the good news is that going to Duna doesn't require much more dV than going to the Mun, so it's not too difficult to build something with enough oomph. Short answer: Build a ship that's like a Mun lander, with just a bit more dV, slightly more powerful engine, and a parachute. Then launch it at the appropriate launch window with just a bit more dV than you'd need to go to the Mun. The overall process looks like this: Wait for a good launch window Launch to LKO (just as though you were going to the Mun) Do a single burn of around 1000-1100 m/s to head to Duna Do a small course-correction burn halfway there, to adjust for inclination and such Aerobrake and land. Details below: Waiting for a launch window This isn't an absolute requirement-- you can launch even when the window's not great-- but doing your launch fairly close to the ideal window will mean you need less dV, which makes building the rocket easier. For an optimum transfer from Kerbin to Duna, you'll want to launch from Kerbin when Duna is roughly 45 degrees ahead of Kerbin. Here's an interplanetary transfer tool that I find really helpful: https://ksp.olex.biz/ There are other tools like it, but that one's my personal favorite because it's so easy to use, and I like the graphical display. Just put in where you're going from (e.g. Kerbin) and where you're going to (e.g. Duna), and tell it what's the height of your parking orbit above Kerbin (e.g. 100 km or whatever). Then you push the button and it tells you how big your burn will be, and also gives you little diagrams showing what the relative positions of the planets should be (i.e. the launch window) and what direction you should make your ejection burn from Kerbin. Launch to LKO This is the same as if you were preparing to go to the Mun or wherever. I'll assume you've already got this down pretty solid. Ejection burn to Duna Using the info you got from the launch planner (see "waiting for a launch window", above), drop a maneuver node at the appropriate place in your orbit (in the spot the tool indicates), and give it an amount of burn equal to what the tool suggests. Then zoom out until you can see Kerbin and Duna in the solar-system view. Hopefully at this point you should be able to see the closest-approach markers for when you'd get near Duna. Your goal is to tweak the maneuver node until you get a Duna intercept. Play around a bit with , and also try moving the node veeeerrrry slightly forward and backward in its orbit until you can get an intercept to show up. Once you've got it showing an intercept, you can go ahead and do the burn. Mid-course correction Once you've ejected from Kerbin, you'll want to fine-tune your path so that you'll hit Duna's atmosphere so you can aerobrake on arrival. This step assumes that you already have a Duna intercept from the previous step. Drop a maneuver node roughly halfway along the path to Duna. Doesn't really matter exactly where it is. Don't give it any dV yet. Still in map view, click on Duna and choose "Focus Here". You're now looking at Duna, and you should be able to see a trajectory line showing what your path past Duna is going to be. Probably this will be out somewhere near the edge of the SoI, unless you got lucky in the previous step. While still focused on Duna, rotate the camera around until you can see your maneuver node. Very gently, nudge that maneuver node to adjust the path past Duna. Give it a little bit of as needed to make the trajectory go past Duna the way you want it to. You want to get your Pe down to an altitude of 12 km or so. Note, this shouldn't require very much dV at all, just a little bit. It'll be a small burn. Once you've done that, do the burn when it's time. Aerobraking and landing It's really easy to aerobrake at Duna. Assuming you launched with a good launch window, you won't be arriving very fast from interplanetary space, and the combination of Duna's gravity and atmosphere makes reentry much gentler than at Kerbin. So if you launched with a good launch window, you probably don't even need a heat shield for this. (If your launch window wasn't great, you could be coming in a lot faster, in which case you might need a heat shield.) There are various ways to design a ship for landing on Duna. My own preferred approach is to just build a vacuum-lander type of ship (e.g. similar to what you'd use to land on the Mun), though with more dV and somewhat higher TWR to cope with Duna's higher gravity. Then give it at least one drogue chute, and one regular chute. Set the drogue chute's opening altitude to be as high as you possibly can, i.e. 5000 m above terrain instead of the default 2500. Set your regular chute's opening altitude to a bit higher too, say 1500 m or 2000 m instead of the default 1000 m. Having just a minimal amount of parachute means that the chute will slow you down a lot, but not enough to land safely-- you'll likely be descending at 30-40 m/s even after the regular chute opens. But that's fine, you can then just use a brief burst of rocket thrust just a second or two before landing, in order to slow to a safe landing speed. Note that that's not the only way to do it; it's just how I like to. You could, for example, spam a large number of parachutes, so that you can actually slow to a safe landing speed with parachutes alone even in Duna's thin atmosphere. It's totally doable. The reason I prefer not to do that myself is that it needs a lot of parachutes, and that mass adds up. The little bit of fuel I burn before landing (in the above-described technique) likely weighs a lot less then the mass of all the extra parachutes I'd have to bring if I didn't want to use the engine, so it's a savings. Another approach is to build something with wings that does an airplane-style landing, but that's pretty challenging on Duna (because the atmosphere is very thin), so my advice would be to leave that until later, when you're more of a Duna expert.

@Terwin covers some pretty good points already, a few posts above. Trying to put something like this into KSP would open many cans of very gnarly worms. Building is problematic. How do players build it? To be useful it'll have to be extremely massive. Ship it up in pieces? How many pieces? Seems like the number would be extremely large, and given that KSP is based on the idea of simple ships with a "tree" structure, trying to assemble the thing would be problematic. Spatially extended structures are problematic. KSP treats ships as being small, specifically as being zero size. This is a reasonable approximation when you're talking about things that are spacecraft-size rather than thousands of kilometeters long. It allows KSP to use numerous simplifying assumptions that keeps the code and computations manageable. For example, a craft is either in the atmosphere, or out of it-- there's no modeling of "the top part of the craft is in vacuum, the bottom's in atmosphere". If it's in the atmosphere, the whole craft experiences pressure and airspeed uniformly, based on the values at a single point-- it's not as though "the bottom of the craft sees a different airspeed and pressure than the top of the craft". Gravity is uniform for the whole craft-- the bottom of the craft doesn't experience stronger gravity because it's closer to the planet. There's tons of stuff like that. Something like a skyhook would blow all of those assumptions out of the water, simply by virtue of being large, regardless of how it's modeled. Trying to solve all that will be ugly. Very large, floppy components are problematic. KSP is based on ships with a reasonably small number of components, connected by reasonably stiff joints. Giant structures like space tethers have some very complicated dynamics going on. Either you'll have to model it as some sort of giant monolithic object that gets special treatment (in which case it's pretty disruptive to the normal flow of gameplay) or else as an assembly of many subcomponents (e.g. segments of cable), and simulating the dynamics of the whole thing would be nasty. Physics engine conniptions. KSP only does active physics modeling of craft that are inside the "physics bubble", i.e. only the currently controlled ship and objects within a few kilometers of it. Everything else is on rails. It has to be that way because otherwise the game would bog down the CPU horribly, by forcing it to do huge numbers of calculations for huge numbers of objects, which would be a nasty O(N2) complexity problem. Running things on rails outside a small bubble helps to limit that, and turn it into something close to an O(N) problem, which is much more computationally tractable. However, having a giant thousands-of-kilometers-long structure would totally discombobulate such a system. You'd have to vastly expand the physics bubble, slowing your CPU to a crawl, or else you'd have to come up with some sort of jury-rigged kludge special case solution to make it work, which would unavoidably have other side effects on gameplay. Playability issues. Players have enough trouble trying to dock / connect things even when all the respective objects are in free-fall, moving at relative speeds of centimeters per second, and all the time in the world to adjust and maneuver. To use a skyhook would require precision docking within a window of seconds to a thing that's accelerating continuously at multiple gees and (at the lower end of its arc) moving at high speeds through atmosphere. There is no way in heck a player's going to be able to dock with that thing using "standard" KSP techniques; it will be impossibly difficult. The only way to make it work would be either to put intrusive "here, let me fly your ship for you" autopilot into the game, or to (again) put in some sort of intrusive jury-rigged kludge mechanic that just automatically teleports you to "docked" when you get within a few kilometers of the endpoint, or something. Yeah, you could try to spackle it over with a cutscene or the like, but it would be an interruption in gameplay, and wouldn't involve the player having to 1. design their craft skillfully, or 2. pilot it skillfully. And if you're taking both the design and the piloting out of it, why even bother? Might as well just give the player the ability to "launch to orbit" instead of "launch to pad" from the VAB. UI complexity. However it's implemented, players are going to have to interact with the thing in a very different way than interacting with everything else in the game. This means a whole new slew of UI affordances for dealing with all sorts of issues. To take just one example among many, if a ship wants to rendezvous with one end of a skyhook, how do you track that in map view? It's not in an orbit, it's continuously accelerating, which means you can't use the "closest approach to target" code that the rest of map view uses-- you'd have to have some sort of custom implementation with all the necessary UI widgets to deal with that. Ditto all sorts of other stuff. The devil's in the details. Doesn't mean it couldn't be implemented, but it would be a great big chunk of work just for all that custom UI, quite aside from all the other coding to handle the physics and so forth. Micromanagement. A real-life tether is going to have to either carry rocket fuel to regain momentum after it gives a ship a boost, or else it will fore the player to use it for down-bound traffic as well, and shift as much stuff down as up, in order to regain momentum. So the player's going to have to manage the momentum of the thing, which feels like a tedious housekeeping chore. It also means that when the player comes home, they can't just aerobrake as they do now (simple, quick, easy)-- no, they have to do another one of those rendezvous-with-the-end-of-the-tether things. If the game doesn't want to turn all of that into a tedious bore, it would have to add yet more custom mechanics to try to automate it enough not to be a burden, so yet more hassle. ...And all of the above is what occurs to me just off the top of my head. I'm quite sure that if one goes to actually design and implement such a feature for real, there would be scads more stuff like that, once one starts thinking it through to all the nitty-gritty nuts-and-bolts. The devil is very much in the details for this sort of thing, and a feature such as you're asking for has many, many details. It would be a great big honkin' ginormous feature to implement. And that's without even considering whether there's any benefit to it, i.e. playability, what fraction of the player base would like it, etc. I have my own concerns about this, which I could go into at length, but since it's just my opinion about what I like in a game (and my observation of what I think most players are into), I won't bore folks with it at length. The executive summary is that just personally, I think this would be a really badly terrible idea for gameplay. I think it would be intrusive and un-fun. I think it wouldn't add any new value to the fun of the game, while deflating much of the fun value of other aspects. I think some of the benefits it does provide, such as they are, are likely to be somewhat redundant anyway, due to the presence of orbital colonies. If it were present, I wouldn't use it, and its existence would bother me. And my impression of the overall KSP player base would be that the vast majority of them wouldn't have a good use for it, either. I just don't think this feature belongs in the game, period, even if one could wave a magic wand and get it for free. But all of that, of course, is just my personal opinion. If you like something different from me, great-- different people like different things. However, regardless of how much a given player would or wouldn't like such a feature, the fact remains that it would be a hugely expensive and complicated feature to implement, and as such would suck development time away from other things. Given how expensive it would be, and given its (I strongly suspect) limited appeal to the player base, I really can't see them implementing such a thing. A feature that expensive would have to be justified by a huge benefit for the player base, and I'm just not seeing it.

Sure, but it would likely be one of those massive Walls of Text™ to which I am prone, and would take a while to set down. So it'd need to be later when I have time. IRL stuff beckons at the moment.

Actually, my intention was to indicate that, I do have an idea of what I'm talking about, since 1. I am in fact a programmer (have been shipping software for a living for >25 years), and 2. I've got a fair amount of understanding of what makes KSP tick under the hood, since I've been modding it a fair amount for the last few years, and actually going into the reasons would likely be tedious, lengthy, uninteresting, and likely rather cryptic to anyone who's not a programmer, which I assume would encompass most of the audience in the thread.

The other nice thing about it is that if you happen to have fourfold radial symmetry on your boosters, this technique makes a really nice Korolev cross.

Several responses have been removed, due to descending into irrelevant bickering over what constitutes a valid argument-- completely derailing the thread in the process. Folks, please try to remember that we're all pals here. It's appropriate to provide comments on the topic at hand (e.g., for this thread, about cargo bays). It's appropriate to share your ideas about that. It's appropriate to respond to other people's ideas, as long as it's still on the same topic. What's not appropriate is arguing about arguing, or criticizing the fact that someone else has chosen to make a suggestion. If you like a suggestion, great. If you don't like it, you don't have to use it. You can even respond and provide your own alternate suggestion, if you like. But it's not appropriate to criticize people for making the suggestion in the first place... and if someone does do that, it's not appropriate to respond to them. There's nothing wrong with disagreeing with someone, but please try to think of all the other people in the thread, too. Folks who come to this thread do so because they want to read about cargo bay suggestions, not because they want to read extensive back-and-forth infighting about what sort of arguments one should or shouldn't make. Therefore, kindly try to stay on-topic, and leave the sanctimonious finger-wagging to the moderators. Thank you for your understanding.

That sounds... wrong. Simply peeping out of Kerbin's SoI ought to be enough. The only "legitimate" (i.e. non-buggy) way for peeping outside Kerbin's SoI not to count as "orbit the Sun" would be if you came out of Kerbin's SoI with so much excess velocity that you actually are on an escape trajectory out of the Sun. But that would take a lot of dV, and in any case it looks to me from your screenshot that you're not even close to doing that. So, it sounds to me as if you've run into some sort of bug. The first thing I'd suggest would be to try saving and then loading the game. That's not supposed to make a difference, but I seem to recall that occasionally doing that can "un-stick" certain bugs. So, I'd suggest trying that first. If that doesn't work, and it still won't complete, then I'd say you've run up against a legitimate bug, which happens from time to time. If there's a contract for which you're really sure that you've legitimately filled the requirements (which I believe you have), and it's not completing, then it's the game's fault, not yours. In those sorts of situations-- which thankfully don't pop up often, at least not in my experience-- that's where I go ahead and use the Alt+F12 cheat menu to force the contract to "succeeded". I figure it's not cheating if I did the thing and the game's just failing to hold up its end of the bargain.

What engines are you using, and what's the mass of your craft?

There's not any sort of guided-missile functionality in the game. SAS does have a mode for "hold " that will keep you pointed directly at the target, but that's not good enough if you actually want to hit the target because you have to worry about your lateral motion relative to the target. There's nothing built in to the game that will give you that. There are, however, mods that are designed to support more military-style vessels, i.e. being able to target and shoot things. However, that would be a question better addressed over in Add-on Discussions, since it's not about the stock game.

Hello, and welcome to the forums! Moving to Gameplay Questions.

Yes, very. It's not the coasting to apoapsis that's the problem, it's the "going straight up" part. As @AHHans points out, it's a lot more efficient to do a gravity turn. Basically, what you do is to start your eastward turn practically right off the launch pad. Just a smidgeon-- how much is "right" will depend on what your TWR is. If you have a low TWR (e.g.1.5 or below), you only want a degree or two. If it's high TWR, like 2.0 or close to it, you'll want a bigger angle, like 5-10 degrees. Having done the initial eastward nudge right off the pad, you then just follow all the way up. No steering needed. Keep burning full throttle, staging when needed, until your Ap gets up to where you want it. Then coast up to Ap and circularize. Judging the "correct" angle to nudge it off the pad takes a bit of practice, but you'll find that you quickly develop a feel for it (especially if you tend to build your rockets with a consistent TWR). A good way to judge whether you've nailed it is, look at what angle from the vertical you are when you reach 300 m/s. At that point, you should be tipped probably about 45 degrees from the vertical. If you're much more vertical than that, your initial nudge wasn't big enough; if you're much more horizontal than that, it was too much. So, if you get to 300 m/s and see that you're way off 45 degrees, just revert to launch at that point and try again. (Also, note that there's nothing "wrong" with how you're doing it now, if you like it that way. It's just somewhat wasteful of dV, is all. A good gravity turn can save you several hundred m/s of dV compared with an inefficient ascent profile, so it's up to you how much you want to fine-tune your ascent.) If you're only 1 km apart, then for all practical purposes you might as well be in "flat space", i.e. you don't need to think about orbital mechanics, just treat it as if you were both floating out in deep space with no gravity involved. So you can just point your nose directly at the target and thrust to a reasonable closing speed that will get you there in a minute or less (say, 10-20 m/s), then take it from there. The reason that works is that with such a short separation, 1. there's not much difference in the gravity vector that the two craft experience, since the separation is tiny compared with the radius of the body you're orbiting, and 2. if the closing time is only a minute or less, you won't have orbited much of a fraction of an orbit in that time, so motion is pretty close to the classic inertial case. If you were significantly farther apart-- for example, if the target were 50 km away instead of just 1 km-- then you wouldn't want to do this; it would be better to take the orbital-mechanics approach, unless you're in a big hurry and have lots of dV to spare.

This can work. However, I'd actually suggest placing the sepratrons on the front of the booster, rather than the middle. That way, they'll tend to rotate the booster by shoving its nose away from the central core. This is really handy, because as soon as the booster is angled away from the central stack, aero forces will hit the side of the booster, generating outward "lift" and very quickly shoving the booster outwards. It allows even a small sepratron to move a really big booster out of the way: aero forces are big. This aerodynamic effect can be much stronger than just the thrust of the sepratron itself. It's a really handy "force multiplier". (This only applies if you're still in a fair amount of atmosphere at separation time, of course. If you're already well over 25 km when you separate, then the aero forces are so small that it won't make that much of a difference.) The other advantage of putting the sepratrons up at the nose of the booster is that you can usually get by with just one per booster, rather than needing a pair-- put it on the nose, so that its exhaust goes over the top. (One thing to be aware of, with sepratrons, is that they have an exhaust that's hot enough to be destructive. This has the potential to actually destroy the central core in some circumstances. It's pretty short-range, though, so the main thing is just to be careful not to mount the sepratrons too close to the center stack.)

Hello @CharDreemur, and welcome to the forums! I'm not an expert at Kopernicus planet-building myself, but I think it's the case that the height of the ocean cannot be changed. I believe that it's hard-coded to be at zero altitude. (Someone please correct me if I'm wrong!) So, when you're designing a planet, you don't change the height of the ocean. Instead, you change the height of the land. Terrain elevation is allowed to be negative, so if you have a planet with an ocean, any land with negative elevation will be underwater. By the way: Please note that when posting outside the international forums, all posts must be in English. We do have lots of people here who aren't English speakers, so it's totally fine if you aren't perfect! You can always use Google Translate or some similar tool to assist. Or, if you would like to post in Russian, you can use the Russian forum. Спасибо за Ваше понимание.

So, if you're deliberately restricting yourself from rotating the target craft, then that means you have to fly your craft until it's in the correct location (i.e. approximately in front of the target docking port). That has absolutely nothing to do with the navball, and there is no way to gauge that without looking at where your ship is relative to the target docking port on the screen. If it's too dark to see, then either you need some way of lighting up the craft well enough to see where things are, or else you'll just have to wait until they orbit into the sunshine. With a mod like Navball Docking Alignment Indicator, it's easy and straightforward: ...get the three icons centered, and you're on track to dock. More details here. Without such a mod, then basically the only way to do it is to eyeball the two craft and verify that they're facing appropriately. Which, if you're in the dark and can't see them, is basically impossible. Bear in mind that there are three orientation vectors that matter to complete a docking successfully: Your position relative to the target (i.e. "are you in the right place") Your relative velocity to the target (i.e. "are you moving the right direction") Your orientation relative to the target (i.e. "are the two ports facing the right way") All three of these things need to be correctly dialed in, in order for a docking to happen successfully. The stock navball gives you two of these. You have to give you the first one, and to give you the second. But you also need the third, and the stock navball just doesn't give you that. So either you can use a mod to give you that third thing (i.e. the red icon in the above picture), in which case you can dock completely on navball alone... or else you need to use the camera view to eyeball the positioning of things, so that you can manually verify orientation.

Two things that occur to me about this screenshot. The first is that your relative speed is 0.5 m/s. That is way fast. I'd suggest making the closing speed much slower-- i.e. around 0.1 m/s if you're relatively new to docking, 0.3 m/s if you're more experienced. Higher speeds are fine when you're far apart, but if you're really close you want to be going sloooow. The other is, how do you know that you're oriented correctly? I can't see that you're using any docking alignment indicator mod, and it's so pitch-black that I can't see whether your ships are facing the correct way relative to each other. This is crucially important. If the axes of the two docking ports aren't fairly close to parallel, it's not going to want to dock even if you have the position and the velocity dialed in pretty well. What technique are you using to ensure correct orientation?

Well, I guess it comes down to this: You've got a problem, and you would like somebody to do something about it. Therefore, presumably you would want to do whatever gives the best chance to have it addressed. The folks who actually work on the game have said that the best way to help them address the problem is to open a bug report on the tracker. You can choose to believe that or not, you can choose to make a report about it or not, it's up to you. But given that they're the ones who actually need to fix it, and they've said what they need... my own suggestion would be to do what they've suggested, if you want to optimize your chance for having it addressed. If you just feel like venting rather than trying to get it fixed, that's okay too-- bugs are frustrating, and it's totally understandable to want to vent. But if the goal is more practical, i.e. actually get it addressed, I'd suggest following the path that's designed for that. That's what will be the most helpful in actually addressing the problem. Great, thanks! Any chance you could post a link to it here, so that other people affected by the bug could vote it up, and/or provide their own details, repro cases, etc.?

Another thing you can do-- crude, but very simple-- is to just increase the ablator load on the heat shield to full capacity. That will make the heat shield heavier, and move the CoM closer to that end of the craft. Even a small move on the CoM can make a significant difference to stability. Of course, that also means you're lugging more mass than you actually need-- ballast, in effect-- which normally is anathema to spacecraft. So I totally understand if you'd prefer not to do that. Just... it's a potential tool in the toolbox to be aware of. No, it means center of dynamic pressure behind the center of mass/gravity. Center of lift means where the cyan indicator in the VAB is. Nice and easy to see where it is, but unfortunately is not what matters here. Whereas what does matter-- the center of dynamic pressure (or, if you prefer, "center of drag" though that's not a technically accurate description)-- alas, does not have any visible indicator so you just have to eyeball it. Overall, "move the CoM towards the end you want to be in front" is the main thing. Fins and such can help, too, but the CoM really matters. Are you sure this is true? I was under the impression that KSP's simplistic aero model does not model occlusion in that regard, and that the "airstream" affects them even though they're behind another part. Note that I'm talking about aero forces here. Heating definitely does model occlusion. But I believe all parts that aren't shielded in a fairing or service bay do in fact experience aero forces, or at least that was my impression. My take on "why didn't the fins help" was that they simply weren't big enough, and/or far enough from the CoM, to overcome the big drag on the front end of the vessel.

I would probably use them more often, but they've got some bugs that can be intrusive in certain use cases. Most common use cases, for me: Extensible arms for solar panels Tilt-engine VTOLs (this is where the bugs bite, for me) Custom landing gear for large craft Propeller craft for exploring non-oxygenated atmospheres (Duna, Eve) Fold-out heat shields for aerobraking

Yes, and this sequel is going forward. They're putting tons of new features in there, including multiple star systems, multiplayer, and colonies. So? Not what I said. Porting any feature across comes at a cost. And that cost is taken out of the budget available for implementing other things, including snazzy new features like new star systems, multiplayer, colonies, etc. So, for any given feature, it's not a no-brainer to port it across. If the developer is behaving responsibly and running a professional shop, it means that everything is considered rationally, balancing costs versus benefits. So for a given feature, the question becomes: How much benefit does the feature provide? How expensive is it to implement? The "benefit" is going to be essentially the product of "how cool is it" versus "how much demand is it among the players". For example, if there's a feature that I think is the absolute coolest thing in the world ever, but it turns out that I'm the only one who likes it and the other millions of players just go "meh" and don't think they need it, then that would be a really poor choice for the devs to implement. To take another example, if there's a feature that's super easy and low-risk to implement, it may very well "make the cut" even if only a minority of players like it and will use it, as long as the minority's not too tiny. But, on the other hand, if a feature is super expensive and very high risk to implement, then the bar would necessarily be a lot higher-- you'd need a lot bigger percentage of the player base to be into it before you'd consider implementing. The robotics in Breaking Ground are a great, big, huge, enormous feature. It's a lot of code work, with a lot of risk (i.e. "attack surface" for bugs). Heck, Breaking Ground itself came out months ago, and still has a fair number of pretty bad bugs in it. That's not because Squad is incompetent-- they're not-- but just because it's a really hard, high-risk feature. Now, put yourself in the developer's shoes. We don't know the relative sales numbers for Breaking Ground versus KSP itself... but they do. I have no idea what percentage of players chose to buy Breaking Ground; and, among the ones who did, I have no idea what fraction of them really get into the robotics. But I wouldn't be surprised if it's a minority of players. I myself? I adore the robotics stuff, I love Breaking Ground, and I myself really, really want the robotics to be available in KSP 2. If I had a magic wand that I could wave and bring all the robotics into KSP 2, I'd do that. But the developers? They don't have a magic wand. All they have is, 1. a finite amount of time, 2. a finite amount of money, 3. a finite number of developers, and 4. a very long list of other features demanding their time. So even though I myself would really like to see the robotics go in... depending on what the "demographics" are of the KSP base, it may very well be that they simply looked at it and said "we don't have the bandwidth to do that, and/or there's not enough demand to justify the extremely large investment that would be required to include that feature." You keep referring to that as if it's a done deal that's going to happen. Why do you assume that? Citation please? Got a link? Did they announce something that I missed? It means that they have made no commitment that the parts would be implemented. (They also haven't definitively said that anything, robotics or anything else, would never ever under any circumstances be added.) I assume they'll do what any reasonable publisher would do, after the game comes out. First they'll watch the market to see how well it sells. If KSP 2 bombs, if it's a total flop, then I think it's safe to say that there will never be any DLC for it ever. On the other hand, if it succeeds well enough that they gauge that there would be a good market for DLC, then we likely will get DLC. As to which DLC we get, I assume that that would be based on perceived demand. They'd naturally build what they think they can sell the best. Would that be robotics? Maybe. Or maybe it will turn out that players will have a lot more demand for something else, and they'll do that, instead. I assume they'll go where most of the players want to spend their money. Since neither we nor they nor anyone else yet knows, 1. how well KSP 2 itself will succeed, or, 2. what types of DLC content may be in the most demand, I suspect that these questions simply haven't been answered yet. Why? I mean, suppose we assume-- just for the sake of argument-- that they're competent and have a reasonable idea of what players like and are willing to spend money on, and that they keep an eye on the forums, and so forth. (I realize that that's not a given, because obviously there are stupid companies out there that have done stupid things. But I have yet to observe anything that would indicate to me that Star Theory is heading in stupid directions-- quite the contrary. So it seems to me like a reasonable default assumption to make, until and unless we get evidence to the contrary.) If we assume that they basically know what they're doing and have a reasonable finger on the pulse of the community, then it would logically follow that whatever they sell afterwards will be something cool that players will like. So if that's what they're doing... well, I dunno about you, but that's what I really care about. I care that the developers have their hearts in the right places and understand the needs of the community. I care that they're going to sell me really cool stuff that I will like, more than I care about any one specific thing. So, for example, I'd love it if they came out with robotics. But if, instead, they came out with something else that I end up liking too, then I'm fine with that, too. Hm? How do "we all know" that? I don't know any such thing. I think colonies are a neat idea. So does RoverDude. So do a lot of other people. Any neat idea that lots of people like is going to have examples of people talking about that stuff. Doesn't mean that they're then "un-creative" if they happen to implement a feature like that. I mean, seriously, if the criterion is "you're not creative if you're implementing a thing that anyone has suggested or made a mod about ever", then essentially they should just quit now because nothing could ever be "creative". KSP added CommNet in 1.2. Guess what? RemoteTech existed before then. Doesn't mean 1.2 wasn't "creative", and it also doesn't mean that it was "based on" RemoteTech in any way. It's its own thing. I assume they did so because KSP players have been asking for moving parts for a very long time. Where there is demand, there are going to be mods, so I'm not surprised that IR exists, but that doesn't mean that what they built was an "adaptation" from IR in any way. They just made their own thing, that's all. Correct. I believe it won't require robotics. This seems pretty obvious to me, because they've explicitly stated that, 1. colonization will be in, and 2. robotics won't be in. So, take those two definitive statements from them, and this seems pretty clear. So? Why were you expecting that, given that their explicit statements demonstrate that it's not? No, why would they? Those are very simple, easy parts to implement that don't require massive amounts of code to support. Those are low-cost, low-risk features to add, and KSP players are used to having them in stock. So it seems like a pretty clear win to me to include them. Robotics? Not so clear. I myself would love for robotics to be in, but honestly I have no idea how widespread the demand is for them; it may just be a small minority of players. (Anecdotal, unscientific data point: Go look at how many questions / tech support requests / general discussion happens about stuff in the stock KSP game in the forums, and then go over into the "Breaking Ground" sub-forum and see how much discussion is there about the robotics. The former is hugely more frequent than the latter. That right there gives a suggestion that the KSP community as a whole doesn't regard robotics as a must-have feature.) And robotics are a hugely expensive and risky feature to implement. Very complex, very rich source of bugs. Sure. I do all those things too. But it's also a game, and what is expensive in developing a game is not the same thing as what is expensive in building an IRL spacecraft. For example, if you look at a Canadarm-equipped space shuttle... what percentage of the spacecraft development and construction cost does the arm represent? I'd be astonished if it's as high as 1%. Probably far less than that, would be my guess. But if you put it in a game, it's the other way around. The development cost behind implementing all the physics and control systems and so on and so forth, in order to enable that arm, would be far bigger than the rest of the shuttle. Then think about: when players launch their craft, what percentage of their total "fun value" of launching orbiting, landing, and doing other stuff with the shuttle does that arm represent? It'll vary from player to player, I suppose, but I bet it's not the majority of the value. It's about cost versus benefit. I mean, suppose they came to you and said, "Okay, you can have robotics, but it means we'll have to cut multiplayer in order to make room for it." Would you want that trade? (Well, I would, because I really love the robotics and I have absolutely zero use for multiplayer. Personally I would love it if they cut multiplayer completely and spent that time and energy on something else that I'd actually use and enjoy. But it's about what the player base as a whole likes, and I suspect that a lot more people would be into multiplayer than would be into robotics; I suspect I'm in a minority there. So from the devs' perspective, I expect it makes a lot more sense to invest in multiplayer rather than robotics, even though that's not what I myself would want.)