Eric S

Yeah, they're messy to set up in windows, but once they're in place, I haven't had any problems with them. Then again, this is the only thing I've used them for so I'm not using them for stuff that changes.

KSP doesn't model this, an engine running at half throttle will produce the same total thrust given the same amount of fuel as one running at full throttle, it will just take twice as long.

Not at this time. I'm considering doing a powershell script to make this easier to do, but for now, this is about as detailed as I can think of. 1) Have a stock install somewhere 2) Create a folder for your "all mods" install. 3) use the mklink command to symlink everything from the stock install that you don't want shared. So symlinks for every file/folder in your top level KSP directory except for GameData, Parts, Plugins, Resources, Internals, and optionally saves and Screenshots. Make a new folder for each of those that you don't symlink. 4) inside the GameData directory, create a symlink to the Squad directory in your stock install At this point, you should have a functional second stock copy of KSP. I recommend testing it and making sure it's basically functional before proceeding, it's pretty easy to mess up the symlinks when you're doing it manually. Once you're happy with the basic install, go ahead and install every mod that you want to use. Test again. Now that you've got a second install with all the mods you want, you can create a third install with just the mods you want by repeating steps 1-4, and then adding a fifth step. 5) inside the GameData directory, create a simlink to the mod folder inside the "all mods" install for any mod you want for this install. At this time, you've got one real stock install, and by updating that, you're updating all your installs. Further, you've only got one real install of each mod, so by updating the one real mod install, you update any installs that use that mod. The downside of this is it takes more work to set up and to change (adding a new mod to all installs can involve a lot of typing). Which is, of course, why I want to do a powershell script to make things simpler.

I've got a way I do this now (one stock install, one install with all the mods and everything else symlinked to the stock install, and then additional installs that are symlinks to the stock install and the various mods. It works, but it's a hassle. I'd like to see this, with one minor addition. I'd want to see the list of mods that are active/deactive be on a per-save basis, so that I could just pick which save I want and load it instead of trying to remember which set of installs I was using on that save.

Solar Panels and fuel lines. Once I have those, I'll cap science before I need any of the other stuff I've unlocked.

Put a bonnet on a giant scorpion... wait that's the wrong game, in more ways than one. Tried a different tech tree, played it until I reached the point that it didn't feel much different than the stock one, then called it a day.

I've often thought that about myself. Sure, I could make a game that I would love, but most current players would hate, heck even most players in general. That's my feeling on a lot of these suggestions. To be honest, that 's the first thing I thought of when I saw this thread subject. A bunch of people throwing out ideas that they'd love that won't necessarily be targeted at the audience Squad is aiming for.

Orbit vs Flyby is solved with biomes, which are coming to most, if not all, planets. On a typical Munar flyby, I usually get reports from 2 biomes, sometimes as many as 4 biomes. On an orbit, I get 6 easily, and all the way up to 15 if I put effort into it. I'd be fine with some experiments taking more time for slightly more reward, but I don't see a thoroughness bonus for time spent working well. If you're taking more data points, you're just doing multiple experiments, and that's already in place with diminishing returns.

Sounds like you're thinking of doing it the hard way anyway. With the right ModuleManager config, I'm pretty sure you can set it up to assign any part that isn't attached to the tech tree to whatever node you want (the first node, for example), or even override it so that all parts are on the first node, with a few lines in a single file that doesn't change when you update your mods or even add new ones. You might need the wildcard extension for Module Manager, but I'm not certain. They've never actually said that though. They said that the tech tree was organized as to not overload new players. That doesn't make the tech tree, let alone all of career mode, a tutorial. Sandbox is where you play without the limitations of research and budget, and probably a few other limitations. Career mode is quite likely going to be the meat of the game, where the greatest challenge is to be found. That said, I don't see an issue with science gathering in sandbox mode, so I'm not against your suggestion.

