DMagic

This is very true. It's always nice, even if it's just a "thanks for this" or "that was great" kind of thing (it doesn't hurt that it bumps your thread up, too). Though I'm probably guilty of not doing that enough on others' threads, I should try to change that. To be fair though, some of the longer 'writing' posts can be a little daunting if you don't want to spend much time reading on the forums.

I won't fill up the page with gifs that I've posted in my missions thread, but I've got a few others I can put here. I spend way too much time on my launch systems...

Because there have been legitimate complaints about the way SAS works. The pre-0.21 definitely had problems and needed to go. But the 0.21 version had many issues of its own. The handling of unbalanced crafts is much improved in 0.22, and I think worth the change.

I understand this philosophy; there are good reasons to not use Engineer/MJ, but there are also good reasons for why not to overload users with information in the stock game. Though I think career mode presents a good opportunity to introduce this kind of info in a more reasonable way. One piece of information that I do wish were made more readily available is the craft mass. You can get it from the map, but it would be nice to be able to see this somehow in the VAB. Basically everything you need to know can be calculated from the information readily available (amount of fuel, thrust, ISP), total mass is the only missing component (and adding up 200 parts is no fun). Another issue that I have with Engineer/MJ is that they force you (or at least guide you) into the design standards that they can deal with. For instance, RCS powered landers are completely feasible and in many cases very useful, but those mods just give you a blank stare when you try to incorporate them. Or take the case of a standard Apollo style lander/orbiter. It's hard to find out the available deltaV at each stage because the lander ends up much lighter when it returns to dock with the orbiter. There are ways around some of these limitations, but I usually resort to calculating by hand when I make designs like this. And that's not something that a lot of people will want to do when they have the tools that can work with different designs.

Oh I fully agree. Before 0.21 I almost never used the stock ASAS system; I got to the point where it was difficult to launch manually because I relied on MJ so much. The new SAS system has been a huge improvement. The changes made for how RCS is more efficiently and effectively used in docking are amazing; that alone will probably save new players an enormous amount of pain in learning how to dock. And while the whole system isn't perfect (as I've discussed in my tutorial), the updates made for 0.22 improve it even more. I think many of the problems arise because people want to continue using their old designs (which is not to say that there aren't legitimate complaints to be made). The problem with this is that those old designs were built around the specific limits and capabilities of the old SAS/ASAS system. Everything about KSP is a moving target, so I expect to have to change my designs whenever updates are released.

I'm going to have to resist the urge to spam this thread with pictures. I've been building a lot of SRB powered launchers specifically because I think they look awesome. I'll just add a few from my latest Eeloo mission.

Spaceship Awesome; it wasn't awesome, it was actually kind of terrible. But the next two or three Spaceship Awesomes were a little better.

That's kind of my point. Even though you only apply manual input on the yaw axis, the pitch and roll axes can still drift. It isn't as if the system dampens the yaw axis and locks the pitch and roll axes, it seems to dampen all three after briefly dropping all non-manual axes to zero control. I might be wrong on this, it might still try to lock on the other axes, but it isn't as effective as it is when the whole system is in locking mode. And yeah, like earth said, control on any axis can cause changes in the other axes, regardless of what SAS is doing.

Very nice and thorough. You might have mentioned it, but I find that maneuver node mods can really help here (MJ, maneuver node improvement, or anything else that gives you fine control over nodes). Because such small changes in your approach to the secondary body can have a huge effect on your resulting orbit it helps to be able to make very fine adjustments when setting up your maneuver nodes. I never had any success when trying to use Eve to get to Moho, but I've recently used Jool twice when getting to Eeloo. With a little patience you can easily shave off 500m/s or so, and as you said, if you really get it right you can save over 1000m/s.

I found out how to setup Catalyst Control Center to switch between landscape and portrait with hotkeys. Now I just need a way to get KSP to switch resolutions on the fly (the in-game settings panel won't work for putting it in portrait mode). I have an Ergotron MX mounting arm, which is a bit expensive, but it's heavy duty and can hold up my Dell 2709w with ease (this is an old fluorescent backlit, 16:10, 27" monitor, which is a lot heavier than the new LED versions), it looks nice too. It's very easy to switch between landscape and portrait. I found that putting it at 1195*1650 works pretty well (1200*1650 doesn't seem to work in windowed mode); it's still very tall, but wide enough so that map mode works a bit better. You can see how it cuts off some of the space center, but you can rotate the view; it works great for my unbalanced SAS tester rocket. And here's the standard mode.

I updated my SAS tutorial with new info from 0.22. http://forum.kerbalspaceprogram.com/threads/41941-New-SAS-functionality-and-You%21-0-22-Update I think there are a few things that should be mentioned. That "steady drift" that happened in 0.21 with unbalanced loads (where your heading would drift a few degrees upon throttling up before locking in place) seems to have been greatly improved now. Fairly unbalanced loads will stay on course and use the available control authority to keep it that way. Whenever you enter damping mode (the two spinning arrows icon) all controls are brought to zero for a moment. This means that if SAS is using the pitch and yaw controls to maintain heading and you try to roll, the system will zero out the pitch and yaw axes. Control resumes after a second, but that brief interval when the other control axes drop to zero can be enough to throw you off course (and sometimes manual control will be needed to bring you out of damping mode). The two spinning arrows indicates damping mode, not just manual override, which is slightly different that what is implied in the release notes. If you start spinning out of control the system will get stuck in damping mode and the icon will remain on the two spinning arrows even if you don't provide any manual input. This is really good advice. With careful manual control and use of the F key you can prevent most of those oscillations. This can get really tricky with an unbalanced or very unstable rocket, but those are design problems, not SAS problems.

It is definitely possible to match your target planet's inclination by changing your inclination in LKO. It's more complex than just looking at the planet's inclination though. If you wait until Kerbin and the target planet are at a node then you can do the transfer burn at a high inclination to match, or nearly match the planet's. I've done this many times for Moho, but it requires careful timing and tweaking of your inclination to get right. It's also not very feasible if you are already in orbit; you have to set this up properly at launch time.

It's the way that oceans are rendered. They are a separate planet that is combined with the solid ground, causing huge slow downs with weaker GPUs. The only real way to get around this is to keep the ground/horizon out view, alter the settings.cfg file, or stay more than 160km above Kerbin. Obviously it's difficult to always keep the ground out of view (and kind of aggravating), and 160km is pretty high up. The settings.cfg change can usually help, but it's not always enough. The settings.cfg changes are detailed here, if anyone is interested: http://forum.kerbalspaceprogram.com/threads/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21

“Ok Bill, now that we’ve checked out Eeloo can we get on a rocket and go there?†said an overeager Jeb. “Not so fast, we still don’t know what’s on the surface of that planet. It could be ice, ammonia, kethane, or maybe, you know, some illicit substance; we can’t have you getting all coked up on some distant planet, now can we? First we need to collect some samples and bring them back here, we’ll get some of the recruits to snort it and see what happens.†“If we have to. So if my first rocket was 280 tons, does that mean this one will have to be 560 tons? That’s how rockets work right†sulked Jeb. “Uh, maybe you should leave this one to Bob, he’s better at this kind of stuff; thinking, and math and so on†After lots of dismissive and snide comments about Jeb’s terrible designs Bob agreed to help create the Eeloo sample return probe. “I’ll make your probe†Bob grumbled, “but let’s get one thing straight, the proper way to get a rocket onto the pad is not with some lumbering crawler; you gather up a kurdle of Kerbals (ED: kurdle being the proper name for a group of ten or more Kerbals) and march them out there with the rocket strapped on their backs. I guess some people didn’t pay attention in their pre-school rocket design courses.†After lots of mathing and scienceing Bob came up with a working sample return probe. Jeb immediately tried to pass of the design as his own, scribbling over Bob’s notes. Before we get to the launch we’ll take a look at some of the launch crew and infrastructure. To capture footage of the launch we have several spotter crews surrounding the pad with cameras and lights. There are a few other light trucks and spotters monitoring the pad. And now we have the launch from the spotter crew’s perspective. Here we see it from the onboard camera. This rocket is made up of about 95 parts and weighs only 40 tons on the launch pad. It delivers a 3.5 ton craft into LKO on a stage-and-a-half design (or maybe a stage-and-two-thirds) using two sets of SRBs and a liquid fueled main engine. The craft, known as the High efficiency Eeloo Return Probe (HERP) is brought to you using the RLA Stockalike part set from hoojiwana, with a few parts from Infernal Robotics, Procedural Fairings and Engineer. Once in orbit the booster is separated and de-orbited. The probe craft prepares for a long journey by deploying its communications arrays and RTG power source. Its antennas are sufficient for short and medium length communications, but for long distance comms it will rely on the Discovery Eeloo Relay Probe (DERP) already in orbit around Eeloo from the last mission. For the transit to Jool for a gravity assist I’ll make two burns. The mini-NERVA has very low thrust (6.5kN), so this multi-burn approach is necessary for an efficient transfer maneuver. The radial tanks provide almost enough fuel for the Jool burn; the rest will be carried out with fuel from the main tanks. And here is the mission plan for the intercept with Eeloo. If you look carefully you can see the price to be paid for such efficiency, over ten years to an Eeloo encounter. It’s worth it though, as it saves well over 1000m/s of delta-V. After a very long trip (as in, turn on max time-warp and go find something else to do for 20 minutes) the HERP arrives at Eeloo. Here we get our first close-up view of the sample probe as it separates from the orbiter. This is an all RCS powered craft; on top are four mini RCS blocks providing just 0.25kN each, and on the bottom is an inline RCS engine providing 5kN for the landing. There are several vacuum-exposed sample containers connected by the yellow sluice tubes as well as some internal storage compartments. A sample drill is present on the reverse side; we’ll get a closer look at that later. The landing legs are special micro-version of the regular mini-legs. These weigh only 5kg, but break at around only 3-4m/s (compared to the bigger 15kg versions that break at 10m/s). There is no power source, only a single battery pack keeps the probe alive during the descent, sample gathering and return. The RCS engine fires to de-orbit the probe, which comes in for a nice, soft landing. Now we can get a close-up of my retractable Diggatron unit in action. It drills and recovers several samples to be returned to Kerbin for snorting, er, for study, that is. With just under 40L of mono-propellant remaining the tiny return probe blasts off from the surface. The probe prepares a rendezvous with the orbiter and approaches for docking. The battery is down to less than 25% charge, but there is still plenty of RCS fuel, which should help with the final journey home. Holy coming in under budget Jebediah! Look at that, only 1200m/s to get back home, and in just over one year. Sure, the angle is a bit steep, but that’s nothing to worry about, I am just crashing into the surface after all. After one last year in space the probe finally approaches home again. Here it speeds towards Kerbin at a steep angle for a landing just north of the KSC during the predawn hours. The return probe separates from the rocket one last time in the darkness above Kerbin. As the rocket burns up, the lander sheds a considerable amount of excess velocity, approaching Kerbin at over 6000m/s. Once the probe has safely reentered the atmosphere it deploys its parachute, allowing it to smoothly coast down to the surface. The Mün rises overhead as the probe safely drifts to the ground, waiting to be picked up the next morning. That marks the end of another successful mission to Eeloo. There is still much work to do, but Jeb, Bill and Bob are one step closer to a manned mission to the distant planet. Stay tuned for more. I played through the last half of this mission with my monitor in portrait mode, which you can see in the gifs, and most of the screenshots are uncropped. It's an interesting way of playing, map mode takes some getting used to, but it still works fine. I made a thread about this in the general forum, too.

Then don't update. In my opinion keeping parts around just to maintain backwards compatibility is a terrible idea. Maybe the legs should be strengthened, but if so it should be because it improves their function, not because it rescues our old saves.

Thanks, stay tuned for part two of Discovery Eeloo, I'm just finishing up with the mission.

This sounds like it might be a bug that may or may not be related to SAS. I've seen this kind of thing happen sitting on the launchpad with SAS turned off. The craft just start shaking and shaking until it falls apart. It could be due to some kind of part clipping problem, or maybe some other bug, but it's definitely not the usual wobbliness that can happen on unstable designs. It's hard to say if this the same thing happening to you without seeing it, but that could be the issue. One way to check is just to launch the same thing multiple times. When the shaking bug hits me I've found that it only happens some of the time; just saving and reloading is enough to fix it sometimes.

It's a little early to worry about (or be asking about) that, but in general you should probably expect every update to be save breaking. Even if it isn't explicitly 'save-breaking' like 0.21 was, there are always hundreds of unpredictable ways that an update can screw up your crafts or save file.

Because I'm using a mount arm my monitor doesn't automatically switch between landscape and portrait layout. I need to setup a hot-key for that since it can be a little awkward. But for now I just rotate it to portrait for KSP and then back for everything else. It's a 27" monitor, which makes it a bit too high for regular use for me. I'll get some pics later today or tomorrow.

Here's an example from the next part of my Eeloo mission using very small crafts. These are uncropped screenshots stuck together in PS. You can see how map view can be a little cramped, but I was able to rendezvous for docking pretty easily. It takes some getting used to, but I think I like it. I play in a 1050*1680 window on a 1920*1200 monitor, so I can make the window wider. 1200*1680 might give me a little more room on the sides.

That could make for some interesting designs. It's sort of reminiscent of how old spy satellites worked; they had a set of film canisters that they would drop one at a time to be recovered (mid-air by an airplane with a hook!). And yes, you will have to switch to watch them descend. Anything below ~25000m will get deleted if you aren't actively watching it. Also, derbies may be a typo, but I think something in KSP should be called that, it just seems fitting.

See my SAS tutorial: http://forum.kerbalspaceprogram.com/threads/41941-New-SAS-functionality-and-You%21-0-22-Update. The new system is fundamentally pretty similar to that used in 0.21.

I was just thinking the exact same thing. The extreme setup would be three screens. One for map, one for the main view and one for IVA.

With the changes in the 0.21.1 update the Inline Advanced Stabilizer became essentially useless, it's just a heavier version of the inline reaction wheel. 0.22 did nothing to change this, but it did repurpose the nose cone to be used as a science part. Something similar should be done for the IAS. It could be used as an extra sample/experiment holder, a different, non-goo experiment, or something else entirely. Anything would be an improvement over it's current state, which seems to exist only for backwards compatibility.

Well, the old SAS part, the gray wheel now called the inline reaction wheel is definitely not obsolete, it has a very useful purpose. And the large ASAS module could use a name change and some tweaking, but it's ok too. The only obsolete part is the old 1.25m ASAS part, now called the inline advanced stabilizer. And I just had an idea. That part could easily be repurposed as another inline science part, just like the nose cone. Maybe some kind of sample storage container, or experiment holder, so that multiple experiments could be stored without adding more of the bigger science modules. It makes more sense than it's current, useless state.