Sean Mirrsen

KSP was never about generally valid physics, especially not to the level of general relativity and quantum mechanics. It began as a game about orbital mechanics, first and foremost. When you get to quantum mechanics, adding a plausible and generally valid FTL travel system is merely a matter of adding a Minovsky Particle. Not literally, but as a trope. We know little enough of the veracity of our knowledge in the fringe physics disciplines that a single, well-defined element can be used to facilitate a lot of the things we cannot accomplish in conventional physics. And above all else, you should remember that game design maxim. "When a choice has to be made between realism and fun, fun must prevail." And its corollary - "A huge crime against physics is better than a small crime against gameplay." Slower-than-light travel is more likely to break the game, and for more people, than faster-than-light travel. It is worth overruling known physics to keep the core game running smoothly.

Currently there is no random failure mechanics that we know of, so it's safe to say that any and all random failures are completely emergent. They occur due to design quirks, low margins of error, and unfavorable alignment of planets, pretty much like in real life. So... half and half. Half bug (in that it's unintended), half feature (in that it kind of simulates IRL behavior).

Well, there's already that hole the size of... roughly the universe, considering it's space-compressed. Bahaha... "space decompression drive"... like the warp drive, but instead of doing the push-and-pull, it just decompressed the space behind itself. Pretty much a booster rocket powered by space itself. Jeb would approve. Anyways. The thing about FTL is that it's... eh, "sort of" unconventional. By which I mean it more or less goes against everything physicists stand for (which just goes to show how little they actually stand for, but I digress). In turn, this "being unconventional" brings with itself a curious property of not being linked in any way to conventional progress. So STL travel is to FTL travel like the Burj Dubai is to a Japanese tapdancing robot - both are achievements in engineering, but areas of engineering so different that there are fewer links between them than between humans and cuttlefish, and either could be built without all or most developments required by the other. In other words, FTL development isn't going to wait for STL travel to develop to any given point. It can happen at any time, exactly because we don't understand half the physics involved in its workings. I'm not saying it should come early, IRL or in-game, but making the assumption that we'd have superadvanced STL drives before we have FTL drives is foolish. No offense. ((P.S.: Unrelatedly, it seems the scientific community is lately becoming its own barrier to progress. At this rate, the first person to discover FTL travel will rather flee into the stars rather than make his discovery known, for fear of being burned at the stake. >_> ))

Well of course you can. But you'll do it exactly how you were doing it in the first place - as in, you'll actually watch your delta-V budget, you'll time burns and slingshot around planets - i.e. do the things that make KSP what it is. With a delta-V budget that could as well be limitless, those maneuvers would be simply boring.

I'm not talking about Kerbin, or the Sol system. I'm talking about everywhere else. Sure, you may have had a challenge developing your interstellar STL drive, and you may have a challenge building enough of it to go anywhere. But you can build it, and go anywhere. Once you're in a different system, with the kind of power and efficiency that interstellar flight necessitates, you will just relocate your carrier into position around whichever planet you need, and you will do it again and again because the delta-V requirements for interplanetary transfers are nothing compared to those of interstellar flight - even if your tanks are empty, you'd be able to Grand Tour any planetary system on fumes. The interstellar travel system of KSP, once/if one does become necessary, must be simultaneously flexible enough to make smart design matter, and restrictive enough to disallow its use for anything but interstellar travel or extreme cases of in-system translocations, not to mention sane enough in regards to logistics that interstellar travel is not limited to elite players with massive amounts of free time and/or Alienware gaming rigs. Going to a different star must be a challenge, but not a challenge to end all challenges. The fun of KSP will die if the challenge of exploration is taken out of it. And I'm not using that mantra. My expression is a corollary to it and its derivative. If any sufficiently advanced technology is indistinguishable from magic, and any technology that's distinguishable from magic is insufficiently advanced, then any technology, no matter how primitive, will be magic to those who don't understand it enough to distinguish it from such. http://freefall.purrsia.com/ff300/fv00255.gif

Refer back to my first post here. Any drive system for STL travel between stars is bound to be so efficient as to break the challenge of interplanetary transfers. I would rather have a "magic" FTL drive, if it lets me keep the exploration of the new starsystems challenging.Besides, in most cases the real problem is spending time accelerating, not waiting. Oh, and toss the "magic is just technology we do not yet understand" thing into the pile too.

I personally already expressed my preference for an FTL drive for KSP. While my all-time favorite drive system is the Linear Displacement System from Edge of Chaos, KSP seems like it would most benefit from a variant of the Kearny-Fuchida jumpdrive, from the Battletech franchise. KF drives are large, rare, require slow recharges using solar power, only function outside of any significant gravity wells, and can jump several times in sequence if enough fuel cells are provided. They won't break in-system travel, they will favor large interstellar carriers, and they even already begin with the letter K. They're a perfect match!

