Snark

I assume you mean longitude, and I'm the wrong guy to whom to ask that particular question. I don't care in the slightest where I come down with respect to KSC, since 1. it's pretty much irrelevant for gameplay purposes, and 2. it's not a challenge I'm especially interested in, and 3. I practically never fly spaceplanes (they're a pointless waste of time for me). When I reenter, basically my only priority is to survive (which is pretty easy), to which I add a slight preference to coming down on the daytime side of the planet ('coz it's prettier) and on land ('coz it's more interesting to look at). For folks who do care about exactly where they land, the really big question is whether you're doing a simple ballistic reentry, e.g. space capsule with heat shield (where you just plow through atmosphere until you slow down, then drop vertically on parachutes), or whether you're flying a craft with significant aerodynamic control (like a spaceplane). The latter is much easier to control the landing location precisely than the former. On those (very rare) occasions when I'm flying a spaceplane and decide to try to land at KSC (or as close as possible) just for a thrill, I generally do my (fairly light) initial deorbit burn over the eastern part of the big desert area across the western sea from "Kerbafrica" where KSC is, lowering my Pe to around 30 km (far to the east of KSC). As I approach the western shore of "Kerbafrica", I generally do a heavier burn that lowers my Pe below ground level, with a projected surface impact point in the ocean a little east of KSC. Then I use aerodynamic control to steer my way in. The important thing to remember when going for a precise landing using a spaceplane (or other craft with significant control surfaces) is that aerodynamic control is king. How you steer the plane makes a huge difference in where you land. It's also worth noting that a steeper descent is easier to predict and control than a very very shallow one. The thing to do is to move your Pe below ground level with an impact point just slightly east of KSC, and then you can use steering to try to keep your target impact point as close to KSC as possible as you descend and slow. You get the most control (I believe) at an AoA of around 25 degrees or thereabouts, so aim for that. If your projected landing spot is heading westwards of KSC too quickly (due to drag slowing your speed), keep your nose pointed above by 25 degrees, so that you generate efficient lift and extend your glide range. If your projected landing spot is overshooting KSC to the east, and not decaying westward quickly enough, then roll 180 degrees to point your belly at the sky, and keep the nose pointed below by 25 degrees, to generate negative lift and bring you down sooner. If you're reasonably on-target but still going way too fast when you're down low in the atmosphere, and are at risk of burning up and/or still going way way too fast at ground level, then you can pitch up way past 30 degrees to add lots of drag, and/or you can roll on your side to generate lift sideways (alternating left and right) to make big S-curves like the IRL space shuttle did. TL; DR: It's remarkable how much control you can have, if you've got some control surfaces to work with. Steer your way down.

Moving to Technical Support.

Moving to Gameplay Questions.

I just set my Pe for about 30 km, regardless of craft or mission. Works for pretty much everything, is steep enough not to get baked but shallow enough not to black out tourists, works for pretty much any arrival velocity.

This. Eeloo is in 3:2 resonance with Jool, so even if they were coplanar they'd never have an issue.

Reading voraciously, drone photography, and hiking.

Locking per OP request.

Moving to Fan Works.

For the curious, here's the discussion of methodology.

