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

[ferram4]

@MaxRebo: If the dev build didn't help you, I need you to provide me a stock-parts-only craft that still experiences issues for testing to make sure that nothing is broken.  I've got time while I wait for confirmation that the non-zero-convective-flux-in-pFairings issue has been fixed.

@Mine_Turtle: Because of how that design is set up the vertical tails on the engine bodies will provide negligible effect at 0 angle of attack and will actually contribute to instability if the vehicle pitches below 0 AoA.  You need to either get rid of them or move them further back; there are no planes in the world that put their vertical tails in line with the center of mass because that does nothing to help yaw stability.

[MaxRebo]

@ferram4I can't seem to reproduce the instability problems of my designs using B9 procedural wings by approximating them using just stock parts. The stock equivalents work as flawlessly as my B9 designs used to under Kindelberger, they just look a lot uglier. Guess that means I'll be staying with 0.15.6.3 for as long as possible, because I'm not willing to ditch the B9 procedurals. Thanks for trying to help anyway.

[ferram4]

@MaxRebo: Then give me a craft with stock + B9 pWings.  Just keep the mods to a minimum so I can load it up and confirm what's happening quickly.

[MaxRebo]

@ferram4 I think I might have found my issue. Preparing one of the planes for you by removing non-stock/B9 pWings parts meant replacing the B9 quantum struts I used to stiffen the wings with stock ones (I use KJR only for physics smoothing because the joint strengthening feels cheaty). The wings still started oscillating and finally exploding at the slightest touch of a control to compensate roll forces at about mach 3, but that was a noticeable improvement over mach 1.5 with the B9 quantum struts. So I tried slapping triple the amount of them on, and that resulted in my plane going over mach 3 under 5km altitude without major problems (like they did without moar struts in Kindelberger). Turning on all joint re-enforcing in KJR had the same effect.

Is this an expected change of Kleinhans (more drag? more lift? anything that can cause more stress to lifting bodies?) Because if it is, I think I can live with trippling struts on all my SSTOs. If not I'll gladly upload my smallest test craft that has the problem.

Edited May 18, 2016 by MaxRebo

[ferram4]

@MaxRebo: Uh.. there shouldn't have been any changes to lift or drag at all.  The only changes to code are to make it compatible with Tweakscale, which should have had no affect on any of the wing aerodynamic properties.

Upload the craft when you get the chance, it'll provide something I know is getting issues.

[MaxRebo]

@ferram4Sure, here it is (stock + B9 pWings)

For some reason, when I double-checked the behavior under Kindelberger, the oscillations are almost just as bad as in Kleinhans. It  might have had something to do with me having forgotten to activate the AoA flight assistant when I tested with Kleinhans. Strange how problems start to disappear when you're forced to look at them in-depth... anyway, at the very least you'll be able to say if those oscillations are to be expected, at least under KSP's wonky physics integrator and no KJR, when subjecting that wing shape to supersonic speeds.

/edit

yep, I'm now almost convinced the problem was me derping out all along.

Edited May 18, 2016 by MaxRebo

[Mine_Turtle]

9 hours ago, ferram4 said:

@Mine_Turtle: Because of how that design is set up the vertical tails on the engine bodies will provide negligible effect at 0 angle of attack and will actually contribute to instability if the vehicle pitches below 0 AoA.  You need to either get rid of them or move them further back; there are no planes in the world that put their vertical tails in line with the center of mass because that does nothing to help yaw stability.

Thank you, I have fixed my design by moving those tailfins from engine nacelles to the tip of wing, my plane now flies rock solid at mach 4 at 20-25km.

[ferram4]

@MaxRebo: Looking at it, even with KJR fully stiffening things this design looks like it should be pretty prone to oscillation.  It's got a lot more wing parts (and thus, joints) making up the wings than need to be there, the wings are a bit heavier than they actually need to be (which leads to less damping of the wing-only oscillations that occur) and the plane itself is a bit on the heavy side overall (expected, that's a KSP plane thing) so more flex overall.  Aside from that, no issues, though I think you lack sufficient yaw stability for high-Mach number flight and this design will almost certainly have yaw and roll issues during reentry unless they are compensated for with large amounts of RCS or reaction wheels.

This is one of those planes that I'd probably fly with just the wing leveler active and leave the rest of the control systems off, just manually adjusting trim every now and then to keep it on target.  Otherwise... seems to behave as it should and needs tweaking to remove some of that behavior.

[MaxRebo]

@ferram4Thank you for taking a look. The actual plane this was made from is somewhat different; for one it wasn't actually meant to leave the atmosphere (only a few ballistic dips over 20km to get some early-mid career missions). The many wing parts near the middle in particular are there to aesthetically accommodate a few parts I removed to make it just stock + B9 pWings (cosmetics over functionality...), and the B9 engines I actually used aren't nearly as overpowered as the Whiplashes for the task. This was just the easiest plane to stock-ify.

