Snark

Well, that's what "autostrut to heaviest part" is for. I don't build spaceplanes all that often, but when I do, I always autostrut at least the biggest, most prominent wing pieces. (That, and avoid building long floppy multi-segment wings if they're likely to be subjected to major stress.) (Actually, I quite often find myself designing biplanes. Not only does this mean that the wings only need to be half as long and are therefore stiffer and stronger; but it also lets me mount them top-and-bottom, leaving space in between where I can mount engines amidships-- which I like to do, because engines are heavy, and otherwise I kinda need to put the engines at the back of the plane, where they tend to pull the CoM rearwards and make the whole thing aerodynamically unstable. But I digress.)

True, though in my experience, this tends to be less of an issue for spaceplanes than it does for traditional capsule-style reentry. The traditional capsule-and-a-heat-shield type of reentry just plows straight ahead as it falls, meaning that if it comes in steep, it stays steep (and indeed gets steeper). So, such a craft ends up rapidly making its way to the lower levels of the atmosphere while it's still going really fast, so the air resistance builds up very quickly and they end up pulling a lot of G's. The steeper the descent, the more G's. For a spaceplane, though, holding a nose-up reentry generates a lot of lift, which bends the trajectory upwards once the craft descends far enough for the wings to be able to "bite". So the craft doesn't suddenly end up in the lower reaches, and they tend not to hit that brutal G spike; they pull gees, yes, but they tend to be milder acceleration, stretched out over a longer period of time. Don't get me wrong, if you do something silly like hit atmosphere going straight down, then yeah, you're not gonna have a good day. But for most "reasonable" descent profiles, e.g. if your Pe before hitting atmosphere is above ground level, then spaceplanes tend not to hit excessively high G force.

As other folks have discussed in the thread, there isn't really any way to heat-shield a spaceplane. However, there is one thing you can do that can help a lot: design it to have a very low ballistic coefficient. In less high-falutin' language, that means: design it to be very lightweight with lots of wing surface. Build an albatross, not a javelin. This works because what fries you is not just being in a high-speed airstream, but staying fast for a really long time. If you make a craft that has great big expanses of lightweight wings relative to the mass of the craft, then you can make it become extremely draggy by pointing the nose up and presenting the flat side of the wings to the oncoming airflow. The combination of high drag and (relatively) low mass means that the craft will slow down very rapidly, and not have time to heat to the exploding point. TL;DR: Wings make extremely effective airbrakes. And what heats you up is your craft's mass. (The other thing you can do is to stay very aware of the max temperature of all parts exposed to the airflow. Most parts can take 2000 degrees or more, but a few-- notably, science experiments and the lower-end probe cores-- have a much lower max temp of 1200, and are easy to go boom. Keep those out of the airflow, either by putting them inside cargo bays or on the upper surface of the craft where the body shields them, and you'll be much more temperature resistant.) Also, this. Very much this. Don't make the mistake of trying to come in super-shallow; you'll fry yourself without slowing down.

Absolutely, and in fact it's usually vital to do so. SRBs are great for boosting off the pad, but once they're burned out, they're just dead weight-- and a lot of it, too! So definitely stage them away as soon as they burn out. In general, the way to design multi-stage rockets is to discard each stage (engines and empty fuel tanks) as soon as it's burned out and no longer helping you move the ship. It makes a world of difference.

That's great, but... care to include a link to the bug report, for those of us who may be curious to follow along?

Whoops-- missed seeing that one additional spoiler. Never mind.

Moving to Gameplay Questions. I don't believe it's possible in the stock game. However, perhaps there might be some mod out there that allows organizing crew rosters? Might be worth asking in Add-on Discussions.

[EDIT] Never mind what I said here, I missed seeing that the OP already did exactly this. Redundant suggestion moved to spoiler so as not to clutter people's eyeballs unnecessarily.

Moving to Gameplay Questions.

Moving to Gameplay Questions. That's... actually the exact opposite of the problem, typically. Rockets tend to be unstable because they're too bottom heavy-- you want them to be top-heavy, generally speaking. Having the center of mass near the top of the rocket makes it aerodynamically stable. Again, this is actually the exact opposite-- if the rocket is unstable, it helps to raise the CoM, not lower it.