The physics calculations wouldn't really change, as there's nothing stopping a 32 bit client from doing 64 bit or 128 bit floating point, and nothing stopping a 64 bit client from doing 32 bit floating point. Goldham's other point is correct, however. It probably wouldn't affect people running stock, but it would give people running the larger parts mods breathing room, assuming that they have at least 6 GB of ram. Since 64 bit clients need 64 bit pointers and KSP uses a lot of pointers, the same number of parts would actually take up more room (the 64-bit Linux client, for example, takes about 30% more memory than the 32 bit client, from what I've read).

To better address the actual questions, here's the type of ship I usually use for my first trip to Duna. If you've gone far enough into the tech tree to get fuel lines, the folding solar panels, and ladders, you probably have all the parts you need, and you can probably fudge the folding solar panels. NOTE: Those those that find asparagus staging offensive should skip this. Basically, the mission profile goes something like this: The six asparagus boosters all get dropped before the craft reaches orbit, but the center stack still has over half it's delta-v remaining. The center stack handles the transfer burn to Duna with plenty to spare. At Duna, I do an aerobrake pass that leaves me with an apoapsis at about the height of Ike. If I got lucky and have an intercept with Ike, I fine tune the intercept and circularize using the transfer stage. Otherwise, I raise the periapsis out of Duna's atmosphere and wait for Ike to be in the right place for an intercept that doesn't require a large adjustment. Finally, I'm in orbit around Ike and still have some of the central stack left, so I use the central stack to start my deorbit burn. This way, the central stack impacts Ike and I minimize my debris. I wind up landing using the first pair of drop tanks on the lander. They've got fuel lines run so that the first pair empty, then the second pair empty, and then it uses the center stack fuel tank which is the smallest. The landing gear are attached to the second pair of drop tanks, though I could probably move them to the first pair so that they drop sooner, since I usually land on Duna before I use up all the fuel from the first pair of drop tanks. Anyway, after landing at Ike, I take off, and put myself in a return trajectory that's far enough into Duna's atmosphere that aerobraking will ensure that I land rather than skip off for another orbit, but not so far that I won't have adequate time for the parachutes to slow me down. The Duna landing is handled mostly by parachute. With the right periapsis, the craft has no problems with going to fast when the chutes fully deploy, and two radial chutes bring that craft down at a rate of 15-20 m/s, so a short burst of thrust just before touchdown drops the landing speed to under 5 m/s. Takeoff is straight forward, the OP Rockomax 48-7s would have a TWR of 1.39 even if that lander was completely topped off with fuel, though the first set of drop tanks usually get dropped in the ascent. The second set of drop tanks usually get dropped while I'm doing the transfer burn to get back to Kerbin (the only bit of debris that doesn't either impact something or burn up on reentry). Arriving back at Kerbin, I aerobrake and land/splash down. Now, all of this is with a craft that tops out at 9.6 km/s of delta-v, not that much more than I'd use to go to the Mun and back. In fact, this is only a slightly refined version of a craft that originally went to the Mun where the intent was to have enough delta-v in the lander to be able to do a few suborbital hops and hit a few extra biomes. You'll see a lot of aerobraking in this mission description. If I had to guess, I'd say that this craft could make it without aerobraking, but there wouldn't be any delta-v reserved for "oops" situations. So I guess the lesson to be learned is to learn aerobraking, it can really be your friend on a Duna round trip.

EDIT: Oops, never mind, wrong thread.

They're in control of a lot of things were they decided to go with solutions that favor gameplay over realism (scaling of the planets at the top of the list). Yes, they could increase torque, decrease the power a probe core takes, give probe cores more power, or let you start with batteries, but all of that would affect the later game play balance as well. Really, if you're the kind of person that is bothered by starting with manned missions instead of unmanned ones, there's probably enough other things wrong with the tech tree that you'll probably replace it with a modded one anyway, and you're not the kind of player that needs to get attached to the kerbals to enjoy the game. Odds are, you're also probably technically competent enough and motivated enough to install a mod to do this. On the other hand, with starting off with manned missions, they simplify the initial game play and get the player attached to kerbals early on for those players that aren't bothered by this, which is probably more of their core audience.

I tend to go to Duna as soon as I have ladders and fuel lines, but not before then, so usually about my third mission, fourth if I decide to go to Eve first, though I usually do Duna first. I have gone there as my first mission, but I just find it more hassle than it's worth that early.

Hasn't been mentioned recently, and the devs have even gone back and forth on whether or not they want to do it at all. I think the last mention I heard of it was as an optional setting.

