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

[Gfurst]

Cheers guys

This thread may get quieter now.

So a note on the mod entirely. It seem FAR isn't remembering its settings, every time I have to input custom action into the menu, and to not show up on the stock toolbar.

Stock toolbar, which by the way, when disabled, also doesn't show as a option for blizzy toolbar.

[Hektos]

Cheers guys

This thread may get quieter now.

So a note on the mod entirely. It seem FAR isn't remembering its settings, every time I have to input custom action into the menu, and to not show up on the stock toolbar.

Stock toolbar, which by the way, when disabled, also doesn't show as a option for blizzy toolbar.

I can confirm that I'm getting weird behaviour between stock/blizzy toolbar. I think this is a blizzy thing though, because PlanetShine also does the same thing.

[Svm420]

Cheers guys

This thread may get quieter now.

So a note on the mod entirely. It seem FAR isn't remembering its settings, every time I have to input custom action into the menu, and to not show up on the stock toolbar.

Stock toolbar, which by the way, when disabled, also doesn't show as a option for blizzy toolbar.

Same issue setting do not persist.

[futrtrubl]

Gfurst that is an excellent idea.

futrtrubl: Just because one can't completely solve a problem isn't a reason not to partially solve it.

I just hope it does, and doesn't cause more of a problem ;']

[ferram4]

Yes, I am aware of the saving issues; you can stop confirming them now.

I also figure out what was going on with the asymmetric plane, and I think I have some ideas on how to fix that. It's just another one of those main axis issues, and because it's asymmetric it doesn't hit the nice notes that I added for taking care of symmetrically-placed parts.

[uglyduckling81]

I have started a new career mode game in 1.0.2 with FAR.

I have found that all rockets require fins/stabilizers when using FAR.

I didn't need to do this in 0.90 with FAR.

It's basically a wrestling match every launch trying to keep the rocket going forwards along a gravity turn (without fins). It always ends in the rocket toppling over and breaking up.

I understand small rockets and even some space going rockets have used fins but none of the recent rockets I have seen launches for use fins or stabilizers.

Am I missing something or is this intended?

[ferram4]

All of the recent rocket launches you've seen have engines with large thrust vectoring ranges and stay directly on prograde, while also being designed to avoid very sudden changes in cross-sectional area.

Your rocket has no sudden changes in cross-sectional area, has a large amount of thrust vectoring capability, and stays directly on prograde, correct?

[Ser]

ferram4, someone has already reported insufficient drag problem. I can confirm this:

Gaining speed with engines cut, pitch near 0 degrees, spoilers fully deployed.

Vessel: a little aircraft made of early stock parts, ailerons, spoilers. Mass about 3.8t.

Stall speed about 70 m/s

Approaching at 83-90 m/s surface speed

Vertical speed -5 m/s

Pitch about -5..-3 deg

AoA about 6 deg.

Spoilers are constantly deployed at 40 deg.

Thrust: idle.

And still gaining speed.

That makes normal landing almost impossible unless going on a very shallow glide slope. When pitch is set to 0 degrees the vessel starts to lose speed but at a very low rate.

Removed FAR and got a reasonable speed decrement on stock, the rate was near the 0.90 FAR version.

Edited May 14, 2015 by Ser

[uglyduckling81]

All of the recent rocket launches you've seen have engines with large thrust vectoring ranges and stay directly on prograde, while also being designed to avoid very sudden changes in cross-sectional area.

Your rocket has no sudden changes in cross-sectional area, has a large amount of thrust vectoring capability, and stays directly on prograde, correct?

No my basic rockets have none or very little thrust vectoring, they veer all over the place but they are just a single tall stick in design.

You make a good point. It's really only a problem when I have 30 part limit in place as 4 fins/stabilizers take up valuable part count instead of science devices.

[ferram4]

@Ser: As was already noted, data of replicas compared with actual replicas built in KSP show drag between 1.3x and 1.8x what it should be for subsonic flight. Do you have data from real life showing that a craft identical to the one you built had different drag properties?

[Ser]

No, I don't have such data. But at least that means that spoiler action is insufficient.

Ok, let's suppose that my vessel has too much lift for its mass. This should only mean that its stalling speed is lower. But the current behavior is that it just cannot go down without gaining speed, as if it was a hollow zeppelin filled with helium. If it is close to a stalling speed it becomes uncontrollable (that's right) but still tends to gain speed. IRL any super aerodynamic design tends to stop in the air, mine doesn't even with spoilers up.

May be that's not the drag, but something's definitely wrong.

I can share my craft if you are interested. You may try to land it.