Hello, and welcome to the forums! By golly, there is! You have a few options. One thing is to use ModuleManager to just tweak the part to be LFO instead of liquid-fuel-only (this would require authoring a bit of custom config, which requires some ModuleManager literacy, but I'm sure folks here would be happy to help out if this is what you'd like to do). Or, you could use some mod that allows switching fuel types for tanks. By far the most popular is Interstellar Fuel Switch: Or, another alternative would be my mod SimpleFuelSwitch: ...it has the advantage of being fairly standalone, with minimal dependencies, and is (as the name promises) very simple. (Which is why I wrote it. Interstellar Fuel Switch is very cool, but it's fairly big-and-fancy for my tastes and has some dependencies and such, so I wrote SimpleFuelSwitch just to be a very low-key, targeted mod that does just that one thing in a very minimalist way.) I'm sure there are other mods too, but those are the suggestions I've got off the top of my head.

Thank you! FWIW... it did come across in exactly that way, fairly strongly (at least to me)-- as did many of the preceding comments in the thread, which I suspect was the cause of much of the contentiousness here (including my own). If that wasn't the intention, then great. Okay, see, now there is an idea I could get behind. There would be a few i's to dot and t's to cross in getting the UX ironed out for starting up a new game, but it would essentially allow players to eat their cake and have it, too. Not only would it allow what amounts to current career mode, science mode, and sandbox mode... but it would also allow a mode that doesn't really have any current equivalent-- "finance mode" (in which player has to worry about funds, but not science). So it wouldn't be taking any functionality away from players as it currently stands-- if someone likes playing the game in a certain way now, they'd still be able to play their way. And if done right, it might simplify and streamline the UI and perhaps moddability. I find this particular example to be especially interesting, because I think it does a good job of capturing much of the dynamic of this thread (and of "how to have productive disagreements" in general). Compare the following two statements: Unhelpful formulation: "X is bad, because <reasons>." Helpful formulation: "How could we better achieve the same thing that X currently lets us do?" These two statements are actually addressing essentially the same issue ("I don't like X and want to improve on it")-- but the latter is going to get a lot more traction than the former, in discussion. "Don't allow an option for career or sandbox mode" is something I'd fight tooth and nail-- because it implies taking something away from me, and many other KSP players. But "Hey, here's an alternate way that everyone can have what they actually want, without actually necessitating having separate career and sandbox options per se"-- now we're talkin'. So in that particular case-- given that particular suggestion-- I could see your suggestion as having some great points. Because it was re-phrased in a way that gives a viable alternative. This brings me back to the original thesis, though, ...because stating it that way goes back to what I've called the "unhelpful formulation" above. I don't think there's any helpful way to make such a sweeping generalization. It doesn't propose solutions, and it really does come across as "everyone should play the game exactly the same way", even if that's not what's meant. To be actually helpful, I think it needs to be case-by-case. For example, in your above post that I just now quoted, we took one option (career versus sandbox mode), and you deconstructed it with some creative ideas for how to deliver what people need, without having to have a big "option", per se. That's good, as far as it goes... but it doesn't address the other options in the game. I think it would be really interesting to discuss various other options, too, in that same vein-- but I also think it's likely to be a productive discussion only if we hew as closely as possible to the more helpful formulation proposed above. If I may propose an example: What about CommNet? There are currently several options around this. There's the ability to turn it off completely; have extra ground stations on or off; have regular or "hardcore" mode (where comm failure means total loss of control). So-- definitely "options" there, now. So... if you don't like that, what would you do? In the above formulation: "How could we better achieve the same thing that CommNet and its options currently lets us do?" Bearing in mind that the KSP community currently includes large numbers of several groups of players, including: People like me who prefer a very hard-core experience (for example, total loss of control; no extra groundstations; no "soft" occlusion modifier for atmosphere). People who like it, but want a fairly "soft" experience, something like the default options. People who can't stand it and find it an annoying distraction, and just want the whole thing turned off. I think each of these three groups contains a lot of players, and I think someone from one of these groups would be very unhappy if features were changed or removed that forced them to play like one of the other groups. So, with that in mind... how would you go about solving that problem, without options, and without leaving any of those groups out in the cold?

So, I'm a bit late to the party, here. TL;DR is that I disagree with the thesis, and personally, I think that options are a good thing for KSP to have. Much of the discussion seems to be various assertions of "Options are bad!" or "Options are good!" That's fine, as an expression of personal opinion of what one likes, since of course that's everyone's personal prerogative. However, having shipped commercial software for a living for a quarter-century means that I see everything through software-engineer-tinted goggles, so to speak, so I'll take the liberty of re-framing the question in language that makes sense to me: Options are a feature. Just like any other feature, they have benefits and costs. Whether any particular feature should go into a piece of software or not is therefore an exercise of estimating, as well as possible, the magnitude of the benefits and the magnitude of the costs, and weighing the one against the other. Benefits > costs = good idea. Costs > benefits = bad idea. So, to me, the real topic of debate basically boils down to: Would options be a good feature to add to KSP? It's just a feature discussion, that's all, like any other. And to answer that question, it comes down to: What benefits would it provide? How costly would it be? I happen to think that the benefits in KSP are very, very large, given the open-ended nature of the game and the extreme variability in how players like to play it. I think the costs are manageable, if done right (which, in KSP, I believe they by and large have been). So I think it's hands-down a good idea to have them. Sure, I have no argument with that. Because they're features, and all features create bugs. But that's not a reason not to have them-- if you eliminate every feature that could have bugs in it, you'll end up with a product with zero features. So I assume what you're really claiming is that they create way more bugs than some other feature would-- so many that it would offset the benefit that they provide. However, I haven't seen you provide evidence for that assertion. Could you elaborate? Because I've seen plenty of counter-examples. There are lots of successful, popular games out there that do have major options in them that greatly benefit the player base. Or, I could take KSP as an example. Consider career mode, versus sandbox mode. I hope we can agree that that's one heck of a "big" option, in terms of scope and impact on gameplay. Choosing one or the other enables/disables a whole slew of other features, all across the product. So... are you saying that that is a bad option? My assertion that that particular option's a good one (in spoiler, to save wear-and-tear on uninterested eyeballs). The TL;DR is that I think that option has a very large benefit (expanding appeal across the player base), and isn't particularly buggier than any other KSP features. Yes, it's a big cost, but-- for me, at least-- worth it. Making CommNet optional? Why is that such a bad thing, in terms of costs and benefits? Players who like it... get the benefit of having it. Players who don't like it and don't want it... don't have to have it rammed down their throats. (And yes, there are such players.) Making it optional is pretty simple and easy, if it's designed to be that way from the get-go (which it appears it was). I've seen no evidence that making it optional is particularly bug-inducing. Certainly making it optional isn't free (both ways have to be tested, etc.) But you seem to be unambiguously asserting that you know that it's a bad choice to do so, and that anyone who disagrees with you is just wrong. May I ask how you know that? The only way to be able to assert that would be to know the benefit (e.g. detailed usage statistics)-- which I don't think is publicly available-- and to also know the cost (e.g. exactly how many dev & QA hours were needed to implement the option)-- which I don't think is publicly available, either. So unless you've got access to data that the rest of us don't... I don't see how it's possible to assert this. Speculate, sure. Assert, not so much? I really don't think you're in a position to say that people who disagree with you do so only because they're somehow less well informed than you. For example, I've been a professional software engineer for 25 years, and I've got a pretty good handle on optional feature sets, thanks-- and I happen to disagree with you on this point. (FWIW, my own take on this is: Sometimes optional features are a terrible idea. Sometimes they're the right solution to the problem at hand. It depends on the situation. In the specific case of KSP and the options they've chosen, I happen to think it's a good fit.) So, no. I don't think people are disagreeing with you because they're ignorant. I think it's just because they happen to have different priorities than you do. Which, of course, is fine. Different people like different things, is all. People like what they like. You're not wrong to like what you do-- but I hardly think it's your place to claim that anyone who disagrees with you is wrong. Other people have just as much right to what they like as you do. Why not? Seems to me, of course it should. It's a feature, on a commercial product that's trying to sell as many copies as possible. If more people like it, more copies get sold, translating to more profits, which can fuel more improvements. People do vote. With their wallets. And that's what companies listen to, and rightly so. Sure, and I can understand that. If they make design choices that you don't like, you'll be disappointed. Presumably there will be other people, who like similar things to you, who will also be disappointed, because their ideas of "flaky" and "mess" and "half-baked" will coincide with yours. And, of course, there will be still other people who will be happy. Because they will like different things from you, and some feature that you think is a "flaky mess" and "half-baked" is something that they really like a lot, and they're happy that the game has it, and it keeps them interested in the game longer and makes them more willing to shell out the cash for it. And you'll be absolutely right. And so will the people who like the opposite of what you do. FWIW: I'm not trying to claim that every single optional setting in the game is the "right" decision-- obviously not, since how would I know? Neither I nor anyone outside of Squad is in a position to answer how many hours they spent on any one feature, nor are we in any position to have usage data for how popular those features are. All I'm saying is... it's a pretty strong claim to say they're all bad, or that reasonable people can't disagree.

Moving to Gameplay Questions.

Are you doing this for the sheer challenge of it (i.e. "hey, how can I make this harder and therefore more fun")? Or are you trying to make things easier (i.e. "if I slingshot I don't need as much dV and that will make the mission easier")? If it's the former, sounds great. If it's the latter... honestly, as a matter of practicality, I think most folks find it more trouble than it's worth. Going to Duna from LKO only takes about 200 m/s more dV than it takes to go to the Mun. That means that you can save at most 200 m/s of dV by doing a slingshot (because you have to at least reach the Mun)... and in exchange for that, you make the navigation much more challenging. Seems easier just to stick another 200 m/s of dV onto the ship, honestly. But if you're just into it for the challenge, sounds like a great idea!

If you dock two ships together, using docking ports, then you can transfer crew between them with a few mouse clicks-- no EVA is required at all. If you're not docked together, then yeah, going EVA is basically the only way. Kerbals have EVA thrusters that work like RCS, which let them control their flight and fly around. You can toggle it on by pressing the R key, then you can use (by default) W, A, S, D, shift, and ctrl to thrust forward, backward, left, right, up, and down, respectively. Be aware it takes some practice, though-- the EVA thrusters are pretty powerful and you should only use very light taps on the keys to fly around pretty slowly, at least until you've had a chance to practice.

Could you post a screenshot? It's pretty hard to make judgments about things without being able to see how they're arranged. Picture worth a thousand words, and all that.

More efficient at what? They're essentially the same thing, they're just opposite orientations. Asking "which is better, An or Dn" is like asking "which is better, left or right". Can you describe what problem you're trying to solve? i.e. why you're asking the question?

Hello, and welcome to the forums! Moving question to Technical Support. None of the files that ship with KSP are public domain, so it wouldn't be legal for people to share those files with you. Your KSP release should already have all the files it needs. If by any chance your KSP install has become damaged somehow (e.g. if you accidentally deleted the files), then whatever platform you purchased the game from will generally have some mechanism for recovery. For example, if you purchased through Steam, there's a "validate local files" option that will check your local install and re-download any files that may be missing.

More content has been hidden, due to being off topic. Folks, please try to stick to the topic. Arguing is fine. Arguing about arguing is not. Joking about arguing about arguing is off topic and unhelpful. And please note that if you respond to something that gets removed, then your response will end up getting removed, too-- so please don't engage with off-topic posts, either. Thank you for your understanding.

A lot of content has been removed from this thread, due to various rule-violating posts from people who should know better. C'mon, guys, you know better than this. We're all familiar with how things are done, here in the KSP forums, but perhaps a refresher is in order: Address the post, not the poster. Personal remarks are never called for. If you find yourself making a comment about the person themselves, rather than simply addressing the points that they make, then that's either a sign that you're losing the argument, or that you need to take a step back until you cool down, or both. If you find yourself using the word "you" a lot... that's a danger sign. If you're talking about other posters in the third person, that's also a danger sign. If you're actually name-calling, then that's a red flag that you're way over the line. Just don't go there. Either address what the person said-- i.e. the substance of their argument-- or, if you think that's unhelpful, then just stroll on by. Don't tell other people what to do or what not to do. You're not a moderator, it's not your place. If you think someone is behaving so egregiously that they're actually violating the forum rules, then by all means file a report and the moderator team will have a look. Otherwise, it's not your place to issue orders. Don't publicly call for moderator action. It's against the rules. If you think the moderators need to step in, then file a report and we'll have a look-- but don't publicly request action, and don't publicly say that you have filed (or are going to file) a report. That's called "backseat moderating" and is not allowed. And, of course, the most important principle of all-- though not an actual "rule" written down-- is, relax. Remember that opinions differ. Different people like different things. Different people believe different things. Someone else likes or believes something that's very different from what you do-- and they're just as passionately attached to their opinions as you are to yours. The existence of someone who differs from you is not a threat to you. So if you feel like engaging in lively civil debate, by all means go to it, and good luck! But if you're getting overwrought because you can't change someone else's mind, then it's probably best to take a step back and perhaps go elsewhere. If you're not enjoying the conversation, then there's no point in continuing in it. We now return you to the thread already in progress. Please play nice, folks. Thank you for your understanding.

Ah, okay. If that's what you were asking about, then I specifically addressed this in the intro paragraph right before all the Q&A in that same post. So if that's what you were asking, then the answer is "nobody outside of the development studio can know, because it hasn't been announced and the only person I asked wasn't in a position to be able to answer the question because he's not an engineer and isn't involved in those kinds of details."

It's compatible with pretty much everything.

Guys, this is a long and rambling conversation and people are mixing actual observations with wild unfounded speculations with hopes and "well X is what I think is common sense so therefore it must be X" and so forth, so I have no idea what you're asking here, and don't have the time right now to go through and read every single comment in the thread and try to forensically reconstruct the actual question. I haven't had the patience to read through this thread because the title is about FTL and special relativity, and my personal guess (can go into my reasons why for the curious) is that neither one of those things is going to be present in the game at all, which means for me the whole thread is just hopes-and-wishes and not tied to what's actually (IMO) likely to be in the game, which limits the amount of time I'd invest in trying to decode all of this. So, to be clear: When I was at Star Theory, I interviewed (in the sense of "sat down for a scheduled half-hour block of time, so I could grill them by asking questions one-on-one") exactly one guy, and that was Nate Simpson, who was (and still is, after the new-studio announcement) the creative director for KSP 2. I also had a chance to casually chat with quite a few people there, though not in a formal interview setting. This included at least one engineer. Now, what I don't know is what question you're asking me or what the topic is, here, because the thread is rambling and kinda free-ranging. So if anyone would like more of an actual, useful answer out of me, I'd need to hear an actual question. Can someone please pose me a specific, succinct question? Then I'd be happy to give an answer (even if the answer is an authoritative "I don't know, I didn't ask that"), along with my reasons and/or source for that answer. Thanks!

Hello, and welcome to the forum! Very probably the problem is with one of your mods. A couple of things you can do: First, it's worth taking a quick look at your log file-- the chance of solving it this way is probably under 50%, but it's quick and easy, so worth a shot. After exiting KSP: look in your KSP install folder, and find a file called KSP.log. Open it in a text editor (like Notepad), and scroll through it looking for error reports (most likely place to see a relevant problem is towards the end of the file). If there's something that jumps out at you, that might help point the finger at the problem. Assuming that looking at the log file doesn't help (it often doesn't), then basically your only option is to figure out which mod is causing the problem via a process of elimination. Dunno how many mods you're running, but even if it's a lot, using a "binary search" technique works pretty quickly. Basic idea is to try running with only half your mods installed (doesn't matter which half) and then see whether the problem persists. Whether it does or not will tell you which half of your list of mods contains the problem. Okay, once you know the "guilty half", try running with half of that installed, and so forth. Each time you do this, whittle the list down in half, and pretty soon you will have identified the culprit. Once you know which mod is causing the problem, then you can go find the release thread for that mod (in the Add-on Releases subforum here), and ask your question there-- that's where the experts for that mod will be, so it's where you're likely to find an answer to your problem.

Ah, okay. Well, if what you're interested in is the ability to make resource harvesters switchable, then my guess is that it probably wouldn't be too hard for someone to write a mod that would do that... but if so, it would have basically nothing in common with SimpleFuelSwitch other than the word "switch". Resource containers and resource harvesters are handled by different chunks of code and don't really have much in common other than that they both happen to work with resources. So, not something I'd be likely to add to SimpleFuelSwitch-- if I ever needed something like that, I'd probably sooner make a new mod than try to shoehorn it in here. But since I don't generally go in for multi-resource-switching scenarios in my own gameplay, that's not something that's likely to come up for me, so I'll pass that torch on to whomever's interested in taking it up.