We have this now. Because we don't have N-body physics and no atmospheric drag above 70km, orbits don't drift or decay. You're thinking of Lagrange points as the solution to a problem we don't have. Park a satellite 60 degrees ahead/behind the Mun in an orbit that matches the Mun including the orbital period, and it will stay there until the end of time, which is more than you can say for something dropped into EML4 or EML5 in reality. I'll admit that exactly matching the Mun's orbital period could be easier, but even if you're off by 10 seconds, it would take 6 years for the satellite to drift back into the Mun's SoI. If you were asking for a way to do very precise burns so that you could more easily match the desired orbital period, I'd agree and endorse the goal. To be honest, I don't think the Kerbin-Mun Lagrange points would be stable enough to use, since there's Minmus adding to the mix. Then again, without running it in a simulator, I can't say for certain that Minmus would interfere enough. As for this only working in time-warp (I think you mean on rails, which isn't exactly the same thing), I find that even more bothersome.

Heat shields are hardly the only way to have to react to reentry heat. Given that the heat is less than you'd see in reality, heat shields could be overkill. The solution could be as simple as making sure that any heat-sensitive parts are occluded by parts that aren't as heat sensitive. I seriously doubt that the lander cans are going to have the heat tolerance of the capsules once heat is an issue, so you might have to avoid using lander cans on craft that will be reentering, or at least make sure that the lander can stays occluded. Other solutions could be "just don't aerobrake at high velocity and low altitudes, take more than one orbit to slow down." It's quite possible that we may wind up in a position of having multiple ways of dealing with reentry heat, and as long as we pick one of them, we're good. For what it's worth, I've played with Deadly Reentry, including the versions that were actually deadly back when the heat was higher than the physics would suggest. I'm not saying that we shouldn't have to deal with reentry heat, just that that's not the only way to have to deal with it, and I'll wait until I see what the devs are thinking before saying something has to be done a certain way.

The devs have said that they're not planning on having reentry heat something you'd need a heat shield for. After all, we're reentering at a third the velocity of real life reentries. They said that they wanted it to be something you had to keep in mind, but not something that required extra parts. As a side note, very little of reentry heat comes from friction, most of it comes from the compression that the atmosphere in front of the craft undergoes.

Aside from the dirty feeling of a "magic" solution, you've got some unintended consequences going on if anyone wants to try to dock with this craft that is now not following the physics of the game. They can be in normal physics, which means that they are going to diverge from the target's trajectory, or they're locked into the magic orbit, which means that they can't maneuver to dock with the target.

You're not as likely to notice Lagrange points as you think you are. Lagrange points in reality are more stable orbits precisely because of the issues that N-Body physics bring to having stable orbits. So what's really being said is "We want N-body physics so we can get Lagrange points to solve the problems of N-body physics." Even with the EML4/EML5 "stable" Lagrange points, you're talking orbits that are stable only for millions of years, instead of orbits that are stable forever that you get in KSP. Of the five L-points in any given pair of bodies, three are inherently unstable in one axis, and the other two (and one of the first three) are in a position barely distinguishable from placing something in the same orbit as the smaller of the bodies farther ahead or behind in a patched conics system, unless the two bodies are closer in size than normal (Duna/Ike, for example), at which point the Lagrange points would be even less stable. Even the two stable points aren't as trivially accessible as you'd expect. We've found all of one asteroid caught in the SEL4/SEL5 points to date. Dust in space isn't any more common in EML4/EML5 than elsewhere, so getting captured there isn't trivial either. Of the two L-points that can't be approximated easily in a patched conics system, the main use for them is for solar observations in the case of SEL1, and stellar observations for SEL2. SEL1 makes for a nice place for solar observations because the earth never occludes the sun there and it's far enough from the earth to minimize interference from earth without being so far away to make communication difficult. SEL2 is used for stellar observations because the earth permanently occludes the sun, reducing the interference of said sun when trying to see dim items very far away. On the other hand, because the points are unstable in a full N-body system, most missions that go there are of a duration of a few years at most due to the instability of those L-points meaning that they need to do frequent station keeping. The Halo orbits people talk about using in the unstable Sun/Earth or Sun/Kerbin L-points aren't really a stable orbit, just the orbit that required the fewest course corrections. One other thing we'd get with N-body physics would be the Interplanetary Transport Network. As nice as it would be to have, I think that this wouldn't be remotely accessible to the majority of KSP players. None of this even considers the fact that N-body physics for more than three bodies doesn't work "on rails" (in fact, it only works for three bodies if the orbit of the middle body is circular) but just as physics warp, which would break large amounts of KSP. TLDR: N-body physics, or even simplified 3/4 body physics, would eliminate anything really being "on rails" for a reward that the majority of KSP players would find difficult to take advantage of. Yes, the geek side of me wants Lagrange points, but the realist says that we don't need them, we really are saying "We want N-body physics so we can get Lagrange points to solve the problems of N-body physics."

Agreed, and I was supporting what you were saying, though I didn't make that clear. Something like this suggestion doesn't fit in well with scaling difficulty unless you come up with a reason for it not to be an issue in Kerbin orbit.

Which is why the Mun is in a zero-inclination orbit, but Minmus has a non-zero inclination. This pattern repeats itself when you start playing around with planetary transfers. Duna, which is probably the first interplanetary destination of most new players is once again minimally inclined and almost the least elliptical orbit of any interplanetary destination, beaten only by Eve. The planets farthest away from Kerbin, Moho and Eeloo, are both more inclined and in more of an elliptical orbit than any other planets within the system. If you're trying to challenge an experienced player who's trying to get to the Mun under the same circumstances as a new player, the new player isn't going to stand a chance. Hence, when you can, you put the challenges meant for more experienced players somewhere where the inexperienced player is less likely to trip over them.

Agreed, every time I look at my list of save files, I have to remember "that 12 current missions doesn't mean I'm doing a lot there that I'm not finished with, it just means I left flags all over where I did do things."

I think Squad has plans for making space stations relevant to science without doing science over time, which they've spoken out against because timewarp makes time a bit pointless for something like this.

Look into the RemoteTech addon. Two of the three main branches of it have communication delays due to lightspeed, and the third may be getting that in the future, if I recall correctly.