Edited May 14, 2015 by Ser

[tempsgk]

No my basic rockets have none or very little thrust vectoring, they veer all over the place but they are just a single tall stick in design.

You make a good point. It's really only a problem when I have 30 part limit in place as 4 fins/stabilizers take up valuable part count instead of science devices.

What is happening is your centre of lift is ahead of the centre of Mass.

[Sterbehilfe]

A question: Does FAR balance the "overpowered" stock aerobrakes?

Another question: Does it matter whether air intakes are open or closed? Aerodynamically? Otherwise?

And: I have encountered issues where my plane would inexplicably fly unstable, drag strongly to the left or right when launching it after fiddling in the hangar. When i restart KSP and load the same plane however it's smooth flying as it should be.

On a different note, i figured out what was causing my engines to have different thrust: TAC fuel balancing. Switching it off immediatly yielded full fuel flow in all engines.

[SzaboMarton_D]

is it just me? i made new career and everything FAR is included...after i orbited first time i retro back, seperate so my craft is only the basic pod with realchute on top and heatshield on bottom...and around 30km down it starts to flip over so bad that even the reaction wheels can't hold it...neither could MJeb...so i went back again and tested out different altitudes...and still when i hit the 26-22km range down it alwqays wants to flip head first and that either kills the chute by heating, or anyway making the heatshield pointless...

KSP is 1.0.2 and FAR is the latest to today...i tried with the stock chute too

also when having fins on the rocket and reaching the critical speed above 5-10km going up the fins induce a really weird lift only on one of their side, making them actually being the cause of the flipover...rotating the craft along it's horizontal axis helps it somewhat...and i always stay 10°near prograde that low...so i don't get it really...

also could you somehow fix the lift indicator in the VAB or SPH? because they jump around all the time and its really small so it's really hard to place something without seeing the CoL...

i like this mod but theese issues make me want to uninstall it for a while...i have enough problems with my 2hour loading time...

thanks if replied to

[Hodo]

I saw this today in the news, and was wondering would this work in FAR.

Because that would be a fun little excursion to try and get to work.

[tetryds]

@Sterbehilfe: Aerobraks currently run on stock code, they are overpowered but they work.

A closed intake should generate more drag, but AFAIK it doesn't change anything right now.

@Hodo: I don't see why it wouldn't be possible

I am unsure of how it behaves with InfernalRobotics, but from what I know it refreshes the voxelization every 0.8 seconds, so that shouldn't be an issue at all.

That plane looks awesome (also cool that the guy says the altitude in meters).

[Bedwyr]

If you guys are interested I saw another interesting design a few years ago that might make quite a FAR design challenge. Met the designers from the US Navy too.

http://www.dodlive.mil/index.php/2013/02/armed-with-science-saturday-top-tech-the-flying-transformer/

This would be a pretty extreme challenge though. The rotor half flips 180 quickly and stops turning very precisely at the correct angle.

[Goddess Bhavani]

I saw this today in the news, and was wondering would this work in FAR.

Because that would be a fun little excursion to try and get to work.

Sure, it's no issue at all to run distributed electric propulsion. Just make sure TWR is greater than 1.05 for positive vertical acceleration in hover mode.

This is a simple example craft I made as a quickie half hour project using Infernal Robotics Rework and TweakScale.

The video I made was before I tried nuFAR so I need to re-release a FAR-compatible craft file or you can download it and fudge the airfoil values until it's light enough to takeoff.

The KAX electric props used too much electricity (it may have been rebalanced now) back then and despite cramming on 8 space station sized batteries its runtime was very poor. As a result I didn't even bother to equip it with fixed-wing controls.

Sounds like it would be fun to make a nuFAR friendly version of this thing then

[Gfurst]

Ok, let's suppose that my vessel has too much lift for its mass. This should only mean that its stalling speed is lower.

May be that's not the drag, but something's definitely wrong.

I can share my craft if you are interested. You may try to land it.

A picture of your craft would be nice. Whats is wrong is that we're thrown off by the KSP scale and weight, parts are too heavy. Stock wings are hardcoded to produce a certain lift, to balance this out.

The thing is that you have a 4 ton (which is more than medium passenger carrier) craft with a smallish wing area, plus, FAR airfoil is symmetric and not very efficient one, so it means less lift and less drag, therefor, the minimum controllable speed gets higher.

I was having this discussion and made some tests to come to that conclusion, plus jet engines are very powerful making it possible for our super heavy crafts to get up to speed.