I get no bad oscillation with 3 quantum struts per wing, which is good enough for me. I'll take a look at the wing mass anyway; I left it rather high to make the wings less susceptible to aerodynamic failure which inevitably is a thing at those speeds, but it sure seems like a worthwhile thing to tweak, so thanks for that insight.

[SpannerMonkey(smce)]

@ferram4  Back again , i have a clue this time,  I'm getting this and only this error when activating a chute

[LOG 20:24:26.026] [RealChute]: Kerbachute3 was activated in stage 0
[EXC 20:24:26.292] NullReferenceException: Object reference not set to an instance of an object
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.FixedUpdate ()

What I'm wondering is, as these chutes are not stock or derived from stock, maybe your plugin is not finding a named transform that it's looking for and so not able to activate, although they were built to the stock hierarchy canopy, base, the only change is that thru laziness the cap of the base has been cap001. Also  a couple of times a little message flashes up on the screen about deployment but it's gone so fast I can only catch a word or two     . Also noted than when using the FAR flight info screen the chute shows no increase in drag even when semi deployed, this sorta backs up my thoughts on the above( maybe). Just had another though is it the animation names??? I tend to build everything on a project per month base. with all parts irrelevant of type sharing a folder. so I usually give animations a unique name, rather than the stock animation or default Take 001 nonsense, this sounds more promising than a transform issue I think and not difficult to fix.

Edited May 18, 2016 by SpannerMonkey(smce)

[ferram4]

And now, FAR v0.15.6.5 "Knudsen" is out, with a couple bugfixes for issues.  Changelog has them, as usual.

Today's namesake is Martin Knudsen, who is primarily known for his contributions to low-pressure gas dynamics.  For aerodynamic purposes, we're primarily concerned with the Knudsen number, which is useful for determining if the flow we're looking at is a standard continuum flow (read: basically most every airflow that you've ever dealt with where there are so many molecules compared to anything else that they interact with each other so much that individual molecules don't really matter) or a Knudsen flow / free-molecular flow (read: just a bunch of molecules bouncing around not really interacting with each other much because there just aren't enough of them there), which is more accurate for the beginnings of reentry (and if it is ever implemented) orbital decay.

Edit: @SpannerMonkey(smce): well, I dunno what to tell you, this is @stupid_chris's realm.  FAR's Flight Data doesn't update the numbers based on RealChuteLite behavior (yes, I know, need to fix that at some point), but as for the actual performance... I dunno.  Thing is that it works fine for every single other parachute part, including mod ones, so the question is, "what is unique about yours compared to every other parachute in stock and in every other mod?"

Edited May 18, 2016 by ferram4

[SpannerMonkey(smce)]

@ferram4 Turns out that the only unique thing about them is the environment, I'd missed a blindingly obvious test, Do they work when attached to a craft not a kerbal and the answer is yea they do astoundingly well.  It's simply that EVA issue, so it's not me, not you(not that ever thought it was) not stupid_chris it's the damnable EVA module limitations again, so if anybody needs probe chutes these'll work, but sad to say will never work for our little green buddies, and thanks again

 

 

[Vegetal]

I need help here. Take a look at this:

See those sideways pointing arrows? This is happening to every plane i make. I normally don't trust the aero overlay, but the behaviour in-game matches what they display. Even completely level, the plane keeps yawing sideways continually because of that. Takeoff is nearly impossible.

I'm using Knudsen, and the craft is all stock parts, except for elevators which are kinda stock (Ven's revamp). I have some mods here, maybe one of them is important in this? Physics-wise, I run a 6.4x system and use Atmosphere Autopilot.

Edited May 19, 2016 by Vegetal

[Vegetal]

Update: Restarted the game, loaded the same craft in the picture above. Behaviour is normal, plane flies straight, aero overlay shows usual stuff.

Reverted back to hangar, cancelled actuation of inboard wing control surfaces (the only change). Behaviour is abnormal as in previous pic, a bunch of the plane's parts seem to generate lift sideways for no reason. Aero overlay agrees with the situation I'm experiencing.

So....something weird happened when I reverted. No idea what. Have logs: https://onedrive.live.com/redir?resid=C7155ACFE0CC3925!4150&authkey=!ACJe7-JmhBwQAao&ithint=file%2clog

[silvermistshadow]

I had some thoughts while I was riding home today. Would it be possible to make either a blended wing body or a flying wing type of aircraft or spacecraft? Then again, I guess that's not a question for FAR. It'll probably simulate and deal with them just fine if I make them, but I have to find the parts, which isn't FAR's job. I just feel like sticking this here anyways.

[MaxRebo]

@silvermistshadow People have been doing that and similar stuff by building the hull out of structural wing elements and/or procedural wings. Far from ideal (and ridiculously fiddly), but it's possible.

[taniwha]

6 hours ago, SpannerMonkey(smce) said:

It's simply that EVA issue, so it's not me, not you(not that ever thought it was) not stupid_chris it's the damnable EVA module limitations again, so if anybody needs probe chutes these'll work, but sad to say will never work for our little green buddies

