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.

Any plane change requires burning normal to your orbit plane. The higher you are, the slower you are and thus it takes less dv to get the right inclination but it takes 3 burns unless you are also trying to get to a high orbit anyway. Without doing math it's tough to figure out the most efficient way, but the general approach is to raise your equatorial node (where you cross the equator) nice and high. Next do the plane change at the apoapsis node. For large plane changes it may take a few burns. Finally lower your orbit back to the desired orbit.

I thought Procedural Wings 0.6 had questionable FAR support and was waiting for the next update.

There are 2 big issues that mess up the SAS with FAR: 1: Control lag - SAS is assuming a near-instantaneous response from the control surfaces (stock behavior & how the system reaction wheels & engine gimbals behave) and in FAR both the deflection and its impact take some time (like in real life). Control lag is a classic instability in control theory. 2: Variable control effectiveness - the impact of control surfaces (and the outside forces being corrected for) varies over the flight envelope based on speed, altitude, AOA, etc. The SAS algorithm scales based on a few items (based on how it behaves on rockets) but can't account for the dynamics and isn't robust against having a bad (i.e. poorly understood) plant model. 3: SAS responds poorly to cross-coupling, which all aircraft suffer from to some extent. The most basic example is roll-yaw coupling, where a rolling causes a yaw, or yawing causes a roll. SAS detects and reacts to deviations from the desired attitude and tries to correct all of them and exacerbates the problem. FAR's controls operates on a per-axis basis with tuning for each which helps to suppress coupling. Additionally tools like the pitch and yaw damper don't try to return to a set pitch, instead they try to zero their respective rates. In short, SAS isn't tuned for aircraft unless you are careful in your design (i.e. its fairly stable to begin with) or you get very lucky.

Another Bug report. While using the .7.5 to try to line up a Minimus intercept the editor window goes blank on me. I can still manipulate using the hotkeys, but there's nothing in the draw window.

That will depend on your TWR. If you've got a really high TWR, and thus can get going really, really fast where drag losses become significant. As long as you stay below terminal velocity then keep the throttle maxed (or maxed so you don't overheat). KER's surface info tab has the current terminal velocity available. Ideally, your TWR should be such that you just barely ride the terminal velocity line. Any more and you've got more engine than you need. I use FAR most of the time. FAR's flight data tab provides equivalent information via the dynamic pressure (Q) term. Drag in FAR is (if I've read Ferram's implementation correctly) Q * Cd * A, where A is a reference area an Cd is the drag coefficient which changes with the angle of attack (angle to the airflow). Q is (1/2) * density * velocity^2. For FAR, keeping Q 'low' is equivalent to flying the terminal velocity profile - if I Q gets too big I throttle back until it starts dropping due to altitude and then raise the throttle.

I don't, but I also use FAR so the drag model is both more realistic and more forgiving. I also have self-imposed rules about airflow through structures - i.e. no inlets mounted to fuel tanks. That said, when using B9's 'big' SABRE I will use multiple radial mounted intakes on the engine to get the equivalent performance of putting one of the big SABRE intakes. Also, the only fighters I know with multiple intakes have multiple engines (ex. F-15, F-22, multiple curent gen MiGs) OR have 2 intakes to the single engine for symmetry (ex F-35, F-104) because the single nose intake doesn't work very well.

And we have a winner, thanks Ferram.

@ferram - update works as advertised but I'm getting a significant performance hit in the atmosphere over .22/11 or .23/12.1 Figured you would want to know.

@ferram - FAR was out by the time I was actually able to download .23. I'm not going to complain about a bug or two needing to be squashed. Oh, and that was a quick turn-around - I think I can speak for everyone when I say you are awesome.

B9 is on the dev team, so I'm sure he'll update it soon enough. Glad his priorities have been on the main game rather than the mod. Also, I expect the SABERS will be reworked to use the same code as the stock RAPIER engines - i.e. provide different sizes since the stock one is only available in the 1.25m class.