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

[Voculus]

Hmmm. I knew their values had been tweaked, but what threw me off, and I failed to make clear earlier, is that they took off and flew rather well at low speeds. It was only when the speed was poured on, that they started fighting me. Glad to know a fix is in the works.

[IvanTehFennec]

How about giving us a way to run this on the win64 build, regardless of instability? What if we don't care about it at all? I want to use x64, and don't care about the bugs.

[AetherGoddess]

How about giving us a way to run this on the win64 build, regardless of instability? What if we don't care about it at all? I want to use x64, and don't care about the bugs.

the disable is not to protect you from bugs, it's to protect ferram when you come back and complain about squad bugs as if they were ferram's fault.

what you sugguest is exactly what a lot of mod makers did in .24, but 1) it didn't stop them getting complained at, and 2)the problem has gotten worse in .25. Linux x64 seems to be operating normally, and all the crashy is on the squad side of the wall, so modders just stopped letting their mods run at all in win x64.

[ferram4]

I tried leaving it open. I also tried allowing mods to run on KSP versions that they weren't intended for, so long as the user acknowledged that they were broken. In both cases, people ignored it and proceeded to make supporting the mod more difficult. So no more of that now, I'd rather spend time working on issues that I can fix rather than issues that are from older builds or that are Squad / Unity's fault that I can't do a damn thing about. I'm not going to help support something as broken as win64 KSP; that should have never gotten out of experimentals in the first place.

[coldblade2000]

I found a bug, don't know if it has been posted yet:

In the SPH, when you go to the data & stability derivatives screen and set mach number to 0, the window glitches out and stops working, but the game itself is unaffected. Picture here: http://i.imgur.com/ZPMN0XI.png

[ferram4]

@coldblade2000: And nothing else? Using stock parts? Wings needed or just anything will do?

Edit: Oh wait, this makes sense. Mach 0 corresponds to V = 0. Okay, I'll add something to prevent that.

[Vanamonde]

With regard to some removed posts, you folks need to express yourself without resorting to insults.

[IvanTehFennec]

With regard to some removed posts, you folks need to express yourself without resorting to insults.

Sorry, forgot we're not allowed to be angry at each other. I'll be a good little goy, I promise.

[blowfish]

I think this whole saga is a good indication that Squad should never have released the x64 version in its current state.

[Temeter]

Hmmm. I knew their values had been tweaked, but what threw me off, and I failed to make clear earlier, is that they took off and flew rather well at low speeds. It was only when the speed was poured on, that they started fighting me. Glad to know a fix is in the works.

