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

[tetryds]

I have a question regarding the building of airplanes/spaceplanes. While flying, my SNC Dream Chaser replica tends to go into combined pitch and yaw, resulting in unrecoverable stall.

I've read somewhere that dihedral wings "under" the COM make a stable combination. However, it seems that is not the case here. I'm on my phone so I'll post pictures as soon as get to my laptop.

Thanks in advance!

You should post it on the official FAR craft repository, this topic is mostly to discuss the mod itself you will get better support there.

[viktor19]

You should post it on the official FAR craft repository, this topic is mostly to discuss the mod itself you will get better support there.

Didn't now where to put it so I ended up here. Thanks for directions

[ferram4]

Well, there are a few points to make here.

1) Dihedral wings do make the plane more stable in roll, but mounting them lower on the vehicle makes them unstable. In addition, backwards-swept wings also increase the dihedral effect; the strongest effect is from wings mounted on top of the plane, with a positive dihedral angle and lots of reward sweep.

2) Dihedral angle alone will not cause pitch issues. It can, however cause pitch issues in conjunction with a lack of yaw stability.

So, assuming your vehicle is actually stable in pitch to begin with (if it's not, move the wings backward or the CoM forward), there is a way that inertial coupling can cause yaw / roll behavior to make pitching a problem. This is a function of how lift changes as a function of Mach number at near 0 AoA and how lift reacts to changes in sweep.

The first problem is that as Mach number increases, wings near 0 AoA become less effective at producing lift. This has the effect of dropping yaw stability, sometimes enough to make the vehicle unstable in yaw. The second problem is that at higher sweep angles (note: relative to the airflow), wings create less lift if they're kept at the same AoA; this is why a 737 needs less AoA to take off than the Concorde did.

Alright, taking a wild stab in the dark, this problem showed up in the upper atmosphere, with you at a high AoA and high Mach number. That would lead to the yaw stability of the vehicle dropping a lot. So it starts to sideslip to the right a bit... and suddenly, the left wing is at a lower sweep angle (more straight-on to the airflow) than the right wing is; the left wing makes more lift than the right wing. It starts to roll to the right under this force, and rather violently because it was at a high AoA to start with, so a relatively large change in lift between the wings. So now, sideslip (remember, this is all relative to the vehicle) decreases, and then starts to increase in the opposite direction as it overshoots. Meanwhile, AoA starts to decrease, but the trim level compensates to start bringing the plane back to that AoA, but that overshoots too.

At this point, if you're lucky the phenomena you're experiencing (wing rock) is damped enough to not destroy the vehicle and you have the sense to bring it back under control by finding an orientation that brings the sideslip angle to 0. And then you fly at a lower AoA, or add more vertical tail. Or more lever arm for vertical tail to act over by moving the tail back or the CoM forward. This issue really only occurs between Mach 2 - 7, above that the effects of sweep on wing lift are much less important so there's no forcing, but at KSP speeds, this can be a real problem.

[Cairol]

This heating bug is sure annoying.

Today my space stations power module lost a couple of batteries, lights and solar panels due to a spontaneously exploding strut connector

while I was doing Stuff at some other module.

Deinstalling FAR until this is fixed.

If octagonal struty on my rocket explode during ascent, I can handle it by changing the design.

But if existing crafts that are already in space get damaged randomly, it's not bearable for me.

Looking forward for the next release.

[viktor19]

Well, there are a few points to make here.

1) Dihedral wings do make the plane more stable in roll, but mounting them lower on the vehicle makes them unstable. In addition, backwards-swept wings also increase the dihedral effect; the strongest effect is from wings mounted on top of the plane, with a positive dihedral angle and lots of reward sweep.

2) Dihedral angle alone will not cause pitch issues. It can, however cause pitch issues in conjunction with a lack of yaw stability.

