[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Challenger-X2]

Officially anyway, I updated my copy to 0.20, but the license says I can't distribute modified copies. You can use the unofficial patch and place it in the legacy parts folder and it should work fine though. KW has the best fairings.

Also, I can confirm that the GUI clicks through, at least for the button.

Where can one find this unofficial patch?

[Nobody_1707]

http://forum.kerbalspaceprogram.com/showthread.php/30591-20-Compatible-and-Incompatible-incomplete-mods-list-fixes-%285-27-2013%29?highlight=unofficial+patch

There seems to be two of them listed there.

[toadicus]

@ferram

Does 160km count as a low altitude? I'm testing on an i5 laptop with graphics turned all the way down, and still get the stuttering at my LKO station. I even get the stuttering at a KSO satellite. It occurs whether I'm in map view or staging view.

I think it is not as bad at higher altitudes, and higher time warps (>100) seem to suffer slightly less, though the effects wind up being worse (at 100000, I only see the satellite at two points per orbit).

The laptop is fully capable of running the stock game without any performance hits. Let me know if I can help out with anything!

As a follow up: this may not happen in Linux, or it may be less pronounced. I've been playing in Windows to avoid the scroll wheel bug, and it has happened in Windows almost identically on three different machines of varying power (from a mobile i5 to a high-power overclocked i5 to an overclocked Phenom II 955 with a GeForce 560Ti). I had occasion to start up KSP in Linux in spite of the current bugs, and FAR appeared to be working just fine, and timewarps appeared to run smoothly, even in relatively low orbits.

HTH

[zzz]

There nothing, sorry.

Edited May 28, 2013 by zzz

[Camacha]

Okay, I am dealing with a bit of a weird problem and I am not sure where to look. In 0.19 I had some major performance issues with an aircraft of about 350 parts and with a lot of mods. KSP ran at about 8 frames. A bit annoying, but I knew I had lots of mods installed and things like that were to be expected. With 0.20 I decided to see whether FAR had anything to do with this. I installed 0.20 and ran it completely vanilla. I opened the craft and launched. Dispite the thing barely flying I could tell performance was a lot better, around 25-40 fps. After that I installed the mod manager and installed FAR. Sure enough, 8-9 fps. Okay, that is a bit disappointing, but hey, complex calculations are not free.

This is where the weirdness starts. In flight, the number seems to vary between 8 fps and a perfectly playable 25 fps. Without a reason it seems to switch from one to the other with not much in between. This suggest I should be able to play KSP and FAR at a decent frame rate (and I should, considering I am running some proper hardware) but something is acting up. When checking the CPU and GPU load they seem to be at a respective 40% and 50% in both cases, so no problem there.

Any idea whether this is actually related to FAR and what I might do about this?

Edit: it might be that hitting a speed of around 270-280 m/s causes this drop in performance, though I am not sure, since the exact point seems to vary. Slowing down does seem to help though.

What fairings mod do people recommend to go with this?

I am really enjoying Fairing Factory

Edited May 28, 2013 by Camacha

[Doomydoom]

I'm using the Procedural wings + FAR and I have a problem. My aircraft that look like gliders or the Globalflyer or something are performing all around better than anything I make that's actually designed to go super or hypersonic. A design based on a hypersonic waverider glides for less than two minutes from maximum speed down to subsonic. My gigantic winged glider thing glides for 2-3x as long before getting down to subsonic speeds, in addition to achieving higher velocities. I know you say anything will go supersonic if you give it enough thrust, but my bricks are flying better than my Concordes, here.

[ferram4]

@Camacha: That makes sense, since there is more math needed to handle transonic and supersonic flight. There's only so much that can be done though, unless I want to drop the accuracy quite a bit for supersonic flight, but I can look into trying.

@Dommydoom: Noticed it in the Pwings thread; I'll see what I can do to bring the drag performance of the sailplanes down to where they should be at high speeds, but the lift performance they have is about right, even at those speeds. Realistically, they should just fly apart first, but that's extra code to run to do that.

[Doomydoom]

I just got a 90km apoapsis with a sailplane. Also I think you forgot to include the nerfed "TurboRamJet" version of the engines in this latest .20 release. These are giving the stock 180 thrust.

http://i.imgur.com/V2Uw9dB.jpg

[MR4Y]

