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

[Wanderfound]

Need some help with FAR, just trying it for the first time. Are there good resources to help get a sense of what to look at and how to build to minimize issues? I got over my penchant for building rockets with giant bulbs on top rather quickly. Currently however I'm struggling with re-entry. Pods are coming in just fine but when I try to get anything more complex to the surface I'm running into a lot of stability issues. For instance, trying to land a pod with a science jr attached to it. It always flips over and goes pod first, tossing a chute from the top of the pod or even sides of the science jr rips my craft apart. How can I make my re-entry more stable with FAR?

Whatever you build is going to want to rotate to put CoL behind CoM. Mass at the front, drag at the back; think about feathers and arrows. Not a problem on the way up, just put some fins on the tail...but then, come reentry, you want it to fly backwards...

There are a few ways around it.

1) Reenter with a bare capsule. That's what they're for. There is no need to return goo pods or Science Jr's to the surface; go EVA, collect their data, and store it all in the capsule.

2) Spend ages fiddling around to get a design that is aerodynamically stable both ways, and strut it enough so that it can cope with the pressure and g-forces. Usually not worth the bother.

3) Come back down the same way you came up, spaceplane style. Streamline your nose, and have enough control authority and lift on the reentry vehicle that you have full control of your altitude. Use the lift to control your descent as you slow, and don't drop deploy parachutes until you've slowed enough to survive the deployment shock (i.e. < 300 m/s). Use struts etc to reinforce the structure of the parachute mounting points, and consider deploying chutes in stages to ease the impact and provide failure redundancy.

Edited November 21, 2014 by Wanderfound

[Wanderfound]

Small feature request:

The max deflection on spoilers and flaps can be negative, which is good: it allows you to set opposed spoilers as airbrakes.

But the maximum negative is only -30, while max positive is 50 or so. This means that you can't do maximum-strength airbrakes unless you do the lower half as flaps instead of spoilers, which consumes two action groups and complicates deployment.

Could we get the maximum negative deflection stretched to the same as maximum positive?

[Hodo]

Is there any chance that we get 64 bits compatibility again? i use several parts mod and i just cant use 32 bits, with the loading times of KSP and the crashes that the 32 bits version gives me i am always forced to use 64 bits.

How many parts mods are you running?

I have somewhere in the area of 2 dozen mods on my KSP install and I am running 32bit fine. I just use ATM basic and OpenGL, this keeps my RAM use down to about 2.7GB.

[Frederf]

Is it possible to just turn the part upside down so that "negative is up" and "positive is down"?

[BudgetHedgehog]

How many parts mods are you running?

I have somewhere in the area of 2 dozen mods on my KSP install and I am running 32bit fine. I just use ATM basic and OpenGL, this keeps my RAM use down to about 2.7GB.

