longhornchris

@ferram4 I can confirm this fixes the issue I was having with the Mk1 cockpit. Aircraft behaves like it did in the previous version.

Good point. I'll go pull a log file when I get a chance but I reverted to 0.15.6.3 and the problem went away. I'll have to re-install the update to get the behavior back. If it helps, it doesn't matter what craft I use - if I have the Mk1 cockpit i get this behavior.

Ferram, I love FAR - can't play without it. I wanted to report a possible bug. I just upgraded to 0.15.6.4 and now my spaceplane using the Mk1 cockpit (basic 1-kerbal cockpit) have huge yawing problems. The aircraft worked fine in the previous version. I activated the 'aerovis' arrows and the cause appears to be huge lift being generated whenever there is any sideslip in yaw.. Strangely, this only impacts yaw, not pitch. Its acting like there's a huge 'vertical' wing in place of the nosecone. Note: I haven't checked the other cockpits to see if this is related to the Mk1 or all leading nosecones.

While the average smart phone is more than capable of doing the math and IO necessary to operate the entire Apollo mission (including the Saturn V launch sequence which had its own computer in the IMU ring) - you would need some sort of IO card to hook in all the sensors, but there's an excess of CPU power. For reference, the Curiosity rover uses a RAD750 (http://en.wikipedia.org/wiki/RAD750), though technically it has 2 with one as a backup. The RAD750 is based on the PowerPC750 that was used in Macs back in the late 90s and generally runs slower (clock speed) than the PPC chips that were common back in the day. Now, if you are asking yourself 'Why would NASA use such an antiquated computer?' the reason is the RAD750 is rad-hard. Your smartphone isn't. Due to the nature of making radiation hard electronics (physics, engineering, and cost) the RAD750 is the current 'state of the art' even though it is 15-20 years behind current terrestrial computers. Put another way the RAD750 can do ~400MIPS, the latest Intel i7 can do ~125,000MIPS (or ~125BIPS). An ARM A7 (reasonable smartphone processor) can do 2850MIPS. While MIPS aren't the end-all in CPU metrics, they are a decent comparison given the vastly different architectures. So, while the ARM based computer in your smartphone can run circles around the computer in Curiosity, radiation upsets would cause hell with the processing do to bit flips... and there's a high likelihood of radiation induced latch-ups that will destroy the processor elements.

@sarbian - not sure when you added it, but I really like the that the maneuver editor now has the 'execute node' button. Thanks

@sarbian - love mechjeb for a whole lot of reasons. I do have a suggestion - can you add the 'execute next node' to the maneuver node editor along with the maneuver planner. I like to use the maneuver node editor to tune my maneuvers but its annoying to need to have the other window open to execute a node once I've got it.

I've found 2/3 before, 1/3 after tends to work best for me for burns over 20 sec - so for a 30 second burn start at T-20. I also tend to throttle down when I get to around 5 sec left in the burn so I can steer the craft to stay on the node. For larger burns, I generally need a small correction burn anyway. Once you drop a node onto the system the dV (direction and magnitude) are based on what it takes to get you onto that new orbit, so it does adjust if you miss the node.

Anytime I have weird behavior with mechjeb its caused by my 'control from' direction not being set relative to my engines. Usually this is because I was docking and was steering relative to the docking port. For the autoland system mechjeb wants to end up pointed 'nose' up and assumes the net thrust vector is pointed down. If your engines are at an off angle or your COM is off center the autopilot will get confused.

KSP is a 32bit executable, so it can only access 3.2Gb of memory. The only benefit to KSP of having a 64bit OS is that KSP can have a full 32bit memory allocation while a running a 32bit OS limits the entire system to the 32bit allocation. So you do get more ram available, but not much.

SAS works just fine with my rockets when using FAR... not so much with my spaceplanes. Then again, I also make my rockets look like rockets and use procedural fairings on almost everything as soon as I an unlock them. I also make sure I have plenty of control authority, reaction wheels and aero-surfaces, to keep the pointy end up and the flaming end down. Finally, I make very gradual direction changes during my ascent.

true enough, but it doesn't look as cool

Everybody knows on a ship that size you have 2 centrifuges to counteract the stored angular momentum... Duhh. Very nice work. While I don't play with a life support mod I do try to keep kerbal comfort in mind, and these are perfect for that.

I recommend adding the crew manifest mod which allows you to add kerbals while on the launch pad and move them around your vessel. Adding Kerbals on the pad is nice in the event you forget to setup your crew in the VAB. Because a docked ship is 'one' vessel it also allows you to move kerbals around without having to go EVA, which is how it should be for space stations. It also means you can do station launches without having to send kebals up in the lab module.

If you have to drop the fuel with the mainsail it may be better overall to disable the mainsail, burn using only the LV-Ns, and ditch the engine and tanks once you've expended the fuel. Using the mainsail is a waste as its ISP isn't as good and you don't need the thrust

Mechjeb can either launch you into the same plane (phase and right ascension), which is great for intercepting something in an inclined orbit, or proper phase for intercept if your target is in a low inclination orbit. Matching orbital plane (inclination & RAAN) is more important, especially if your target is at high inclination and it doesn't require a test launch to get the launch phase angle for the booster. From there a Hohmann transfer will get you the rest of the way there. You can save a little dv if you launch to a lower orbit than the target so you can wait for the phase alignment. As a reference, matching the orbit plane is usually (but not always) the key part in defining a launch window because in-plane is easy and cross-plane is very expensive.