Loskene

I... god damnit

When you forget to leave space in the crew cabin for a rescue contract. Looking back on this now, I'm not sure what amuses me more, the Kerbal bouncing around the cargo bay (he survived btw, despite me leaving the doors open the whole time for laughs), or the "just in case we miss the runway" parachutes all over the orbiter.

Aha, I see you're far more trusting of physical timewarp than I am.

Yep, found that one out the hard way too last time I tried anomaly surveyor. Ended up building a plane with a huge wing area and overpowered control authority specifically for landing on mountaintops with not a lot of "runway" space. Though I also had to strike a balance between lift and drag since many of these anomalies are quite a long distance from the KSC, and even a small speed difference makes for quite a change in travel time. We basically need planes that are stable at both supersonic and near-stall speeds. Maybe a non-janky stock swing-wing implementation would be good for this.

I think if (higher ranked) pilots should have any function, seeing as unlike engineers and scientists most of their "real life" functions are things that the player is responsible for in-game (similar to how probe cores' "programming" is just the player telling them what to do), it should be to automate some of the micromanagement and busywork that players will be sick of doing over and over later in their careers. I believe, unlike others here, that is what most people use mechjeb for, rather than as a crutch to compensate for having to learn orbital mechanics. Efficient gravity turns, executing manoeuvres and landings, once you've done them once you can easily do them again, you don't need to "prove yourself" every single time, and they can quickly become more of a chore than a challenge in a late career game with many missions running. Though any functions that can be assigned to pilots can remain optional for those who like to do everything manually. If less skilled players want to use them (or any mechjeb-like functions) as instructional tools to help them learn how to do them manually, they can do that with all the level 5 pilots in sandbox mode before trying it in career. There's no reason something like this can't just be a helpful extra without "ruining" or "cheating" on the base game experience, and refusing that as a concept outright under the old adage of git gud is, frankly, elitist ignorance. I see no reason it can't be something appreciated by noobs and veterans alike for different reasons, without devolving into slippery slope arguments about the game playing itself. Though let's be honest, if the game were full realism, it would play itself, as pilots (aka the player in this scenario) don't do anything but read dials and push the appropriate buttons when ground control says go. Since KSP aims to strike the middle ground between realistic and engaging/fun, some concessions from both sides must always be considered. Full mechjeb in the stock game? Nah, it has a lot of unnecessary functions with respect to the base game, and more granular control than most players will need on the average playthrough. Some of its more useful or basic functions being used to make pilots more than self-loading cargo, particularly if it's a late-game feature to tone down the micromanagement? Sure, why not, doesn't harm anyone. I'd also like some stock implementation of kerbal alarm clock and transfer window planner, since the lack of these are probably half the reason new players never make it as far as Duna, but other than that the stock game as of 1.6 is reasonably well supplied with tools new players might need to get a handle on the basics. Some small additions like those mentioned here would help round out the experience and make it significantly less intimidating for people who've never made it further than the Mun unassisted, without having to go overboard and automate everything.

Because KSP is CPU-bottlenecked due to all the realtime physics abstractions and relatively simple graphical demands, as opposed to most other games (at least ones people often complain won't run on their laptops) which are GPU-bottlenecked. Grand Theft Auto 5 does less complex physics calculations on the fly than KSP, but you won't get that running on a school laptop.

This wasn't exactly today, but I have some slightly old footage of an Energia-Buran launch that I never quite got around to finishing the editing on before moving on to other projects. But no sense letting it go to waste, it's probably 80-90% done and you guys will appreciate it anyway. Sharp eyed viewers will notice I cheated a bit and added some fins to the boosters, but since Kerbin is 1/10th the radius of Earth it requires a more aggressive gravity turn and thus fins on some craft that don't need them IRL. And here is the landing, which I started recording only because the fly-by-wire had decided on suicide the moment beforehand. Sharp eyed viewers again will have noticed I didn't have quite enough delta-v for a suitably low periapsis after hauling up 34 tons to land where I wanted. So I pulled out of a spinning dive to land in the middle of nowhere. In a glider with the aerodynamics of a brick. In the dark. That certainly made things interesting. This one isn't edited at all yet so you'll have to supply your own suitably dramatic music for now.

That's sweet. Love to see something a little different in KSP.

I try to do something a little different every time, otherwise the playthroughs get stale before mid-game. In my fresh 1.6 career for example, my usual procedure for SCANsat mapping the Kerbin system involved 2 launches, a polar launch for Kerbin and an equatorial launch with 2 probes for its moons. This time I decided to test myself a little, and do all 3 in a single launch. Went straight for a polar orbit of Kerbin, then sent the other 2 on an off-plane transfer to the Mun, with one of them braking into orbit and the other using the Mun as a slingshot to correct most of its inclination and boost its orbit towards Minmus. Turned out to be surprisingly easy to achieve, I expected the Minmus transfer to be a pain (since I didn't worry about timing at all) but it only took one dogleg burn at Mun periapsis and a small correction on trans-Minmal orbit. I think this will be my standard operating procedure when I start a new game from now on, saved a lot of time and delta-v!

No wonder I could never find the bloody things, they're in the decouplers section? Bah.

The newest version. I fear no mod updates, 90% of them work fine on patch day anyway, and the few that don't are usually nonessential and quickly brought in line. I do still maintain multiple installs of previous versions though, stock and modded, to preserve save files and transfer crafts.

There are mods on consoles, it's not an unprecedented ask, however if you're expecting anything like how it's done for KSP on PC you will come away disappointed. It will not be free and open sideloading for any mod any rando on the internet made for you in their spare time, it will be whatever gets approved into a console's walled garden that has been tested to not cause problems like, say, bricking your xbox. That's bad for business. Mods, while they can vastly increase the popularity and lifetime (and therefore sales) of a game, are a huge risk and headache for a dev/publisher/platform owner to support. They're not always feasible, and not always worth if it they are. If they decided mods for PC are doable, but mods for console are not worth the hassle, I would not call them hypocritical for it, though I can understand the disappointment.

This isn't Children of a Dead Earth, why are we talking about KSP parts as if they're physically generated from material properties and interaction tables instead of really simple config files.

Raise apoapsis then do a radial-in burn to point periapsis deep into the atmosphere with as much speed as possible. Don't go straight down though, you want it to spend a decent amount of time moving very quickly through the air for maximum destruction prior to lithobraking.

If you bought it from steam it should've downloaded automatically (if you don't have auto updates turned off) and they should be able to handle the refund for you if not. If you bought the game on steam and the DLC from another store, you can download the game files and copy the SquadExpansion folder into Program Files/Steam/steamapps/common/Kerbal Space Program/GameData/ and it should work.

Spot on. One of the worst communities I've ever seen is the forums for Elite Dangerous, and the only correlation I find is the sickeningly PR-laden devspeak (and I do mean it'll make you sick some of the crap they come out with), ignorance of problems, shameless exploitation of their customer base, evasiveness or just straight silence from the devs. Any company choosing that path ends up with a toxic community divided between people (rightfully or not) complaining about bugs/stupid design decisions, penny pinching and radio silence from the powers that be, and the most depressing phenomenon you'll witness on the internet: people white knighting for a company that isn't even paying them for the service, because they spent €1000 on cosmetic DLC and feel obligated to justify their purchase to the point of absurdity. The most outspoken proverbial bootlickers often end up as forum moderators too, which, as you can imagine, only exasperates the toxicity of the forum until everyone who actually wants to enjoy the game has left. You don't know how good we have it here, this place is practically a basket full of kittens in comparison. I hope it doesn't go down the same path, but even post-exodus Squad can't possibly be worse than Frontier.

Re: ring stations. Use empty SRBs or procedural parts as spokes. Structural members need to be made of as few parts as possible to minimise the presence of krakenbait. Autostruts are out too, use real struts as band-aids if you have wobbles, you shouldn't ever need so many that it overinflates your part count. If you have to use autostrutting (it should be avoided in general where not strictly necessary) don't use heaviest part mode on anything that has a docking port. Grandparent is the preferred choice, followed by root. A small number of larger launches is preferable to a large number of smaller launches of modules that all have to dock together. I once launched an entire Deep Space Nine-style station in one go because I couldn't figure out a decent way to bolt it together in space without headaches. You can always add more boosters.

Ah, true. In those scenarios, usually regarding aircraft, I tend to clip the landing gear just to the point where only the doors are showing on the outside, to at least give some hint of a non-magic-based mechanism inside. I appreciate the cormorant shuttle mod adding a thermal tile texture to the stock landing gear to help with this.

Lazy part clipping to handwaive a design problem looks ugly. I generally try to avoid it myself, but the single-part way you design vessels in KSP sometimes mandates clipping for greater realism rather than less. Science parts, doohickeys, avionics and other things that would normally be inside something that otherwise has a lot of empty space in it like crew cabins, but don't warrant an entire service bay to themselves. Done right it can be made to look aesthetically pleasing, a la cupcake's SSTOs, even if those are rather pushing it in terms of realism. I also tend to use small degrees of clipping to make part transitions look nicer, within the realms of the imagined amount of empty volume each part offers.

I had a career game where I decided not to clean up any orbital debris and see what happened first: Kessler cascade or the game refusing to load anymore. It ended up being the latter, as you might have predicted, especially seeing as vessels outside render range are on rails and don't have any collision physics, so nothing can hit anything except the ship you're actively flying. But I did have some notable close calls. Now a bunch of rocks in mid/high equatorial orbits you're not likely to ever hit during an escape burn unless probability decides to play a joke on you, but in a low orbit (70-80km) even a single one can pose a serious hazard to rockets during ascent. At one point I had roughly half a dozen spent rocket bodies flying around this orbit, all within small fractions of a degree of 0 inclination. During one later launch I nearly had a heart attack while preparing for circularisation, as one of them belted past me in the blink of an eye, showing as a HUD element that briefly became a flash of metal streaking by before disappearing back into the distance. I couldn't tell you the exact closest approach, I was on ascent into the same orbit as the debris so the relative velocity was on the order of hundreds rather than thousands of m/s (still way too fast to track when you're not expecting it), but it was definitely less than 2km, I can tell you that much, probably closer. If it had been an asteroid, that launch would have been less close call more difficult letter to write to a Mrs. Kerman. So yeah it's unlikely in general, but this game allows for a number of specific circumstances that'll shift that probability closer to 1 than 0, though you'd really have to do it "accidentally-on-purpose" to see it happen.

If the intercept velocity is high enough there's a decent chance they'd "collide" in between physics steps and simply phase right through each other without registering a hit. This is usually the case for "head-on" collisions in LKO, and it makes testing these scenarios rather difficult at times. If you wanted to ensure a hit at a high velocity but not so high the physics calculations can't keep up, you can have both objects travelling in identical orbits but at a different inclination to one another. Can be hard to get the timing right but you're guaranteed quite the fireworks show at the crossover point, and the impact velocity can be altered by adjusting the relative inclination, so you can find out exactly where the clipping threshold is where the objects are moving too fast to impact each other. 0 relative inclination obviously has a relative velocity of 0, the objects would be in exactly identical orbits and never meet, and 180 degrees relative inc being the prograde-retrograde impact trajectory where, ironically, the objects may never meet either. Although orbital debris strikes of sizeable objects in real life are quite rare, in KSP there are a few factors that make them significantly more common, and I've had a few very close calls myself as proof. Lack of axial tilts and most bodies in the system being on the same plane mean most of your vessels will tend to launch into the same orbital ranges with little deviation from the ecliptic, and Kerbin being so much smaller than Earth there's just a bit less space for everything to get lost in. Still though, unplanned encounters with spent rocket stages and debris in LKO are uncommon, though asteroids obviously present a much bigger target.

I also think it would be best as an advanced tweakables option. It's not meant to give you a broad range of freedom over your CoM placement, it's just for fine tuning it when you already have the arrangement basically how you want it. ie your plane must already be able to fly before you tweak the CoM, this is just to make it fly exactly how you want it to. For these purposes just simulating rearranging the seats in the crew cabin is more than sufficient. Also, it already exists as a mod, as I mentioned earlier.

It's so you can do engine mobility checks during prelaunch. For the hardcore players, you understand. If you want to turn your engines and engine gimballing off at the same time, you can bind them both to the same action group.

As someone who spends more time making tiny tweaks to aircraft to shift the CoM/L over to "aerodynamically stable" from "turns into a pretzel on takeoff" than actually designing or flying the planes, it's a constant pain in my neck I can't just *slightly* tweak the CoM in some parts to get the desired result instead, as I would easily be able to do were I designing a real aircraft. To me, that KSP doesn't simulate rearranging internal components (or just throwing out the passenger seat) to tweak the CoM of the overall craft is more of an oversight than a "would be nice to have" feature. It should at least be applicable to crew capsules, as this was a very important detail in the re-entry profiles of early spacecraft like the aforementioned Apollo command module. The offset centre of mass allowed them to "fly" the capsule during re-entry to adjust their approach and limit G-forces imparted on the crew by rolling the craft, something that we cannot simulate in KSP without mods or clipping ballast inside them, which are 2 things not every player is comfortable with and come with issues of their own. So yeah, +1 from someone who makes planes with FAR, where precision placement of your CoM on the order of centimetres can be the difference between smooth sailing and a RUD at the sound barrier. Edit: Consider this. If being able to move around the CoM of individual parts within a certain range is considered too finicky or "cheaty" for some, then perhaps there's a simpler solution that nearly already exists. One (or probably more) of the Apollo capsules I saw as mods for realism overhaul had a toggle switch option in flight called "Descent mode" or something along those lines. This would shift the capsule's centre of mass to one side a little in order to give it the aerodynamic properties I mentioned above. Very handy. Now what if we implemented this descent mode option to all stock command pods and cockpits and let us configure, with 3 sliders for X, Y and Z, how much the CoM is displaced within a preset maximum range along those axes of the pod? This would pretty much solve all the problems I mentioned above. We'd have a stock method of doing lifting-body re-entry manoeuvres with the basic pods without a mass or launch stability penalty for ballast, and I'd still be able to fine tune the CoM on my planes without rearranging all the wings one millimetre at a time. Think about it, whoever's responsible for these kind of things, I'd appreciate it as a QoL. Edit 2: Yeah this would be real handy right about now

Can we please stop making the "money/indie dev" excuse? It's been years since squad was that small or poor, and they've since been picked up by Take Two, a literal triple-A publisher, after their game became hugely successful. They are neither strapped for cash nor indie by definition, so if whoever's in charge doesn't want to spend the money on a functioning QA department, that's on them. We can have a back and forth about the complexities of game development but we can likewise admit that gamedev as a whole is the worst offender in the field of software development for shoddy practices and cutting corners for the sake of profit, while simultaneously having some of the most forgiving audiences who will overlook or handwaive away obvious self-serving moves that have no benefit to the customer. Squad haven't been the worst offender in taking advantage of the lack of scrutiny that usually afflicts video games, but they're not exactly squeaky clean either. There is only a certain amount of "there's no money in bugfixes" a studio can get away with before the whole thing falls apart under them though, so let's just hope squad know not to push that too far. It would be a shame to see this game driven into the ground out of greed, laziness or simple disorganisation.