32bits and I think I'm reaching the limit. Still doesn't go above 3Gb though (or not that I've noticed. ATM and OpenGL are wizards.

Is it possible to just turn the part upside down so that "negative is up" and "positive is down"?

Course it is. Won't make a difference if it's a simple cylinder like the materials bay or a fuel tank though (unless you have some CoM offsetting going on). It's a cylinder - a symmetric shape that has the same profile both ways.

EDIT: I may have misunderstood who Frederf (now there's a name for KSP) was addressing or what part they meant.

Edited November 21, 2014 by ObsessedWithKSP

[Wanderfound]

Is it possible to just turn the part upside down so that "negative is up" and "positive is down"?

No, control surfaces look at their alignment and adjust, e.g. forward surfaces deflecting opposite to rear. As mentioned, you can hack around it with flap/spoiler combos, but it's a nuisance.

[Dr. Death]

I can tell you right now the answer is no, but you can find 64-bit enabled builds here. Of course, don't expect any support if when you get 64-bit related crashes.

But a more reliable solution to the memory limits of 32 bit would either to use Active Texture Management or DDS Loader and convert all your textures to DDS. The DDSLoader approach has the added bonus of significantly cutting down loading times.

Used the texture management, game crashed before i saw any difference. I also tried the Open GL mode. The graphical difference was a big problem when trying to read textures in cockpit and the game had a lot of compatibility issues.

How many parts mods are you running?

I have somewhere in the area of 2 dozen mods on my KSP install and I am running 32bit fine. I just use ATM basic and OpenGL, this keeps my RAM use down to about 2.7GB.

How many mods its not really important. What's really important its that i AM using quite a few parts mod, wich are the most RAM intensive (KW, FS, KAX, IR, KAS, B9, Retrofuture, etc.)

I find quite annoying the lack of mod compatibility for 64 bits. With the game taking so much time to load up with mods, crashes become more frustrant, and being my nº1 case of crashing the lack of ram, i find 64bits to be without doubt what should be the future of KSP.

[Rebelgamer]

Future or not, its still a buggy mess. I've tried it, both with and without mods, too unpredictable.

[ferram4]

@Dr. Death: There is absolutely nothing modders can do to provide 64-bit compatibility; since C# is a managed language, the code is the same on our end regardless of the system. You may have noticed that Linux 64 bit is supported and has never had any problems with mods in the > year that it has been out. It is only win64 that has any issues.

Now, since the code that I create doesn't change with word size, that raises the question of what needs to change and where the behavior could be different. Well, there are two options: the KSP devs could be using unmanaged code somewhere, and the Unity devs certainly use unmanaged code in the internals of the engine. Since they are the ones with the code that is word-size dependent, go bother them, not me. I cannot fix code that I don't have access to. It is people like you, who insist that I go and do the impossible and insist on ignoring any information about how mods actually behave in KSP that are the reason why I added the special code needed to shut down my mods for win64.

I wish that win64 weren't such a crashy mess, but the problem is that when people like you fill up my support thread with requests for me to fix issues that aren't even my fault, it buries legitimate issues and makes me really wonder why the hell I even bother to provide support in the first place.

[blowfish]

Used the texture management, game crashed before i saw any difference. I also tried the Open GL mode. The graphical difference was a big problem when trying to read textures in cockpit and the game had a lot of compatibility issues.

Okay, have you tried DDSifying everything or using an unofficial Win64 enabled FAR build?

[Hodo]

Used the texture management, game crashed before i saw any difference. I also tried the Open GL mode. The graphical difference was a big problem when trying to read textures in cockpit and the game had a lot of compatibility issues.

How many mods its not really important. What's really important its that i AM using quite a few parts mod, wich are the most RAM intensive (KW, FS, KAX, IR, KAS, B9, Retrofuture, etc.)

I find quite annoying the lack of mod compatibility for 64 bits. With the game taking so much time to load up with mods, crashes become more frustrant, and being my nº1 case of crashing the lack of ram, i find 64bits to be without doubt what should be the future of KSP.

Well looks like you have an issue that doesn't look like it can be fixed by anyone on these forums. Good luck with that.

[DaMichel]

There is absolutely nothing modders can do to provide 64-bit compatibility; since C# is a managed language, the code is the same on our end regardless of the system. You may have noticed that Linux 64 bit is supported and has never had any problems with mods in the > year that it has been out. It is only win64 that has any issues.

Now, since the code that I create doesn't change with word size, that raises the question of what needs to change and where the behavior could be different. Well, there are two options: the KSP devs could be using unmanaged code somewhere, and the Unity devs certainly use unmanaged code in the internals of the engine. Since they are the ones with the code that is word-size dependent, go bother them, not me. I cannot fix code that I don't have access to.

To be fair, this issue isn't explained a whole lot. I suppose without prior knowledge of C# one might be inclined to think that modders are somehow "too lazy" to write x64 compatible code. If it was my plugin i would likely put the above text as disclaimer in spoiler tags right below the first heading. If you did this you could at least refer to it without having to write the same stuff over and over. If you are lucky somebody will even read it

On a totally different topic. I love the recent contributions to FAR. Yesterday i spent several hours playing with the new control surface settings. Also thanks for finishing the work on the gui which i was too lazy to do. I am ashamed of myself. I didn't think it was really necessary either, but this is certainly nicer!

Edited November 21, 2014 by DaMichel

[Zidane]

The next version will have the parameters set using a dropdown for planet, along with altitude as inputs. Setting the flight configuration and deciding the flight conditions is still up to you. After all, I can't actually expect what circumstances your plane will be in; you're the designer, you'll have to make those calls. So it'll be easier to select conditions that make sense, but it's still going to leave you to decide whether it's sane to reach 15 km at 300 m/s.

I already done that, with a propeller plane. I learned two things, first propeller planes don't go over mach 1 (they actually don't reach mach 1) and second, while they might climb to 15-18 km, they tend to nosedive down to 10 km as soon as they go over 15km. I bet you know why that happens. I have no clue, but I know what I can and can't do now xD

[Van Disaster]

Q: has the handling ( code-wise ) of control surfaces changed much in the current github version vs release? some previously stable craft seem considerably less stable longditudinally, I'm wondering if my double-stacked spoilers are being processed differently, it's all I can think of at the moment.

[Dr. Death]

@Dr. Death: There is absolutely nothing modders can do to provide 64-bit compatibility; since C# is a managed language, the code is the same on our end regardless of the system. You may have noticed that Linux 64 bit is supported and has never had any problems with mods in the > year that it has been out. It is only win64 that has any issues.

Now, since the code that I create doesn't change with word size, that raises the question of what needs to change and where the behavior could be different. Well, there are two options: the KSP devs could be using unmanaged code somewhere, and the Unity devs certainly use unmanaged code in the internals of the engine. Since they are the ones with the code that is word-size dependent, go bother them, not me. I cannot fix code that I don't have access to. It is people like you, who insist that I go and do the impossible and insist on ignoring any information about how mods actually behave in KSP that are the reason why I added the special code needed to shut down my mods for win64.

I wish that win64 weren't such a crashy mess, but the problem is that when people like you fill up my support thread with requests for me to fix issues that aren't even my fault, it buries legitimate issues and makes me really wonder why the hell I even bother to provide support in the first place.

I am not blaming you about problems. If you say that you wont provide support for the 64 bits then i will happily wont give you feedback from it. The problem is just that you disabled the mod on the 64 bits version.

[Jovus]

I'm having some problems designing a light cargo lifter spaceplane. Specifically, around 20-25km it noses up uncontrollably until it stalls out and dies, every time. Can I get some help/advice fixing this? I'm obviously doing something wrong, but I've been carefully following the work of successful spaceplane designers, so I'm not sure where my mistake is.

Javascript is disabled. View full album

[MAKC]

I'm having some problems designing a light cargo lifter spaceplane.

Center of mass problem. In the graph it shows that as you pitch up, the CoM moves further forward relative to the CoL, which will decrease pitch stability even more, like a positive feedback loop. It's a really tricky one to solve because it usually involves having to redesign your entire craft, the location of fuel tanks and how the fuel tanks drain. Adding cargo into that equation makes it even harder. Good luck.

[Jovus]

I see. Wouldn't the CoM shifting forward relative to the CoL increase stability, though? Or is there something I'm missing? Also, this happens well before I lose anything like a significant amount of fuel (using jets only), so I don't really see how the CoM could be shifting much on the airframe.

(I realize I'm probably misunderstanding you.)

Edited November 21, 2014 by Jovus

[Gfurst]

I already done that, with a propeller plane. I learned two things, first propeller planes don't go over mach 1 (they actually don't reach mach 1) and second, while they might climb to 15-18 km, they tend to nosedive down to 10 km as soon as they go over 15km. I bet you know why that happens. I have no clue, but I know what I can and can't do now xD

May I ask you first, which are the prob engines you're using? FireSpitter? I would liek to try me some front engines too.

To answer your (non-existing) question, when you reach higher altitudes, air gets thinner and thinner, having less air density requires a greater air speed to maintain same lift. Its a natural trade-off.

However most engines tend to lose power going higher, jets will flame-out due to less oxygen. But this is specially more important on propeller engines, propellers works as airfoils, little wings rotating, as such their power depends on air density(less density less lift). Though, I'm sure prob engines don't work as such on KSP, they are simulated by loosing power with height.

I'm having some problems designing a light cargo lifter spaceplane. Specifically, around 20-25km it noses up uncontrollably until it stalls out and dies, every time. Can I get some help/advice fixing this? I'm obviously doing something wrong, but I've been carefully following the work of successful spaceplane designers, so I'm not sure where my mistake is.

25km and up is around the edges of space, very low air density (read above). The edge between controllable atmosphere and non controllable is a weird place where aerodynamics don't always work as we think.

Around that altitude and above wing don't provide as much lift, and control surfaces specially will barely provide any control, so be ready to switch to SAS units and RCS, this will greatly help you to control your craft.

As for pitch up spin, I bet its the air-intake causing it, for reason they provide an weird drag when going out of air, be ready to close all intakes and shutdown air engines (action group key). Hope this helps.

[tetryds]

I'm having some problems designing a light cargo lifter spaceplane. Specifically, around 20-25km it noses up uncontrollably until it stalls out and dies, every time. Can I get some help/advice fixing this? I'm obviously doing something wrong, but I've been carefully following the work of successful spaceplane designers, so I'm not sure where my mistake is.

http://imgur.com/a/9G2mD

It spins because at a point one engine will stop working before the other, this is a common cause of catastrophic failures.

Notice the "Air Req Met" on the Flight Data window, when that thing goes below 100% you will spin out.

Unless you have one single jet engine on the center, but if you do that you usually won't have enough power to keep up at that altitude.

What you do is set a command group to shutdown both at the same time, and activate the rocket engine.

Then you wait until you are as close to 100% air req as you can, and shut them down.

Edited November 21, 2014 by tetryds

[jstnj]

I see. Wouldn't the CoM shifting forward relative to the CoL increase stability, though? Or is there something I'm missing? Also, this happens well before I lose anything like a significant amount of fuel (using jets only), so I don't really see how the CoM could be shifting much on the airframe.

(I realize I'm probably misunderstanding you.)

Not when theres less atmosphere to push against your control surfaces, things can get topsy-turvy very quickly.

[Jovus]

The plane doesn't spin out, though, and the engines don't flame out (until I start the stall). The problem is that it noses up uncontrollably, but the engines are fine until then, nor do I have any yaw problems.

[tetryds]

The plane doesn't spin out, though, and the engines don't flame out (until I start the stall). The problem is that it noses up uncontrollably, but the engines are fine until then, nor do I have any yaw problems.

Then what you want is to remove those canards, increase your wing area a bit and move it forward to not turn into a dart.

Check exactly how is fuel being consumed by the fuel logics, it tends to use the fuel on the front first.

[Jovus]

I'll give it a try, thanks.

I know the fuel consumption logic is good, because I spent hours fixing it. It drains lateral rear - lateral front - core front - core rear

[tetryds]

I'll give it a try, thanks.

I know the fuel consumption logic is good, because I spent hours fixing it. It drains lateral rear - lateral front - core front - core rear

You may want to drain core rear before core front if you are running into issues at that point.

But if it's okay then no worries.