Would you mind detailing this for me? PM, separate thread, or better yet, bug tracker (if there's already a bug rep, the number will do).

[ferram4]

@Vegetal: Logs are less useful than the craft file and full reproduction steps.  Provide those and I'll look at it.

[karamazovnew]

Hi Ferram, I've just started using KOS and I seem to have a problem controlling the vessel with any FAR v0.15.6.5  related control surfaces (no idea if it happened in previous versions). I'm trying to use LOCK STEERING TO HEADING(x,y) during the ascent. If I don't use any gimbaled engines, the control surfaces  twitch on all axis very fast, while the craft remains pointing up and "stable". The vessel ignores any Heading commands, both from the script and the console. With gimbaled engines added, the craft behaves normally on yaw and pitch axis, except for the roll axis which again twitches wildly, but the craft is "stable" on that axis as well. After removing FAR, everything works normally. Oh and reaction wheels work fine in all cases. 

The following log appears in all cases, no errors, nothing bad from FAR either. 

I already informed the kOS guys, but thought you might have an idea. If you want to give it a go, just make a simple rocket and input "LOCK STEERING TO HEADING (20,20)." in KOS terminal. After you launch, if the rocket stays straight instead of turning, it means I'm not crazy

Edited May 19, 2016 by karamazovnew

[ferram4]

I don't think that's anything on my end.  The physics, to the best of my knowledge, are correct.  If kOS refuses to control it, there's nothing I can do.

[cantab]

Do double-check the FAR Flight Assistant is turned off though.

[SpannerMonkey(smce)]

5 hours ago, taniwha said:

Would you mind detailing this for me? PM, separate thread, or better yet, bug tracker (if there's already a bug rep, the number will do).

Will do, though can't find anything on bug tracker relating. to this issue, not sure how to report it as a bug as it's not a stock feature. I'll send PM

[Vegetal]

7 hours ago, ferram4 said:

@Vegetal: Logs are less useful than the craft file and full reproduction steps.  Provide those and I'll look at it.

Have craft file then: https://onedrive.live.com/redir?resid=C7155ACFE0CC3925!4151&authkey=!ABkgkn1WetHZqWM&ithint=file%2ccraft
It's wildly unstable though, I use it with AA's fly by wire.

Also noticed something curious: 

Voxels are assymetric somehow.....and yeah, this happens with stock wings too by the way.

Okay then, how to reproduce: Start game, load craft. Behaviour was normal with me the first time. Revert back to hangar. Changing something on the craft may or may not influence results here. Launch again - Bug manifests itself. I also noticed something that I don't know if it's related or not, but when I manage to take off and fly (kinda) straight, even if I come in veeeeery gently for landing, the gear bounces off the runway violently, launching the plane into the air by several meters again. This doesn't seem to happen at all when I don't notice the bug happening, ultra smooth landings.

Some of the mods that may be involved: Sigma Dimensions with Kopernicus (6.4x stock re-scale), kerbalism, atmosphere autopilot, ven's stock revamp and procedural wings (maintained by crzyrdm I think). I have some more, but common sense tells me it wouldn't make sense for any of them to tamper with in-game physics.

[tetryds]

@Vegetal I know that the bouncing thing is caused by touching down with the landing gears at angle, and has nothing to do with FAR, it's strange though that you get this behavior, have you tried changing your landing gears or moving them to another position to see if the problem persists?

[karamazovnew]

9 hours ago, ferram4 said:

I don't think that's anything on my end.  The physics, to the best of my knowledge, are correct.  If kOS refuses to control it, there's nothing I can do.

Well, to quote the kOS authors:

Quote

FAR changes the aerodynamic properties of the game, and we currently do not directly support FAR.  All of our steering calculations are based on KSP's new `ITorqueProvider` interface, so FAR would need to replace the control surface module with it's own module providing FAR specific torque calculations in order for kOS to accurately control with it. 

So that's that. Anyway, solved it by copying the basic canards and giving them another name, so that FAR leaves them stock. Seems to work fine, but I'm not sure how much I'm loosing physics wise. In your opinion, would it be better to force the new parts to use the FAR model (but the stock control)?

@PART[kOSAdvancedCanard]:AFTER[FerramAerospaceResearch]
{
	@maximum_drag = 0
	@minimum_drag = 0
	@angularDrag = 0
	MODULE
	{
		name = FARWingAerodynamicModel
		MAC = 0.93122
		MidChordSweep = 37.044		
		b_2 = 1.7904
		TaperRatio = 0.139074
	}
}

So i'm leaving the stock deflectionLiftCoeff, ctrlSurfaceRange and ctrlSurfaceArea as stock, while using your FARControllableSurface module parameters for a FARWingAerodynamicModel module. This seems to work but I'm not sure if I'm breaking anything. Is it ok? Or should I just leave them stock? 

EDIT: Oh and...

@dragCoeff = 0
@deflectionLiftCoeff = 0

In stock they sit in the ModuleControlSurface so I thought I might not need to touch them? Or should I zero out them as well?

Edited May 19, 2016 by karamazovnew