Sevio

I don't agree that the Round8 was redundant with the Oscar-b. With that logic you might as well remove all FL-T* tanks except the FL-T100, since they're all multiples of it. As well as all Rockomax tanks except the X8. (forgot the exact name, 800 units of LFO) My small probes with an ant engine get at least a Round8 and an Oscar-b to get a decent amount of delta-v. A small probe with a single Oscar-b is on the low side in delta-v, but an FL-T100 is overkill and looks bad. There definitely needs to be more than one tank option for the 0.675m parts. If you're going to repurpose the Round8 for Xenon because its looks aren't consistent with other LFO tanks, new LFO tanks for the 0.675m diameter are needed. From a gameplay perspective, if ion drives are to power larger craft than probes, please also consider a larger version of the ion engine along with the needed power generation options to prevent the need to cluster the small ones excessively.

Squad mentioned earlier they reworked things so they could know the exact time at which a ship changed SoI, so that warping across a boundary at high speed no longer resulted in your orbit predictions being way off. Being able to do the same for water impacts was probably a nice secondary result of this change.

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?