It's not weight. I had a spaceplane from the earlier versions, which was 260t with cargo, and it flew wonderfully at almost all speeds and heights. New FAR update without cargo is 250t, and the instability doesn't make sense (at least considering the old FAR's working), even with a shifted CoM. You can just test old craft with almost empty fuel tanks.

Taking a close look with a new plane, the issue seems to be excessive stalling at ~20k and mach 4+, sometimes even lower at 15k/mach 2. Even going up 5 degrees from apoapsis can cause wings to stall. I'm not saying it has to be the mods/games fault, but there has to be a huge change inside of FAR.

Maybe someone can help with more information. This plane is something i threw together and modified it a bit. All stability derivates are green above Mach 2/3, at all heights. Also a mach 5 AoA sweep, i'm not sure i could read critical failures out of it.

Edited October 11, 2014 by Temeter

[Senshi]

Regardless of x64 being buggy, I hate being patronized by a mod . I personally simply don't experience a lot of issues with x64 (certainly less than with a x32 always bloating to the memory limit), and it allows me to utilize all the mods I like.

I now compiled the .dll privately with the 64bit check removed and am enjoying FAR just as before. But it obviously would be nicer to just be able to toggle a flag somewhere. In the cfg maybe? With a capital letter comment that enabling x64 support void all support requests? So users have to do a manual change to activate 64bit, should make it more apparent they are venturing in the experimental area.

[taniwha]

Senshi: part of the lockout is it is a filter: those who can recompile it themselves will anyway. However, they take on the responsibility. More importantly, they take on the responsibility of providing support should they distribute the modified version.

[DaMichel]

@DaMichel: Wing mass is computed using the "supported area" of the joint, which is calculated from that wing's area and the area of all wing parts that are children of it. This supported area is then multiplied by a constant (in FARAeroData.cfg) to calculate the wing mass. I picked a number that I calculated for the wing mass per unit area of a MD-83 for that, but perhaps it should be lower.

Thanks Ferram4. I do however suspect that this is bugged. See here. The multi part wing is heavier.

where m means mass, obviously. I used the current dev version, commit fc25444.

P.S. Ferram4, would you mind uploading some of your plane creations? Now that the former examples are gone i would genuinely love to see what you come up with using the new parts.

Edited October 11, 2014 by DaMichel

[Wanderfound]

It's not weight. I had a spaceplane from the earlier versions, which was 260t with cargo, and it flew wonderfully at almost all speeds and heights. New FAR update without cargo is 250t, and the instability doesn't make sense (at least considering the old FAR's working), even with a shifted CoM. You can just test old craft with almost empty fuel tanks.

Taking a close look with a new plane, the issue seems to be excessive stalling at ~20k and mach 4+, sometimes even lower at 15k/mach 2. Even going up 5 degrees from apoapsis can cause wings to stall. I'm not saying it has to be the mods/games fault, but there has to be a huge change inside of FAR.

Maybe someone can help with more information. This plane is something i threw together and modified it a bit. All stability derivates are green above Mach 2/3, at all heights. Also a mach 5 AoA sweep, i'm not sure i could read critical failures out of it.

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

This does match with my experience since the update. I don't know if it's due to heavy wings or not, but I am struggling to control pretty much anything above 25,000m, regardless of what the analysis screens say. Lack of lift and dangerous stalls at small AoA's. I can get to orbit, but it's a chore. It almost feels like flying in stock aero again.

I'm pretty much focussed on rockets and career mode until this shakes out. Kerbodyne SSTO Division is taking a temporary holiday.

The dev build looks promising, though.

[Temeter]

Jep, i'm also trying the devbuild (the 250t plane was the normal 14.2). The modifiable wing mass is great! Can't wait to see to what extremes i can drive my spaceplanes.

Also thx to ferram for making the general wing weight a bit less extreme. Just adding a few wings was a bit to simple before, but i feel the now adjusted way is better than throwing winged stones at the sky.^^

edit: Huh, I just brought a stone into stable orbit. Interesting point: EDIT: Nope, nvm. There seems to go on more than i understand... Oo

Also, very light wings might be a bit to stable. Might have been a procedural wings thing, but even big B9-stabilisators did withstand some crazy stuff. Hard stall including incontrollable spiral (at ~15k), and nothing happened to 0.2 to 0.4 mass stuff.

Edited October 11, 2014 by Temeter

[wingnutspeed]

Be prepared to wait for a long time then. x64 is unstable because of underlying Unity issues and sloppy programming from squad. You'll probably have to wait for Unity 5 to be released before you see a stable x64 KSP.

i dont care about stable my .24.2 crashes all the time bot thats becouse allot of mods that i use i just dont want to use incompatible mods so when all mods all compatible i go to .25 if it is stable or not

[JackCY]

Where can I find the devbuild? Or do I have to compile myself from latest source?

Try setting the gains. It doesn't automatically do it for you, because tuning those values automatically will always go badly.

Try setting the AoA limit lower?

It's to prevent you from overcontrolling the plane during high-dynamic pressure maneuvers. Maybe you should mess with the options.

I will try some more but so far I think reducing the power my me control surfaces would work better than guessing random numbers.

Often I get oscillation when I use anything else but stock SAS, I do turn off SAS when trying the FAR helpers, it seemed to me they fight each other otherwise.

So far I had to resort to use stock SAS for stabilization of roll/pitch and couple it with DCA while changing the Scaling Velocity mid flight to get proper control force. The Scaling Altitude didn't seem to have any effect at all on the Control Factor, trying it again, it does have an effect but the number put there are different by thousands of times to have any effect on the control factor.

Right now I got on runway and the plane oscillates, opened FAR and the helpers are turned on, stock SAS is off, MJ is not present on this craft.

It does this even when flying most of the time.

The AoA limiter, I have it set to 1 degree but it will happily do 10-15 degree anyway.

Changed helpers to 0.01 from default 0.1 but they still oscillate the same way as before when landed.

Even when flying the FAR helpers like to oscillate no matter what and usually do overshoot instead of lower the input a little they like to shoot all the way to the other side so instead of going less up it turns it all the way to going down for example and then back up and down and up again ... And when I manage to get rid of oscillation from the helpers it also turns out that their power is negligible and I might just turn them off as it has the same effect.

Caused me many stalls when trying the helpers, the dampening instead of reducing oscillations introduces them even when I lower the forces ten times.

Tried a leveler now, instead of turning the short way around, it turned the long way, another large stall as it rotated out of control.

Glad I took my cargo version and not the heavy passenger version of the plane. This one is much more recoverable.

The AoA limiter so I set it to 5 but it happily keeps going 10-15 AoA and if I increase the force it will oscillate. It helps but not very much, have it at 5 degrees and k=0.05 to get 15 degree turn at this moment of my flight. But some other time in the flight I might have to reset this again so it corrects AoA desirably. That is not very practical as all I do is change values in helpers AoA and DCA instead of flying and before any important steering I have to reset the helpers so I can steer well and am not limited too much or too little.

When I want to recover, turn off all FAR helpers, hit stock SAS ON and keep it moving usually down or to the direction closest of prograde if it can move close to it that easily.

I think bill and jeb must have thrown out in the cockpit by now because that was so far at least 6 spinning stalls. 10t plane, doing 1-2 mach at 10-20km.

It's quite a challenge to make the helpers work well and set them up for one plane. None will hold altitude though. Have to use stock SAS or MJ for that.

If I use stock SAS and couple them with the helpers, they don't have enough power or get overridden by SAS.

Guess my plane could be a bad design or 0.25 is harder flying than 0.24. Just flew FAR Jet Liner and that's a piece of cake even landing on first try, no stalls, impossible to stall even without helpers, nothing really needed apart from something to keep height locked. All the example planes in 0.24 seem to have very different graph and most use wings up above to keep CoL above CoM, usually heavy with little amount of control surfaces. With no apparent stall curve in the graph and with Cm always in graph shooting up which I cannot achieve in 0.25. Maybe having a huge tail wing helps?

A simple, small example craft would be great to have. Don't need zillions of them like there were in 0.24. A basic one, just one is enough so we can see ok these is what is stable with FAR and it looks like this and that in the graph.

I bet my plane is too short and since it has all lift at the middle it makes it easy to stall compared to planes that have front and rear wings more similar in lift.

You only have to click one button. You don't need to update the CoL before the sweep; the button is there for if any errors occur for the indicator alone. I'll make sure to remove it to reduce confusion.

Let me try again. My bad, it had me confused. The CoL marker/indicator for me updates fine and graph seems to update OK without the Update CoL. I don't mind the button, keep it, I just couldn't find explanation while in game in the help for what it does and it wrongly seemed to have helped to update before doing a sweep.

It actually remembers three different values, but I'm not sure what you want: another entire window for the settings for each sweep type?

I'll illustrate on my silly Kerbal carrier that I use for testing purposes:

I would say it remembers 4 values: Lower, Upper, Num Pts (precision), Mach/AoA

1. So I do a sweep for AoA with values: 0, 25, 50, 0.2, the default ones I think.
   
2. Then I do a sweep for Mach but the values used are again 0, 25, 50, 0.2, which is not very useful so I change them to: 0, 5, 50, 15
   
3. and sweep Mach again.
   
4. "Now I have made changes to the plane." And proceed to do AoA sweep, click and the values used are not 0, 25, 50, 0.2 as I used for AoA before but it uses the new modified values I have used for Mach sweep the 0, 5, 50, 15 so I get again a not very useful graph
   
5. and have to change the values again and resweep once more, every time I do different type of sweep.
   

It would be useful if it remembered the values for the type of sweep it is doing. It should not be hard to detect what values to use:

Previous sweep/next sweep/values to use:

none/AoA/default useful values for AoA or remembered from previous AoA sweep if possible

none/Mach/default useful values for Mach or remembered from previous Mach sweep if possible

AoA/AoA/those entered in the text fields

AoA/Mach/those remembered from last Mach sweep or default if no previous Mach sweep was done

Mach/Mach/those entered in the text fields

Mach/AoA/those remembered from last AoA sweep or default if no previous AoA sweep was done

It would then remember 4 values for each type, 8 values total. Precision is not important so it could as well be 3 and 6.

There was. Then Squad updated the plane parts and they were all broken.

I see, I might check 0.24 then and see what is there. Thanks.

Edited October 11, 2014 by JackCY

[tetryds]

There was. Then Squad updated the plane parts and they were all broken.

I can help making planes that could be made stock far planes, several people who start with the mod need them to remember how an actual plane flies before building their own.

[Baughn]

Nope, can't seem to make a stable plane. :-(

If this is fixed in the dev build, could someone please point me at it? I can't seem to find one.

[ferram4]

@Temeter: There were some changes to the raycasts used by wing interaction stuff to get around some issues with the SP+ wings. I guess I'll just have to recode the whole damn thing.

@Senshi: Good to hear! Now you're on your own, until win64 is stable. Have fun, and don't complain.

@Da Michel: Okay... I guess I'll need to recode that then.

@wingnutspeed: No, win64 is unstable because win64 is busted. The number of mods just exacerbates an already-existing stock issue. There are also pretty much no incompatibilities between mods; I don't know where you even got that idea.

@JackY: If changing the gains and limits did nothing, then you didn't click the update values button. I think that you are expecting an autopilot rather than minor control assistance from the control assistants; perhaps you should code one of those up.

Landed and stopped control oscillations are known; it's caused by the velocity vector changing direction like crazy, because you're never perfectly stopped.

None of the control assistants are intended to hold attitude. As I said, they are assistants, not autopilots.

I'm not building example craft again. They quickly become out-of-date if I update the physics to be more realistic and I expect that the spaceplane parts will get another pass anyway.

So... you do want a different window with each value for the sweeps. Yeah, not going to bother.

As a side note, I'll bet that plane of yours has really stupidly high wing loading.

@Baughn: A completed build can always be found in the github repo.

[JackCY]

@JackY: If changing the gains and limits did nothing, then you didn't click the update values button. I think that you are expecting an autopilot rather than minor control assistance from the control assistants; perhaps you should code one of those up.

I do click it

I've made minor changes to the plane and now it flies almost perfect with stock SAS, no need for FAR helpers or anything, not even DCA or AoA.

The plane is small and the control surfaces were strong, so strong that FAR helpers were oscillating when trying to correct the plane and when "k" changed they don't they lost all steering ability altogether. I've lowered the power of control surfaces and now it flies fine.

Both slow speed <0.5 and mach 4.

Landed and stopped control oscillations are known; it's caused by the velocity vector changing direction like crazy, because you're never perfectly stopped.

Yes but why make any corrections if the velocity vector is tiny? It must have a value something like direction, don't care about that one for this but also speed at which it is moving in that direction, now if that speed is tiny do not try to correct the steering. Should remove oscillations when landed.

None of the control assistants are intended to hold attitude. As I said, they are assistants, not autopilots.

Yeah, they dampen yaw, pitch, one does hold roll to 0 and the rest limits steering.

Guess I will have to look elsewhere for a hold pitch.

So... you do want a different window with each value for the sweeps. Yeah, not going to bother.

Not a different window but a smarter way the values are remembered is all as described in previous post. Store one extra variable of what was the previous type of sweep done, store 6 values total and a few if/else, done.

As a side note, I'll bet that plane of yours has really stupidly high wing loading.

Could be, it's 10-20t and FAR says reference area 35m2 if that means wing area.

At current 11t and 35m2 that puts it to 315kg/m2 a little over Eurofighter Typhoon's 313kg/m2.

At 20t that would be 571kg/m2 which is less than A380 with around 663kg/m2. F22 has 376kg/m2.

--

I've made a different plane that is similar to the 0.24 example planes but it does not take off very well. Has wings placed up top with a large area. It's much heavier since it has many fuel tanks. Flies ok but is slow despite having higher TWR, the wings must give it quite some drag.

Edited October 11, 2014 by JackCY

[NathanKell]

FAR reference area is for *all* wings, including horizontal and vertical tails. In real life, only main wings' wing area is used. So your wing loading is more like 400-450kg/m^2

[DundraL]

Hey just another lurker here....

After finding my wing parts much too heavy with the recent update, I read this thread and found the dev/master version on github...

After which I found that the default strength for wings is much heavier than stock counterparts....

Any way I would ask that you consider making the default position for the "mass/strength" slider at a point where the mass would match with the part description.

A step further and you might even allow a config file to change the default slider position for those who find themselves constantly tweaking every wing surface higher/lower.

Other concerns with this is that some challenges may start disallowing FAR "because it can change the mass of stock parts"... that's not something I want but again, the decisions are yours to make.

Also, I have noticed some changes to stability in existing craft, but I'll come back to this later as I expect there will be further changes to both stock and FAR that would prb render any fine tuning obsolete...

Any way, thanks for the time- DundraL

Edited October 11, 2014 by DundraL

[Baughn]

I didn't expect binaries to be checked into github... but that works.

I found the dev build, and it works fine, in the sense that my planes now fly. This feels like a major achievement. ^^;

However, the analysis system appears to be broken; the graphs all go up and to the right, stability derivatives suggest my airplane should go into a spin and tear itself apart on takeoffâ€â€possibly without movingâ€â€and the displayed wing area is 1 m^2 regardless of actual area. Maybe I installed something wrong?

[ferram4]

@DundraL: I can't do that though. The stock wing masses are so low that the wings would rip off under tiny forces if I tried to get them close, and considering that the mass of the root of a wing will always be heavier than the mass of a similar piece placed at the tip of a wing. The best I can do is to have the wing mass appear in the tweakables readout.

Also, I don't care if challenges disallow FAR. Most already do because of the lower dV to orbit. No skin off my nose.

@Baughn: I suspect a bad install. Nothing has changed there for that to be the case, and it works fine for me.