KSP is SteamPlay. "Buy once, play on Windows, Linux, and Mac." their slogan goes, I believe.I don't think I ever saw any game that sold for different platforms separately on Steam.

STL interstellar travel will break the regular interplanetary travel. Any conventional drivesystem powerful and efficient enough to make a journey between the stars possible will make travel between planets trivial. Making traveling between the stars a challenge is not worth killing the challenge of planetary exploration.

Whether or not buying on Steam gives Squad less money in the long run is still up for debate in this case. What with the money saved on bandwidth, and not even taking the extra money from Steam exposure into account. Of course, if you bought it during a sale or something you would give less money. On the other hand, if you really want to give them more money, you can just buy more of the game - again, on Steam, where it's much easier.

Not being sure if a platform will still be around in 10 years is no reason to not buy a game for the platform now, you gotta admit. Especially a game not really dependent on said platform. I've posted this in other threads like this, and I'll say it again. I see absolutely no reason not to use Steam for a game like KSP. It is not tied to DRM, will never have achievements, can be modified and copied anywhere at will, and you get easy on-time updates without hassle, and without pulling bandwidth from Squad's server. Plus Steam allows you to give more money to the developer if you want - just buy a bundle of game copies as gifts and give them out to friends, or just raffle them off. It's a win-win for everyone, with no drawbacks to be seen.

Eh, by the time I'm 50km from the target I'm usually already on an intersection course, or an orbit planned far enough ahead to intersect at a later point. The times when I need to do an orbital correction burn from within 50km to the target (instead of a direct approach) are so few and far between that I'd be far more inconvenienced by the lack of auto-switch. Skin-of-your-pants barely-outside-atmosphere orbital approaches are far from the norm, you usually have at least 10 to 20Km breathing room. But, hey, that's just me and my way of playing.

I saw/read several posts like these, and I always get the mental image of that customer from NotAlwaysRight in my mind, who is shouting "but you should have known I meant 'small' when I said 'large'!"There are reasons for SAS behaving in a given way. One of these reasons is that SAS has no way of telling where you want it to point - only what the input levels are telling it. Since input in KSP is a virtual stick, SAS has to wait until the input level returns to zero, which might take a sizeable fraction of a second, especially in fine controls mode. I know that SAS does have bugs, as any computer program is prone to, and the resulting behavior does indeed require fixing. The key, in my mind, is remembering that it is, after all, just a computer program. It has its own way of working, and it can only respond to what you're doing. Reading your intentions is beyond its capability - don't expect it to. (not meant to be directed at the OP specifically, just something I've noticed across some similar complaints)

If that decision was made to prevent me from plowing into the rear of the car in front of me, then I would welcome it. I really have nothing against the automation, but probably because I see the logic behind it and see that it matches my own. The navball switches to target mode when you a) have a target and are close enough to the target to want to do target-relative maneuvers. It will stay in target mode as long as you have a target and are within range of it, and will return to orbit mode when either of those conditions are not met. As long as it functions in this intended way, the automated navball switching does exactly what I need it to. It's less of a brake/accelerator control, and more of an automatic transmission. You might want it to stay in second, but unless the designer saw fit to add the option, you're out of luck. I say again, I wouldn't be opposed to an option being added to keep it manual. Just that I wouldn't use it. I'm fine with the automated system as-is.

Most games that have the replay feature optimize by not really recording everything. A lot of the time, they use precise and/or simple enough mechanics that all they need to capture is player input. In other cases - a majority of other cases - the recorded data is either simplified to reduce game-time load, or is not all that abundant to begin with. A prime example is FlatOut 2 - thousands of physics objects on the map, deforming cars, but you can see in the replays that only the motion of the cars and the initial states of the objects are captured, with everything recreated dynamically from that. It's good enough most of the time, but you do see lapses when cars hit things that were, but aren't there - or don't hit things that weren't, but are. IL-2 Sturmovik is also an example of "recreationist" replays, being generally accurate enough to recreate an encounter with nothing but inputs. It's not really an option for KSP, neither of those. Every parameter of every single part has to be followed, because every part matters. So the limiting factor for KSP would be performance. And even besides that. I hope I don't sound offensive when I say this, but in my opinion, KSP is not a casual enough game for action replays to be considered an important feature. It's a possible feature, and a possibly useful one - but far from "basic", "essential", or even "important".

They don't. Like I said, I never noticed the behavior you're describing. All controls are relative to the navball. Even if you change SOI, the navball will change to reflect the new frame of reference, but the center mark will still point forward, and all controls will function the same. Even if you change the control point to a docking port perpendicular to your actual heading, the controls will work relative to the navball.Can you provide an example? Because I'm honestly not seeing it. I've flown many different ships into orbit, using nothing but the map screen and the navball after the last booster stage is detached. Closest thing to a "change" is how your prograde marker jumps sideways to reflect your actual orbital velocity, when the navball switches to orbital mode.