Various content has been redacted and/or removed. Folks, please be civil. It's entirely appropriate to engage in lively debate about matters of scientific fact; if you think someone else is incorrect, by all means point that out, and give your reasoning & evidence why. However, it is never okay to engage in trolling, personal remarks, or insults, per forum rules 2.2.d and 2.2.n. Please address the post, not the poster; if you can't win your argument or make your point without resorting to name-calling, finger-pointing, or outright mockery, then perhaps best just to stroll on by. Thank you for your understanding.

Moderator's note: @ARS asked an interesting question about calculating interatomic distances in metals, and the ensuing discussion became quite lengthy, so it has been split off into a separate thread (including the original question). The new thread is located here: We now return you to your original thread, already in progress.

Yeah, me too. I miss it. That's a neat idea. I'd have to do some research, though, to figure out how practical this might be. The issue is that even though the stock countdown might be turned off... the stock estimated burn time is still there. And the countdown indicator has to be keyed off of that. And the stock estimated burn time won't necessarily mesh with BBT's estimate (since stock takes into account staging, and BBT doesn't). So to prevent it from being out of whack, if I were to show the BBT countdown dots, I'd need to figure out how to get at the numeric data that stock has calculated for the burn duration, and I don't actually know that that's programmatically exposed anywhere that's accessible to modders. Hopefully it might be, but I don't actually know that. And even if it is, I'd then have to do a fair amount of rewiring in BBT to feed that number (rather than BBT's own calculations) into the countdown display. So, I'm not saying "no", and I do like the idea-- it's just that it would take some research and a fair amount of coding to do, so it's non-trivial. Therefore, I'm not sure when I might have a chance to get around to it. (What would make it more likely to be sooner rather than later would be if some kind soul did the footwork for me and could tell me exactly what code's needed to, 1. get the status of the extended indicator being turned on or not, and 2. get the numeric data for the stock burn time estimate, and-- ideally but not strictly necessarily-- 3. the ability to get at the numbers for the extended burn indicator, even if it's not being displayed, i.e. what countdown value it would be giving based on the current selected dV percentage. Hint, hint.) So, thank you for the suggestion and I'll definitely bear it in mind-- but I don't know when or if I might implement it.

Hello, and welcome to the forums! Glad you find it useful! I have no idea what you mean by "interstellar" here, I'm guessing some other mod. My guess is that this is some issue with your particular installation. IndicatorLights has zero external dependencies, other than ModuleManager itself-- I haven't included anything from any other mods, and in any case, IndicatorLights contains no code or config to affect the tech tree at all. So if you're seeing some content from some other mod showing up in the tech tree, then my guess is that you've got some sort of detritus from another mod in your GameData folder, and it's interacting oddly in some way. My suggestion would be to check your GameData folder carefully, and make sure you have everything installed in the correct place and don't have any leftover files from any mods that you might have uninstalled.