Would FAR work well with scramjets, using Taverio's scramjet engine?

[camlost]

Would FAR work well with scramjets, using Taverio's scramjet engine?

yes, but those are ramjets, not SCramjets

[Camacha]

@Camacha: That makes sense, since there is more math needed to handle transonic and supersonic flight. There's only so much that can be done though, unless I want to drop the accuracy quite a bit for supersonic flight, but I can look into trying.

I must admit, it is quite a sizable craft consisting of lots of panels and wings. It has been named (quite aptly I think) the whale shark and mainly intended as a proof of concept - so ignore the ugly and nonsensical design. I just tried another version with a pWing and that did seem to mitigate the problem, though there were still a few moments the frame rate dropped to 8 fps. Maybe the large amounts of panels are at fault.

There is some other funky stuff going on with the multi wing version though; earlier the thing rolled like a dream, while in 0.19 and in later tests the craft actually rolls left when the aileron is trying to roll right (probably due to wing flex and other problems) and any turning is done very slowly. Frame rates also seem to be lower, around 25 to 15 fps. There might be something going on with the mod manager there, I will have to investigate.

Another question would be whether FAR will understand craft like this. When you build a transporter like this, will FAR know what is shielded and what not or is that asking a bit too much? At the moment it seems like everything is causing drag, even some panels where the payload would be.

The flying brick did hit mach 1.8 just now

Edited May 29, 2013 by Camacha

[ferram4]

I think that the framerate is more a problem of the huge number of parts and struts than anything else. An alternative is that it has to do with a few situations where I'm using raycasting but that's done by the wings, not the regular parts.

One of the possible reasons for the ailerons not function properly is if they stall partially during the maneuver; if that happens you might end up with your lift dropping when you wouldn't expect it to. Alternatively it could be large scale flexing in the vehicle (there are a lot of joints in that thing that can flex).

And no, FAR won't figure out if stuff in the middle is shielded; trying to identify shielded parts can be really difficult to pull off in a situation like that.

[foamyesque]

@anaximander: Try to design your rocket to be something like an oversized, powered dart: lots of weight at the front, lots of fins at the back. Other suggestions include:

• Keep your TWR lower than 2; this will help keep aerodynamic forces manageable.
  
• Start your gravity turn early and gradually, somewhere around 200m - 2km depending on the acceleration each of your stages is capable of; going straight up until 10km and suddenly yanking it over 30 degrees will end badly.
  
• Keep your orientation within 5 degrees of your surface prograde vector; too much deviation can cause a loss of control.
  
• Build your rocket upwards, not outwards; longer rockets will be more stable than wider rockets as well as suffering less from aerodynamic drag.
  

@SalmonellaDingDong: Make sure that you cleaned out the Plugins folder in the KSP root directory; everything has moved to the GameData folder. You might be accidentally overwriting the new plugin file if you tried to bring FAR v0.9.3.1 over to KSP 0.20.

Y'know, I've actually found going straight up until Q starts dropping is actually a necessity for some rockets. It requires a higher orbit target so you can make a gentler gravity turn, but if you've got really big wings or something that don't respond well to turns at high Q it's actually useful.

[entaran]

I find myself almost always going straight up to 17-20km and then banking SLOWLY over following the prograde vector within 5-8 degrees. Most of my rockets don't survive a mechjeb ascent however I can easily put them into orbit by hand.

That said, vast majority of my rockets are carrying between 15 and 40 tonne payloads into orbit and are more or less lifters. And i'm not that good at design in general so they are probably not very streamlined although I try to nosecone everything. I've found that anything that isn't absolutely hilariously long (like think 5+ orange tanks in length) if you grav turn below 8km it'll just somehow flip completely and head for the ground. That said, it's probably because I am infact the worst person ever and the kerbal universe hates me.

[taniwha]

One thing I've learned recently is that with FAR, not only are the CoM and CoL important, but so is the center of drag. As you get going, the CoL gets swamped by the CoD and if the CoD is in a bad spot, it can really ruin your day (either ahead of your CoM and thus flip you, or behind and rob you of any control authority). Sadly, there's no indicator for the CoD at all, but fortunately, FAR's static analysis can give you hints about it if you sweep AoA out to 90 degrees at various Machs.

[a.g.]