If you mean relative to the camera, then of course they do. Look at the ship from the side, and what was pitch will look like roll. All that changes between Free and Orbital camera modes is that Free is oriented to the surface plane, while Orbital is oriented to the orbital plane. And by the way, you can always prevent that by manually changing to Free mode. By default, the camera is on Auto.

Controls are always relative to the navball, so it's perfectly feasible. I never saw controls change due to camera mode switching. Worst case, you're switching camera and navball modes at the same time, but you can still tell which mode you're in when looking at the navball. It's a lot worse when your control point changes after docking maneuvers. A lot worse. It's something you can never spot on the navball itself until you correlate with what you're seeing your rocket do. Also no, I wouldn't turn off automatic navball mode switching if such an option were presented. As-is, I am more annoyed by when it fails to automatically switch. Target mode only appears when you have a target selected, and clearing it is as easy as double-clicking on empty space in the viewport. Surface mode automatically switches to orbit mode when you're high enough for orbit to be possible, and switches back when you're more likely to be interested in surface-relative velocity. If you would rather have to manually switch modes every time you begin and end a target approach, why do you not manually check that you're in the right mode when you do the same now?

It's far worse when you undock a control node, and the resulting craft ends up oriented hell knows where, without much indication. My eyes are usually glued enough to the navball during docking approach that I always spot the switch - especially considering that the current velocity changes drastically. I've had more missions failed due to odd choices for the current control point than due to navball mode switching to "target" or back. I don't even remember how many of the former I had, but any number is greater than zero.

Not going to help an actual rocket, mind. Shifting center of gravity and such.

My favorite, and by far the one I see most fitting to the Kerbalverse, is the Kearny-Fuchida Jumpdrive, from the Battletech franchise. Appropriately limited by the lack of certain features in the Kerbalverse. Let's see. 1) Jumping distance is 30 LY, and is near-instantaneous. 2) Jumping requires a slow recharge over the course of a week, via solar power. 2a) Charge is applied to giant battery cells, of which several can be charged, and later used in sequence - providing the ship can carry them all. 3) Jumping is only possible to and from gravitational L-Points, or the polar Zenith and Nadir points of a planetary system, a certain (large) distance from the star. 3a) Kerbalverse lacks L-Points. Meaning that the drive is limited to Zenith and Nadir points, requiring a polar orbit. So we have a large, power-dependent drive system that needs a slow recharge between uses, can only be used for inter-system travel (or jumping between the Zenith and Nadir of the same star if you want), and requires establishing a polar orbit around the Sun with a certain apoapsis to use. This means a single big carrier craft - a JumpShip - with a number of smaller ships docked to it to perform the actual exploration and work. Operation requires good design, skill in docking and ability to establish a difficult orbit. In other words, it's a perfect test of KSP aptitude. The carrier doesn't even necessarily have to be heavy on the parts - the only important ones are the jumpdrive, the fuel cell, and the array of several large solar panels to keep it recharging. The rest is just typical fuel and nuclear engines. The amount of Delta-V to get a polar orbit might be pretty large though, so if that's actually too difficult to be practical at all, I suppose changing it to be "just very far away from the Sun" should be good enough.

Well, not exactly. I was actually writing it somewhat differently, and it did occur to me that you could boost it (therefore I left out the inevitability of it burning up) But all you give yourself is time. Presumably you still have to bring it back in somehow, even from a stable orbit.More importantly, you want to bring it back in. Y'know, alien tech and such. Which is why I mentioned dismantling. You could just try to save whoever's in there, too, but, again, same issue. You don't know if the thing would just explode if you took a cutter to it in the wrong place, and you don't want to accidentally damage anything.

It's not a question of "practical". There may be a situation where you need to reduce or remove the reentry heat. For instance, imagine that for some reason you suddenly need to deorbit and return home a space object not intended to be equipped with a heatshield. For whichever reason, coming up with a modular heat shield container large enough for it is impossible, or can't be done quickly enough. I mean, let's take an extreme example. A small alien spacecraft had FTL-traveled into our solar system, and entered a decaying orbit around Earth, where it seems to have gotten stuck, and sent out what seems to be a distress signal. It is imperative that this craft be brought planetside, as carefully and softly as possible. A heatshield might be too risky, as it's impossible to tell if the craft will be able to handle the stress of reentry even with one. Dismantling it in orbit is not a good option either. The craziest way, tremendously impractical normally, is to slow it down as much as possible and gently ease it into the atmosphere. The question thus is: would it really be the least stressful way to do such an operation, and what would it actually take?

I believe the answerer failed to actually answer the question. As KSP has shown, getting enough fuel into orbit is not an issue with enough determination. But WHAT IF a rocket slowed its orbital speed to non-existence before reentering? Drop the plausibility, and focus on the answer. Would it still need a heat shield?

Well, I did land this thing. It only took, like, two tries.