Accounting for the heavy weight (minimizing it) and building larger wings, will then get better results allowing for smoother landings... (which may be hard to do given the early career, so I've made some patches to balance things out)

Plus there are still some funkiness with the voxel system that we're trying to figure out.

[Ziw]

@Hodo: I don't see why it wouldn't be possible

I am unsure of how it behaves with InfernalRobotics, but from what I know it refreshes the voxelization every 0.8 seconds, so that shouldn't be an issue at all.

That plane looks awesome (also cool that the guy says the altitude in meters).

You'll have to wait for IR to update to 0.21.3 though, as now voxelisation is not updated for robotic parts as they move. We've already added the code to development branch. I'll post it tomorrow in dev thread for people to test.

[kcs123]

A closed intake should generate more drag, but AFAIK it doesn't change anything right now.

Not quite true. Closed air intake does not help with drag, but it helps to lower craft temperature. It prevents hot air to get inside of hull, so heating occurs only on craft skin.

Don't know why SQUAD make them to work like that, but certainly helps if you are switched to rockets while you stil fly too fast and too low in atmosphere.

[Ser]

A picture of your craft would be nice. Whats is wrong is that we're thrown off by the KSP scale and weight, parts are too heavy. Stock wings are hardcoded to produce a certain lift, to balance this out.

Ok, I'll post it a few hours later as I get to that PC.

[DuxDucisHodiernus]

How do i control flaps/ spoilers properly?

Also the wiki is very lacking.

[toadicus]

@FaterW: That indicates that TweakableEverything is updating the scale of parts way, way, way too often. There is nothing I can really change on my end, because I have to update the shape every time the part is rescaled; if TweakableEverything is rescaling parts when it doesn't have to, that's on that mod to be more efficient.

ferram4; TweakableEverything doesn't actually rescale parts, or do anything intentionally to trigger any event calls. That said, TweakableEverything (and any other mod that uses Squad's FloatRange tweakables) exposes a Squad bug relating to tweakables and excessive calls to onEditorShipModified, which I've generally identified to behave thus:

...When the control detects that something's changed, it does some work to assign the new value to the part and whatever needs to happen as a result of that goes ahead and happens. There are certain points in certain ranges that cause onEditorShipModified to be fired way too often when the ranges are open. The reasoning goes something like this:

1. The slider loads up and sets its position to X pixels long. The total slider is Y pixels long.
   
2. Since the slider is repositioned, fire an update event. (this eventually chains to an onEditorShipModified call, which can be very expensive depending on the mods installed and the size of the ship)
   
3. The control uses the slider's normalized position to interpolate along the available range, essentially Value=Min + (Max - Min) * X/Y
   
4. The control checks if Value lands on a stepIncrement (the feature that makes ranges "snap" to certain values along the range).
   
5. If Value does not land on a stepIncrement, it rounds the value to the nearest stepIncrement and repositions the slider, basically X=Y*(Value - Min)/(Max - Min) truncated to an integer (no fractional pixels).
   
6. If the slider is repositioned, start over at #1.

For certain values in certain ranges, especially when stepIncrement is small in relation to the overall tweakable range, that equation for Value will never return a value divisible by stepIncrement. When that happens, onEditorShipModified is called every Update for every float range visible that is subject to this condition. If you want to check if that's what's happening, compile this plugin and see if onEditorShipModified is called whole bunch in those trouble scenarios: http://hastebin.com/nudeniboli.cs

This means that any time a FloatRange tweakable (something I've added, or a Squad stock tweakable) is active and set to a value where the slider can't sit precisely on a stepIncrement, Squad's code spams onEditorShipModified. This is mostly present for tweakables that default to a value other than 100% or 0%, which in general Squad doesn't have very many of, so this is mostly exposed when mod parts or tweakables are used.

Does that seem like a plausible explanation for what's going on in FaterW's report?

I'll consider rewriting UI_FloatRange entirely if that's what it takes to keep TweakableEverything and FAR playing more-or-less nicely. Thoughts?

[Goddess Bhavani]

How do i control flaps/ spoilers properly?

Also the wiki is very lacking.

If you open the FAR configuration menu in the main KSC screen, you can have FAR assign two action groups to increase and decrease flap setting.

Thus you will be able to deploy or retract all flaps with 2 keys, instead of running all over the plane and right clicking individual control surfaces.

"Negative flaps" may also be used for interesting effects, such as elevator position overrides / response boost for takeoff rotation, aerobatics mode, etc.

Likewise you can have spoilers on the B key (by default) and by assigning "negative spoilers" to elevators you can automatically trim the aircraft to decelerate with airbrakes while not changing pitch at all. It requires some trial and error but very rewarding when you get the 'control logic' setup just right.