In my modified version of FAR there are some indicators for lift and drag in flight, although they are based on the actual forces at the moment, and Ferram told me it's actually called center of pressure instead of center of lift, or something like that. I don't know if it is even possible to display indicators in flight on top of the craft like in VAB, so they are just crude long lines sticking out of the sides of the craft, and I'm not sure if it is good or useful enough to be included. You can see them in the flameout screenshot I posted a few pages back: http://i.imgur.com/yWFADPz.png

[Taverius]

I don't know if it is even possible to display indicators in flight on top of the craft like in VAB

Unless KSP has some way for you to use the inbuilt meshes and textures used for the indicators, you'd have to load a custom mesh or two yourself and put in the scene. Simple GL lines is certainly easier.

[a.g.]

The bigger problem is how to make them display on top of the craft, i.e. not be obscured by its outside surface when inside it. I have a very faint idea how stuff is rendered in unity, especially the more complex effects like this. For the lines I basically looked how Quantum Struts draws its stuff.

[Camacha]

I think that the framerate is more a problem of the huge number of parts and struts than anything else.

Combined with the increasing number of calculations approaching mach 1 you mean? I guess that makes sense, I will just have to simplify the craft with pWing and bigger (so less) B9-parts. It will probably be the biggest atmospheric craft in my program anyway, intended for transporting an entire base around Kerbin.

One of the possible reasons for the ailerons not function properly is if they stall partially during the maneuver; if that happens you might end up with your lift dropping when you wouldn't expect it to. Alternatively it could be large scale flexing in the vehicle (there are a lot of joints in that thing that can flex).

I do think it has to do with flexing, as the wings are visibly moving around a lot. But I actually meant that the roll behavior seemed to vary from flight to flight. It looks to be a fluke though, as I haven't been able to reproduce this.

And no, FAR won't figure out if stuff in the middle is shielded; trying to identify shielded parts can be really difficult to pull off in a situation like that.

I figured that, with all the panel chaos. I think I will experiment a bit with built in nosecones. It is a dirty hack, but it might help FAR understand my intentions.

[Subcidal]

Hm, It's been a while since I've played KSP, the last being .18.4, So excuse my absence. But FAR seems waaaaay different now.

I just built a plane and I could not for the life of me get it to stop lifting up until i threw my wings quite a ways back behind the center of mass. My center of lift icon doesn't even touch my center of mass icon and it just barely keeps it level. It never use to be like this when building planes, I would always put them (CoL & CoM) fairly close togother else it would be impossible to control the thing.

Is something bugged or have I just been away THAT long that i'm really that rusty? Hell I even modeled it after the Bell X-1 and my flaps on my wings just about touch the horizontal tail when looking at the plane from the top down, It doesn't look like it should fly without it's nose dropping like a brick in a matter of seconds but it's actually the only way to keep the thing level. If you look at pictures of the Bell X-1 the wings are obviously not anywhere near that far back. As far as i remember back in .18 and well... reality itself, planes are designed with the center of lift VERY close to the center of mass, (besides some modern jets) and it no longer seems to apply here. Am I just misinformed or is something a bit goofy going on with FAR ATM?

I just did a test flying the SR-71 included in FAR in my .18 version modded of the game and it flew quite nice. In .20 I can barely get the SR-71 to pull it's nose above the horizion, the whole flight is a constant battle trying to keep the thing from plummiting into the ocean like the worlds most expensive dart. It just doesn't seem right to me.

I can post pictures/upload crafts if you want.

Edited May 30, 2013 by Subcidal

[camlost]

Hm, It's been a while since I've played KSP, the last being .18.4, So excuse my absence. But FAR seems waaaaay different now.

I just built a plane and I could not for the life of me get it to stop lifting up until i threw my wings quite a ways back behind the center of mass. My center of lift icon doesn't even touch my center of mass icon and it just barely keeps it level. It never use to be like this when building planes, I would always put them (CoL & CoM) fairly close togother else it would be impossible to control the thing.

Is something bugged or have I just been away THAT long that i'm really that rusty? Hell I even modeled it after the Bell X-1 and my flaps on my wings just about touch the horizontal tail when looking at the plane from the top down, It doesn't look like it should fly without it's nose dropping like a brick in a matter of seconds but it's actually the only way to keep the thing level. If you look at pictures of the Bell X-1 the wings are obviously not anywhere near that far back. As far as i remember back in .18 and well... reality itself, planes are designed with the center of lift VERY close to the center of mass, (besides some modern jets) and it no longer seems to apply here. Am I just misinformed or is something a bit goofy going on with FAR ATM?

