The Great Potato

: / I'm torn. I like all the features in here, but I also really like Remote Tech! Proper background processing is something I've wanted in RT for a long time. This mod adds it to my relays, but at the cost of...well...everything else in Remote Tech. Time to go rooting through configs, I guess.

The difficulty for mun landing in career is funds and facilities, not max thrust imo. There is far more to mission difficulty in KSP than the max power of your current boosters. Playing career, I don't think I've ever managed to get maneuver nodes before filling out the tech tier where 1.875m would fit most nicely. In fact, I usually already have a handful of 2.5m parts by the time I get nodes (unless I really turn down the science slider). And then I still have to upgrade the VAB before I can make a suitable mun rocket. I also disagree with the sentiment that limiting parts demands creativity. The power gap between sizes 1 and 2 actively teaches the 'MOAR BOOSTERS' dogma to new players - after reaching orbit the first time, contract requirements go up dramatically but you won't get better hardware for another two tech tiers. What are players to do in that situation, other than go hard brute force tactics? Currently, the only kind of problem solving early career mode teaches is how to game the weaknesses within its own simulation. Bridging the gap between sizes 1 and 2 will present more options for rocketry: for the same job, 1.25m is cheaper and lighter but 1.875m is simpler and uses fewer parts. Assuming the existing size 1/2/3 power, weight, and cost ratios hold true for 1.875m, of course. A little more granularity will help players understand and work with size-based engine stats and their tradeoffs, which are a very real engineering concern. Teaching simplified real-world mechanics while encouraging engineering creativity...isn't that what KSP is known for?

@Alshain No mods. Size 3 with a cluster of 5 engines; with 12 struts placed in a truss pattern around the edges, the rocket is slightly more noodle-y than if I used a rhino. Not by much, but enough to give it a noticeable wobble. I didn't really consider unity's physics...KSP itself usually only goes downward, but I imagine physics would constantly be going either direction...okay, you convinced me. I can still hope, though I was gonna bring up the auto-tankbutt on the Vector. I've had my fingers crossed for mounting-less engines since I saw that. Butts won't do anything for the adapters, though...they still need to mount tanks without clipping. How about a stock thrust plate? @Frank_G The stock fairings work great as interstages in a bunch of situations. The main problems are when you want to put a fairing around something with no center node, or when you're packing a payload LEM-style. You have to spend an awful lot of parts so it jettisons properly and doesn't flop around in flight.

I'd say some combination of Vessel ID, part focus, and mission time (adjusted for timewarp, potentially). For vessel switching...perhaps it should bring up the dialog even if you're back in the original vessel. Or maybe switching should reduce the timer on triggering the dialog (from 20 mins MET to 10 mins MET, for instance). There's no way to stop accidental quickloading entirely, but I'd like to error-proof it so losing >30 mins of game time is less likely. At least if you hit F9 and no dialog pops up, you know it's not that far back. You might have to redo a single launch or reentry or landing, but not a whole set of maneuvers or rebuild a craft.

I'm very familiar with the fixes, I do them all the time. And no, the struts are often not quite enough. Even with 10-20 struts between the adapter and the tank, there's a little more flex than if I were to use a skipper or poodle in place of a reliant cluster. A little extra bendiness halfway down the rocket is not optimal, to say the least. 'Spam struts' is always an option, but I don't like it. It's still totally is a hack by my definition, and not because of clipping. Squad specifically disabled radial attachment on engines; those cubic struts are used to circumvent that. But that's splitting hairs - regardless of what I call a hack, I'd prefer a more elegant solution to interstages and clustering. Eh, you're right. It's a very unlikely option, but I wanted to suggest something other than interstage attachment nodes. Squad seems to prefer features that don't involve hanging attachment nodes or fiddly sliders, and I tend to agree. Allowing multiple parents isn't as complicated as you make it sound, though. Squad could stick with the tree model and keep special cases for stack splitters. Or they could change to a graph model, which - assuming the root still can't have a parent - is nearly the same as a tree for downward traversal, subtree removal, and re-rooting. Upward traversal is the real killer, but I can't think of a place where it's used in-game at the moment. Regardless, this requres a change that's deeper than the modding API. Suggesting a mod with this feature would be futile. There are rumors of a v1.2 rocket rework, so recommending such a major change to bi/tri/quad adapters isn't completely out of the question.

Sure, that'd become a habit if the dialogue popped up every time. Not even close to what I'm suggesting. To be clear, I'd want F9 to bring up a confirmation dialog only if it would cause a flight scene change. You know, as a 'stop and think for a second' warning. If anything, the reflex would be to cancel it. I can count on one hand the number of times I've actually needed to load to a different craft. Saving a backup when you quickload might work in some cases. In most others...it would dangle your old data in front of you with no hope of return. Quickloading generally happens when something goes wrong, so returning to that point is often useless. And remember, loading disables the 'revert' button. Better, imo, to figure out a way to prevent the accident in the first place. Back off topic: don't we already have a 'you haven't saved!' dialog for exiting the VAB? I really like the 'go to SPH' idea, though.

