Sevio

I had this problem too, the sabres were running both airbreathing and closed cycle modes at the same time, (and producing crazy thrust in the process). I tracked it down to Hotrockets, removing its B9 config file in MP_Nazari solved the problem for me.

Hi Ferram, I noticed your development update to the FAR github and decided to test it out, both with my test plane and the plane that originally had the issue with. Both planes now work entirely as expected (I was able to do the reentry and landing successfully with the spaceplane), so thank you for the fix You probably already know but I figured I'd report it anyway: During a test flight with my spaceplane, I did spot an issue where the FAR in-flight window disappears during flight, couldn't see anything in the log indicating what went wrong though. In any case, happy with the fixed control surfaces, keep up the good work!

Is NEAR support planned for a future update?

I've just downloaded FAR from github master and tested the above plane once more, unfortunately control surfaces are still inverted Curiously, in both versions they're also wrong when you control the plane from the docking port.

Hi Ferram, is there any chance of testing a dev build for a fix with the control surface orientation? In case it may help, I've simplified the steps to produce the bug down to an 11 part plane as shown here: The docking port is the root part facing towards the outside, the rest of the plane is built in reverse, cockpit facing towards the back of the hangar. When it is launched, control starts with the cockpit and the control surfaces start inverted from what they should be.

Ok it's actually fairly simple to reproduce: Start in the SPH with an orange tank, attach a docking port to the back, then build from that docking port a simple plane with canards / elevons and a tailplane, the cockpit should be facing away from the hangar door as should the winglets. Launch, decouple the docking port and you'll get inverted control surfaces.

@ferram4: Thanks for looking into it, if it would help I can try producing a test assembly to try to reproduce the problem on the runway.

The control change may have played a factor but the navball is showing the right orientation. It never showed the wrong one either, I just did "control from here" on the cockpit to make sure. I'm more and more convinced this is a bug related to FAR's handling of the control surfaces, as without FAR they work fine under the same docking & reentry procedure. I've quickloaded and redone the reentry half a dozen times over by now trying different ways of getting the control surfaces to work right. (setting control, going to space center and coming back after undocking, quitting the game and reloading after undocking, etc) From what I could see in the FAR flight data on the previously linked screenshots, it's almost like FAR has the up/down direction of the plane flipped. It's showing negative L/D and Cl. Also there is the glitch where the UI rapidly toggles on and off while the error log is being spammed, which also doesn't happen without FAR. Some additional info about the plane: The fuel tank that I left behind at the station was attached to a surface mounted docking port on the cargo bay, facing backwards and upside down. After undocking that port probably became the root part, maybe this is why FAR interprets control surface input the wrong way? Original description of the problem

I am running .24.2, the spaceplane had a fuel tank in its cargo bay with an upward-facing docking port. I used control from there to dock with the station, then detached the tank from the cargo hold when I wanted to leave. So the docking port I once controlled it from is no longer on the ship on reentry. I've made sure to rightclick the cockpit and choose "control from here" before reentry but it still happens.

Hi ferram, After a long time of sticking with stock's aerodynamics, I've started using FAR in the last few days, after a lot of engineering I've managed to produce a spaceplane that stays stable all the way to orbit, however after docking with a space station and trying to reenter, it will flip out of control below about 40 km no matter what I do. At first I thought it might be because of poor stability with the tanks emptied, then I noticed something odd: all control surface input seems to be inverted when I try to reenter this plane: http://puu.sh/aBDbY/e6292f3371.png http://puu.sh/aBDhJ/454eeb9694.png What's also odd to me is that it's showing a negative L/D and Cl, even though the plane is clearly pitched up in the second picture. I have tried exiting the game and reloading after undocking to see if it would be fixed, but nothing seems to help. Also every time I quickload and undock from the station to deorbit, the UI will start rapidly toggling on and off, which forces me to exit to the space center and come back. When I spawn a new version of the plane, the control surfaces behave as expected, but two different versions of the plane that I sent up both have the same problem when reentering. I have tried to do the deorbit without FAR installed and the control surfaces work fine without it, and there is no ui toggling glitch during the deorbit timewarp. Edit: When the ui glitching happens, the log is spammed with these errors: [Exception]: ArgumentException: Value does not fall within the expected range. Mods in use: Enhanced Navball 1.3.2 FAR 0.14.1.1 Kerbal Alarm Clock 2.7.8.0 Mechjeb 2.3.1.270 Procedural Wings 0.8 Procedural Fairings 3.08 RCS Build Aid 0.4.6 Spaceplane Plus 1.3

Ok, after some digging around and learning a little bit about how PartModules work, it turns out it's already possible to tweak the wing mass, even on a part-by-part basis. Since the mass calculation for the existing pWings is uniform, here's the modulemanager config I used to make them a little bit lighter. @PART[*]:HAS[@MODULE[WingManipulator]] { @MODULE[WingManipulator] { massFudgeNumber = 0.013 // Default: 0.015 } } This reduces the mass of all pWings to ~86.7% of their default mass, stock wing connector and delta wing are now equal in mass compared to a pWing of the same size. Still a bit heavier than the stock swept wing, but you do get a lot of flexibility and scalability for it so I guess that is fair. Another thing you could tweak in the same way is liftFudgeNumber (defaults to 0.0775), but this only affects the lift of the wing without FAR.

Took some decrypting to figure out what you meant by that (Reaching for the Stars), and then scanning to find the latest version of it. While it does have a modulemanager patch for pWings, it has nothing in it that changes the mass. It seems to mod the textures and add "objects" to it, whatever those are.

Do you happen to know which config it is? I scanned through the Realism overhaul configs but couldn't find anything relating to procedural dynamics. From the source file I read, the calculation is completely hardcoded, so maybe the realism overhaul plugin is the one that's doing the tweaking?

Hello DYJ, I've recently started using this mod and am quite liking it so far. After playing around with it a bit, I've unfortunately found an issue and also have a request: The issue is that the mod does not detect the presence of NEAR, causing it to not set the required aerodynamic parameters, so the wing scaling has no effect. I'm using FAR in the meantime for my testing. My request is if you could add some way for us to tweak the mass of the generated wings, the mass calculation seems to be entirely hard coded right now, but the wings seem a bit heavy for their surface area when I compare them with similarly sized stock wings, particularly the stock swept wings really overpower a pWing of similar mass.

For those of you who would like lithium mining to make a little more sense, here is the MM config I used to bring down the time to fill a single canister with a single refinery on Laythe from ~7 hours of real time max timewarp to a matter of a few in-game days. Relative balance of mining speed between Laythe, Kerbin and Eve is unchanged, I just multiplied the abundance by 10000. @OCEANIC_RESOURCE_DEFINITION[EveLithium] { @abundance = 0.00093 } @OCEANIC_RESOURCE_DEFINITION[KerbinLithium] { @abundance = 0.0017 } @OCEANIC_RESOURCE_DEFINITION[LaytheLithium] { @abundance = 0.00237 }