So, assuming your vehicle is actually stable in pitch to begin with (if it's not, move the wings backward or the CoM forward), there is a way that inertial coupling can cause yaw / roll behavior to make pitching a problem. This is a function of how lift changes as a function of Mach number at near 0 AoA and how lift reacts to changes in sweep.

The first problem is that as Mach number increases, wings near 0 AoA become less effective at producing lift. This has the effect of dropping yaw stability, sometimes enough to make the vehicle unstable in yaw. The second problem is that at higher sweep angles (note: relative to the airflow), wings create less lift if they're kept at the same AoA; this is why a 737 needs less AoA to take off than the Concorde did.

Alright, taking a wild stab in the dark, this problem showed up in the upper atmosphere, with you at a high AoA and high Mach number. That would lead to the yaw stability of the vehicle dropping a lot. So it starts to sideslip to the right a bit... and suddenly, the left wing is at a lower sweep angle (more straight-on to the airflow) than the right wing is; the left wing makes more lift than the right wing. It starts to roll to the right under this force, and rather violently because it was at a high AoA to start with, so a relatively large change in lift between the wings. So now, sideslip (remember, this is all relative to the vehicle) decreases, and then starts to increase in the opposite direction as it overshoots. Meanwhile, AoA starts to decrease, but the trim level compensates to start bringing the plane back to that AoA, but that overshoots too.

At this point, if you're lucky the phenomena you're experiencing (wing rock) is damped enough to not destroy the vehicle and you have the sense to bring it back under control by finding an orientation that brings the sideslip angle to 0. And then you fly at a lower AoA, or add more vertical tail. Or more lever arm for vertical tail to act over by moving the tail back or the CoM forward. This issue really only occurs between Mach 2 - 7, above that the effects of sweep on wing lift are much less important so there's no forcing, but at KSP speeds, this can be a real problem.

Wow! This is...a lot of useful info. Thanks for such deep analysis of my problem. One rarely sees such commitment to fixing someone's problem in this forum. I will definitely try your advices written above.

One more question: how come this problems don't bother the real Dream Chaser? Could it be because of different body design? I recall in the pictures that DC has flat bottom.

[Hodo]

This heating bug is sure annoying.

Today my space stations power module lost a couple of batteries, lights and solar panels due to a spontaneously exploding strut connector

while I was doing Stuff at some other module.

Deinstalling FAR until this is fixed.

If octagonal struty on my rocket explode during ascent, I can handle it by changing the design.

But if existing crafts that are already in space get damaged randomly, it's not bearable for me.

Looking forward for the next release.

Odd I havent seen this problem in my install since I figured out what was causing it.

The heating and exploding part problem is mostly caused by parts clipped into each other in someway. I have since stopped clipping certain parts into each other and it quit happening. The biggest problem child was BDArmory pylons, I like to place them in bundles of 3 so I can mount things in threes like real pylons under some aircraft. Well FAR/KSP does not like that so they randomly overheat and explode.

And I dont think the problem is FAR problem as much as a stock KSP problem currently.

[cantab]

I am reporting an incompatibility between FAR and Roverdude's Alcubierre Warp Drive. With both mods, and no others, installed manually the game regards parts within the warp drive's warp bubble as "stowed" even when the warp drive is not activated. Other (stock) engines will not activate and solar panels and radiators will not deploy if they are within the size of the warp bubble. This occurs on the ground on Kerbin or in space, and applies whether the warp drive is inactive or active. The warp drive itself is not regarded as stowed and will operate when above its failsafe altitude.

Installation details:

OS: Ubuntu 14.04.

KSP version: 1.0.4, Linux 64-bit.

Alcubierre Warp Drive version: 0.2.1

FAR version: v0.15.3.1 "Garabedian"

This is similar symptoms to what eliminate1337 described in late May, http://forum.kerbalspaceprogram.com/threads/100798-1-0-2-Alcubierre-Warp-Drive-%28Stand-alone%29-v0-2-1-2015-05-15?p=1958397&viewfull=1#post1958397 . I have not attempted to confirm his docking workaround.

Edited July 11, 2015 by cantab

[ferram4]

Yes, that's entirely because the warp drive uses a mesh to create the bubble, which FAR then voxelizes. I can try and add a quick fix to ignore that particular mesh, but ultimately that's a stopgap and I suspect it'll break if Roverdude changes anything about how it's set up.

[Gryphon]

I am reporting an incompatibility between FAR and Roverdude's Alcubierre Warp Drive. With both mods, and no others, installed manually the game regards parts within the warp drive's warp bubble as "stowed" even when the warp drive is not activated.

This is just a shot in the dark, but what does a ship with the warp drive look like when you make FAR voxelization visible?

- - - Updated - - -

Dang, ninja'd. At least I was right!

[Nansuchao]

Is there a kind of workaround for the overheating problem?

[kcs123]

There was also small debate recently in KAX thread about high drag on heli rotors. KAX rotor use collision box for rotor when engine running for interaction with other objects in game (ground,building, other crafts). Unfortunately FAR detects this as mesh and do voxelization on it.

It seems similar as Alcubierre Warp Drive issue. Tricky thing is that not whole mesh need to be ignored by voxelization, only specific collision boundaries inside it.

I don't know if it is possible to properly identify only specific collision from mesh and write MM patch that will tell FAR to ignore it.

If it is possible that will be great, otherwise more difficult aproach is needed.

If FAR can have special MM config for any part that could be used to override default FAR behaviour when comes to voxelization that could help.

In such config file there should be data that FAR need when calculate voxelization, but instead of calculating "on the fly", FAR should read data directly from config file ignoring actual mesh collision.

Is something like that possible ? Could be solver for special parts that some mods use.

[Hodo]

Is there a kind of workaround for the overheating problem?

My work around for it is not to clip some parts into each other. Especially if they are load bearing.

[Nansuchao]

I have this problem without clipped parts... It seems to happen more often when you decouple something from a fairing's base.

[Hodo]

I have this problem without clipped parts... It seems to happen more often when you decouple something from a fairing's base.

Havent made anything that used a fairing in months maybe a year. But the times I have the overheat problem is mainly due to parts slightly clipping into something else.

[cantab]

Regarding the warp drive and other mods with similar issues, would it be feasible for FAR to recognise part config options that instruct it to not voxelize certain meshes? Then part developers would add those options where needed to make their parts behave correctly in FAR.

Is there a kind of workaround for the overheating problem?

Turn on the "Ignore Max Temperature" cheat?

[Nansuchao]

Yes, sometimes I solved with that. The annoying thing is when yoU switch to another ships and back. Usually the old one will explode in no time due to overheating, so you have no time at all to activate the cheat.

[Nansuchao]

Ok, I found a solution for the overheathing problem. First of all, quicksave everytime you think you're having this problem. Now, usually, if you switch back to the KSC and then to the ship again, this will explode immediately. If you, instead, open the save (persistent), you'll find that every part of that ship has the two "temp" string, setted to "Infinity". If you change this with 0 (zero), when you reload the ship, the heat system return to work properly. It can be a long and tedious process, but can save your long awaited mission, just in case... I hope this can be helpful.

Edited July 11, 2015 by Nansuchao

[steve_v]

Ya, Ive used sed find/replace on my save far too often since 1.0.3... I'm pretty sure this is a stock bug, FAR just exacerbates it when it reduces the skin area for clipped parts.

[nitebomber51]

So I was just curious to see if there is an easy way to re-enable FAR on x64 KSP, Ive grown accustomed to using FAR whilst I play KSP and with the current implimentation of FAR's Disabling Feature, It seems to disable all atmosphere completely. So I was just wondering if there is any way to re-enable FAR or atleast request for FAR to not be disabled when using x64 as I dont particularly want to have to uninstall my mods just so I can have an actual atmosphere.

[taniwha]

nitebomber51: by far the easiest way is to install Linux and run 64-bit Linux KSP. It's also the easiest way to avoid getting yelled at by modders.

[Temeriki]

So I was just curious to see if there is an easy way to re-enable FAR on x64 KSP, Ive grown accustomed to using FAR whilst I play KSP and with the current implimentation of FAR's Disabling Feature, It seems to disable all atmosphere completely. So I was just wondering if there is any way to re-enable FAR or atleast request for FAR to not be disabled when using x64 as I dont particularly want to have to uninstall my mods just so I can have an actual atmosphere.

Notepad++ or the easier option to install linux. Using mods on x64 windows ksp only increases instability, its bad to the point where squad has pulled the windows x64 version. This should tell you something, if the original devs dont support something why should the modders.

[Wanderfound]

Odd I havent seen this problem in my install since I figured out what was causing it.

The heating and exploding part problem is mostly caused by parts clipped into each other in someway. I have since stopped clipping certain parts into each other and it quit happening. The biggest problem child was BDArmory pylons, I like to place them in bundles of 3 so I can mount things in threes like real pylons under some aircraft. Well FAR/KSP does not like that so they randomly overheat and explode.

And I dont think the problem is FAR problem as much as a stock KSP problem currently.

I'm still routinely getting phantom overheats on small parts in cargo bays, no clipping involved. Time acceleration seems to aggravate it; I've had thermometers/batteries/etc explode during takeoff when 2x physics was applied on the runway. But it doesn't happen predictably, and I've no idea if FAR has anything to do with it.

[Temeter]

Where can I get the current FAR devbuild? I've got a whole bunch of issues with heat, and want to at least remove one possible point of failure. Got the github bookmarked, but i'm not sure where to look.

[Nansuchao]

After some tests in stock aero and Far, I can say that is a stock bug, exacerbated by FAR, or for sure, by a heavy modded install. If The RAM has a hard job every second, it happens more often. At this point, I think it'll be easy for SQUAD to fix it, and I hope they make it ASAP.

[Temeter]

After some tests in stock aero and Far, I can say that is a stock bug, exacerbated by FAR, or for sure, by a heavy modded install. If The RAM has a hard job every second, it happens more often. At this point, I think it'll be easy for SQUAD to fix it, and I hope they make it ASAP.

FARs problem is afaik incorrectly calculated surface or so, which could ofc excacerbate the issue.