Nah, it's fine. There's no real way to make the workaround look pretty. Usually, I use pancakes for the extra fuel and easier fuel line attachment when clipped in. I use this setup a lot, but I have a bunch of problems with it (other than the obvious aesthetic issues): First, Having the decoupler there can cause issues, especially if you move the engines a little further inward. I've had a bunch of launches where the girder/decoupler collides with an engine and goes kablooey. Second, this uses a size 0 to hold up a size 2. You can strut it up, but struts won't give back the rigidity of an actual 2->2 connection. There will always be some degree of flex at that joint. Third, this is a hack. Getting this to work requires a lot of clipping and every part involved is used in a way that's not intended. Most importantly, it completely ignores a series of parts that are actually intended for this purpose - bi/tri/quad adapters. The adapters should be slimmed down so they actually fit under 2.5m tanks. Adapting and un-adapting a stack should also join all the hanging nodes together. In addition, adapters need to be moved waaay down the tech tree (meta-materials? really?). That would at least solve engine clusters. As for payload interstages...I think the fairings could use a toggleable interstage node, but I don't see that happening in stock.

I'm playing stock again for the prerelease. Without utilities like KER, precise node, trajectories, etc I've found myself using quicksave trial and error a lot more. The trial and error is fine with me; I'm more worried about what happens after that flight. Occasionally something goes wrong a mission or two later and I reflexively hammer down on the F9 key without thinking about when I last saved. ...Aaaand boom. I'm in my orbiter from 30 minutes ago instead of in my plane. I think it might be a good idea to add a confirmation dialog to the quickload button if the last save was on a different flight scene. Thoughts?

What about the roles of "lower stage for a size 1 pod" and "payload for a size 2 lifter"? Size 1 is too puny to take even size 1 payloads much further than LKO. However, I don't think they should be buffed - size 1 works well as starting equipment. You start off struggling to even get LKO with them, which is good. Remember when you could get to the mun with 35 science and a handful of funds? I don't want to see that return. In addition, size 2 payloads are often too heavy-duty for the task. Any size 2 payload requires a large-ish and expensive rocket, even if you just want to get more than one Kerbal to orbit and back. Size 2 is the go-to option for a ton of stuff; not because its efficient at those things, but because it is the only choice. As it stands, career mode goes from "struggling to do much more than orbit" to "finished the apollo program" in the space of a single tech tier. The existence of a size 1.5 would filter some of those possibilities down the tech tree.

Kind of a thing. If you try to wrap an interstage around anything with a relatively small diameter, you end up with a really bendy rocket. Modules packed up Apollo LEM style and engine clusters come to mind. You can reinforce the interstage, but it will always be a little noodle-y even with an excessive number of struts. Since I have an obsession with engine clusters, I'd use the living hell out of a stock interstage option. I like the stock fairings better than PFairings - they're way cleaner and less fiddly. It would be nice not to have to install PFairings just to have interstage nodes.

There's a very real need for a size 1.5, especially in career. Aesthetics are a part of this, sure, but you can say the same of any suggestion for parts. Playing stock recently, most of my rockets need something with more power than size 1, but size 2 is complete overkill. Just look at John JACK's math in the second post - that is the best indication of the problem. There's also an uncomfortably large gap in the tech tree between the Reliant and the first Rockomax engine. During that time, the Reliant is it. The most powerful engine in your arsenal can barely lift 15t. Better hope you upgraded the VAB - you're gonna need a lot of parts.

Squad said they're not distributing the pre-release through the patcher because it's not equipped to do so. Steam has built in pre-release functionality and version control, so they went with that. Maybe the launcher is flawed, but would you have preferred Arsonide or RoverDude or somebody work on fixing that instead of one of the new features in 1.1? There's no ill will from Squad - they would if they could but they can't so they don't. 1.1 isn't even all that different from 1.0.5. 1.1 is all about the backbone and UI, not the gameplay. If you don't use mods, 1.1 mostly gets you new wheels and a couple slightly improved visuals (and a healthy number of new bugs). If you do use mods...most of them aren't updated yet so the pre-release will mean nothing to you. I have KSP on steam and my 1.0.5 install is alive and well. I get the initial disappointment - Squad did announce the Steam-only thing a little on the late side. The way people are still so salty about this is strange to me, though. They apologized, it's temporary, it's just the pre-release and not actually 1.1, etc etc.

I use a game controller unless I'm docking or on EVA. Or if I need lots of buttons. Roll is on the bumpers and yaw is on the control stick. That way, I can pilot rockets and aircraft with the same control scheme.

Picked this up again today. After an embarrassing amount of hair-pulling, I found the ScienceSubject and ResearchAndDevelopment classes in the KSP API documentation - they were exactly what I needed! Using GetExperimentSubject and SubmitScienceData, I can convert pretty much whatever I want into both Science and a valid R&D Archives entry. Now I can start building new and more interesting ways to collect science! ...There are still a handful of smaller things I'm unsure about, though. I've been able to work around them, but I'll eventually want to find better solutions: How the heck do you get the vessel's current ExperimentSituations value? This is a complete enigma! I had to reinvent this wheel to get everything else to work. GetExperimentSubject takes a biome ID as a parameter. What if the experiment is non-biome-specific, like flying Mystery Goo?

Now I'm gonna have that soundtrack stuck in my head all day... @KerikBalm You seem angry. Sure, the animations bother me. It's not a matter of realism in this case, it's a matter of looking good. This is all beside the point. The Mk2 crew compartment is unchanged - Mk2 tailsitters can use that as an entrance. Or use it as the cockpit to save weight.