Ah, okay. Sorry 'bout that. Moving back to Gameplay Questions. So, aiming for a particular inclination exactly is kinda tricky. If you're willing to do a little bit of trigonometry you can work it out more exactly, but generally what I do is just eyeball it, which I find gets me within a couple degrees with a bit of practice; and then I can just manually adjust the inclination once I'm in orbit, which isn't too expensive if it's just a small adjustment. The easiest way, for me at least-- both for the inclination and for getting the longitude of ascending node-- is to eyeball it in map view, but with the view set to Kerbin centric (instead of the default ship-centric view). A common use case for this is when I've taken a contract to put a satellite into a particular orbit, and the orbit is inclined by a fair amount, like 30 degrees or whatever. In such situations, here's what I typically do: Get the target inclination. It's generally specified in the contract wording. Or, alternatively, I can just switch control to a satellite I have in LKO in a perfectly equatorial orbit (I always have at least one), and then check out what the AN/DN says in map view. In the VAB, design my satellite that's going to be heading to the target orbit. (Side note: For launching into equatorial orbit, I always design my craft facing east, rather than the game's default of north, because that makes way more sense to me-- I do my gravity turn by pitching down, rather than yawing right. I used to do this by manually rotating the root part by 90 degrees in the VAB each time, but eventually that got too tedious so I made a mod, VABReorienter, that makes that the default for me. The remainder of this discussion assumes that the craft is facing east to start with, for launching to zero-inclination orbits.) For a zero-inclination launch, I normally face east. Since this is going to be an inclined orbit, after I finish building my craft, I use the rotate tool to rotate the root part (and therefore the whole ship) left or right a bit to match the desired inclination. For example, if I'm going to be launching at the ascending node and the target orbit has an inclination of 30 degrees, then I would rotate my craft to the left (i.e. north) by "a bit more" than 30 degrees. Why it's "a bit more" than the target inclination: This is because Kerbin is rotating, so even when you're at zero velocity relative to the ground, you're already moving eastward at around 174 m/s. So therefore you launch a little bit farther to the north (for launching at the AN) or south (for launching at the DN) than the target inclination. Just eyeball a smidge different, like 3 or 4 degrees. Close enough. Okay, now my rocket is facing the correct direction to launch into the desired inclination, or pretty close to it, anyway. Now launch it to the pad but do not yet take off. You want to get the longitude of ascending node correct. The way to do this is to launch your ship when it's directly under the AN or DN. How to do this: While you're sitting on the pad, switch to map view. By default, the map view is centered on your ship. Change this by double-clicking on Kerbin, so that the view is centered on Kerbin, instead. Rotate the camera to latitude zero, i.e. so you're precisely over the equator looking "horizontally" at Kerbin. Now rotate the longitude of the camera until you're looking precisely edge-on at the target orbit. From this viewpoint, it's collapsed to a straight line passing through Kerbin's center. Note also that at this viewpoint, you'll see the pointy tips of the AN/DN markers just about touching each other, right at Kerbin's center. Now, without moving the camera, start to time warp. You'll need to warp forward a few minutes or hours until your spacecraft (sitting on the launch pad) is directly over Kerbin's center in the camera view, i.e. directly between the AN/DN markers. Congratulations! Your ship is now sitting directly under the AN or DN of the desired orbit. Now's the time to launch. Launch the craft and immediately begin your gravity turn by pitching down, same as usual. Climb to LKO and circularize as you would usually do. You'll have pretty close to the desired inclination, but likely you'll be off by a degree or two. So, after you're well underway (e.g. when you're going mostly horizontally and you've reached the point in your gravity turn when you're pointed, say, 30 degrees or less above horizontal), you can look at the map view and check your AN/DN with respect to the target orbit, and adjust your aim slightly to the left or right for the remainder of the burn in order to correct it. Anyway, that's what I do-- it's not mathematically perfectly accurate, but it gets pretty close and requires only a very small fine-tuning correction burn to make it exactly accurate once in orbit.

Me too... but I can never remember to do that, and also it's a pain to go 'round and do if I've got a lot of RCS thrusters present. So I just made some ModuleManager config that tweaks all the RCS thrusters to have yaw/pitch/roll disabled by default. You can find the config here: https://github.com/KSPSnark/SnarkTweaks/blob/master/stock/NoRCSRotation.cfg ...just grab that file and drop it anywhere in your GameData folder. As long as you have ModuleManager installed, it'll set them all to default yaw/pitch/roll control authority turned off. (You can always turn it on, manually, if desired.) Yep, it's really handy. See the above link for a handy config file that will make them default to that state, if you don't want to have to remember to do it manually every time.

So... depends on how attached you are to the "what" versus the "how". Everyone has their own playstyle, of course, and that's fine. My own take on this would be that you're making life far too difficult for yourself by trying to fly multiple ships in formation, and doing far more docking operations than you need to. It boils down to this. My observation has been that, Docking two-- and only two-- ships together, is easy. For any ships, no matter how big they are. (Yes, even if they're a thousand tons each. If this is your concern, there's a separate conversation we can have about that.) Flying in formation (i.e. station-keeping near each other, without being docked) is really hard. (Yes, there are ways to do it, and if you're insistent that you have to, we can talk about how best to do that. But my own advice would be, simply, "don't".) I haven't seen what your ships look like, exactly, but it seems to me that you'd have this solved in a trice if you'd just limit things to two ships (or, at least, two ships at a time). For example: I get that you have a big interplanetary mission ready to launch, with separate pieces. Why all the shuttling back and forth? If it needs a bunch of fuel, why not just have a single big fuel hauler that holds enough to fuel the whole thing, and just dock the hauler to the mission, transfer fuel across in one go, and you're done? You'd have the whole problem wrapped up in five minutes with no fussing about, and only one docking required. In my own games, I generally design stuff with this philosophy in mind. I dock craft A to craft B, and that's it; no shuttling back and forth between multiple craft that need to stay parked right next to each other. On those occasions when I do need multiple things... then that's when I use a "space station" to tie things together. My space stations are typically not grand affairs-- basically just something with a decent sized fuel tank and perhaps a bit of crew accommodations, but mainly what they offer is a bunch of docking ports in various sizes, widely spaced on projections that make it easy for the structure to serve as a "parking lot" to which I can dock as many ships as I need to. In a scenario like that, what you could do is this: Don't try to park all these multiple ships in formation and then shuttle back and forth between them. Instead, dock them all to a space-station hub, one at a time. While they're all docked, you can easily transfer resources back and forth among them-- no shuttling back and forth needed. So, those would be my own recommendations to you. Idea 1 (the simplest), just make this into a two-ship scenario, where your fueler docks to your interplanetary mission and that's it. Idea 2 is to use some sort of space-station hub to "glue" everything together, so that if you must have multiple ships involved, you can just dock them all to the station. Would one of those ideas work? Or is there some reason why you're especially attached to your current design (or some reason why you dislike one or both of those ideas)?

I always get a chuckle out of "Settling Argument of Periapsis".

Hi @EquliDucko, We're sorry, but we've had to remove your links because they violate the add-on posting rules. The license of this mod is, The "ND" clause of that license means "no derivatives", meaning that you cannot modify the mod and post your own version of it. It's not legally allowed. We're sorry, because clearly you mean well, put some work into it, and are just trying to help... but unfortunately, the license of this mod doesn't allow you to do what you're doing. It's the author's choice, so we have to respect that. (Note that even if the mod had a more permissive license did allow you to post your own tweaked versions... it still would not be okay to simply post a link to a zip file with your modified copy-- there would be some hoops you'd have to jump through, per the abovementioned add-on posting rules. Specifically you'd need to find a place to post-- ideally in your own add-on releases thread-- where you could specify the license, include a link to any source code, follow any requirements that the license imposes, etc. But in this case, all of that is moot, because the mod has a restrictive license that prevents derivative works at all.) We're sorry for the inconvenience, and thank you for your understanding.

Moving this to Tutorials, since this is a "here's how you do this" post, rather than a "how do I do this" question.

Yes, that was what I heard, too, when I was with a few other fortunate folks visiting the Star Theory dev studios in August 2019 shortly after the KSP2 announcement, and we got to ask questions like this to Nate Simpson and the developers, face-to-face. It was pretty clear at the time that they had no plans for FTL. However, that was well over a year ago at this point; and since then, Star Theory has gone defunct and the development has moved over to a new dev studio. I haven't been following recent developments closely, so it's possible I could be out of date. However, I note that it's still the same people in charge of the overall project, though (e.g. Nate's still the creative director), and I haven't heard anything to make me think that the overall creative direction of the game has changed significantly, so I'd expect that the "no warp drive" design to still be in place.,

As @Spricigo correctly points out, it's perhaps best not to try to engage with advice that's half a decade old. The game has changed tremendously since 2015, including major changes to the reentry-heating physics model. To help put things into perspective: just a couple months before I wrote the above advice, there wasn't any reentry heating at all in the game-- it was a brand-new thing at the time I was writing, and they've tweaked it a lot since then. In particular, at the time I wrote that, it was possible for an EVA kerbal to come all the way from Minmus and slam into atmosphere at over 3000 m/s, even straight down, and have no problems at all. Now? ...Not so much. Anyway. Since the person who originally asked this question five years ago has presumably long since found an answer and moved on, locking the thread to prevent further confusion. If anyone else has questions about reentry heating or anything else, please feel free to open a new thread about it.

Have you disabled the steering on the rear wheels? If you haven't, then by default they'll steer, too (in the opposite direction from the front ones). That's a handy thing for tight turning radius and maneuverability, but can lead to instability at speed. Disabling the steering on the rear wheels will make it steer the way a car does, i.e. only the front wheels turning, which should be easier to handle. Yes, my own advice would have been the exact opposite, i.e. "make sure you have some hefty reaction wheels and SAS enabled". Though it's important to remap the rover steering controls awayt from WASD, so that you don't end up generating reaction-wheel pitch and yaw torque when you're trying to steer the rover. No idea why they made those two sets of controls use the same keys by default; hilarity always ensues. Personally, I like to use the numpad keys for steering the rover, so that they're not interfering with WASD.

My understanding (possibly out of date) is that they intend to handle interstellar travel as just conventional rocket propulsion, but with extremely high Isp engines that can maintain continuous acceleration for long periods. Thus, no "warp drive" required.

Mainly make sure that your center of mass isn't too low. Fins are good, yes, but they only work if the CoM is reasonably high above them.