I just did a test flying the SR-71 included in FAR in my .18 version modded of the game and it flew quite nice. In .20 I can barely get the SR-71 to pull it's nose above the horizion, the whole flight is a constant battle trying to keep the thing from plummiting into the ocean like the worlds most expensive dart. It just doesn't seem right to me.

I can post pictures/upload crafts if you want.

FAR doesn't have anything goofy or changed since 0.18.4, pls post .craft

Apparently if the SR-71 keeps diving it's the result of CoL being too far behind. Maybe you are experiencing a bug related to CoL position display. I never have that problem since the last two versions of FAR.

[ferram4]

Post pictures; I updated body lift a bit as well as some of the wing-interaction stuff, so it's possible that some designs aren't exactly right. It's difficult to find a nice, simple graph showing the general trend of lift created by a cylinder at an angle of attack, so currently body lift is the same at all Mach Numbers.

Also, the CoL currently doesn't account for the destabilizing pitching moments of fuselage parts at an angle of attack, which might change things a bit.

[Doomydoom]

I'm trying to make a waverider, and this thing won't stop pitching up uncontrollably. What do? http://i.imgur.com/v4RWGZL.jpg

[seagull42]

Could someone please explain to me what all the simulation data means and what is optimal for rockets/planes? Thanks in advance!

[toadicus]

As a follow up: this may not happen in Linux, or it may be less pronounced. I've been playing in Windows to avoid the scroll wheel bug, and it has happened in Windows almost identically on three different machines of varying power (from a mobile i5 to a high-power overclocked i5 to an overclocked Phenom II 955 with a GeForce 560Ti). I had occasion to start up KSP in Linux in spite of the current bugs, and FAR appeared to be working just fine, and timewarps appeared to run smoothly, even in relatively low orbits.

HTH

@ferram4

I've done some more rigorous testing and I think I've narrowed things down. This looks to be the fault of disk access during flight. I typically play off a thumb drive; it's USB3, but still not the fastest around, and the laptop I often use doesn't have USB3 ports, so I'm sensitive to disk-intensive processes. When FAR is installed, KSP.exe thrashes the disk while timewarping. When FAR is not installed, it only touches the disk when I get to a new craft or planet or something.

To reproduce:

1. Create a new save file.
   
2. Put a part on the launch pad (I used a mk1 command pod)
   
3. Timewarp to 50× or faster.
   

You should see near-constant disk use, which will cause regular pauses on slow disks.

All testing done with 0.20.0, btw.

Just for giggles, I dove into the FAR source looking for the problem, and I think I found it.

In FARControlSys.cs at line 1182, you save settings to FAR.cfg thus:

                        timeSinceSave += TimeWarp.fixedDeltaTime;

                        if (timeSinceSave > 15 || PauseMenu.isOpen)
                        {
                            SaveSettings();
                            timeSinceSave = 0;
                        }

At 1× speed, TimeWarp.fixedDeltaTime = 0.02, so SaveSettings is called every 750 ticks. By 50× it's up to 1, so it happens every 15 ticks. By 1000×, TimeWarp.fixedDeltaTime = 20, so from there on up SaveSettings is called every single tick. For installations on fast hard drives this isn't a problem, but on my little thumb drive, especially over USB 2, the disk just can't keep up.

Guessing that every 750 ticks is more-or-less your intent, I've "fixed" the problem for myself thus:

                        timeSinceSave += 1;

                        if (timeSinceSave > 750 || PauseMenu.isOpen)
                        {
                            SaveSettings();
                            timeSinceSave = 0;
                        }

This way the file is only written every 750 ticks regardless of TimeWarp.

Now, I'm not sure what the cfg file does, or why it's important to write to it quite so often during flights, so it's entirely possible that my "fix" is not actually valid for FAR's proper functionality. It looks to me like the file is only read when the GUI is loaded (so each time you switch to a new ship, I think?), so it doesn't seem like ensuring saves to the file happen consistently in Kerbal time is important. But, I just don't know... but maybe you do?