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

[Kitspace]

True, avoiding stalls using the stability assistant does make sense. But this does not contradict the fact that it looks more like a stability issue in this case rather than stall modeling.

Unrecoverable or hardly recoverable loss of pitch control would certainly mean going in a deep stall or a flat spin for a real life plane but it does not necessarily mean that in the game.

Which again goes to the point that kerbal airplanes resist entering stalls and spins even when they are otherwise unstable. Even though that in the real life less statically stable planes spin much more eagerly than more stable ones.

In fact from my experience in game less stable planes are harder to stall properly because they pitch up higher before the pitching moment jerk and as a result bounce back down more aggressively.

Edited May 16, 2016 by Kitspace

[cantab]

Could that discrepancy be down to the reaction wheels? A Mk1 cockpit offers 10 kilonewton-metres of torque. That's equivalent to a one ton weight hanging off a 1 metre lever arm trying to turn the plane around. I know from experience that aerodynamic forces often do overwhelm reaction wheel torque, but nonetheless it's gotta count for something when it comes to post-stall control hasn't it?

[JtHermit]

I am playing with Realism Overhaul (so reaction wheels are useless) and Kleinhans makes aircrafts completely unplayable.

Rolling back to the Kindelberger.

[ferram4]

@cantab: Confirmed, and you've been drafted: test it with this dll and see if the issue still occurs.  Everyone else with the issue should also check because the sooner I get confirmation it works the sooner I can rush out an update.

[blu3wolf]

A smart enough autopilot assistant should be able to get out of a stall anyway... depending on the stall and craft I guess.

[cantab]

8 hours ago, ferram4 said:

@cantab: Confirmed, and you've been drafted: test it with this dll and see if the issue still occurs.  Everyone else with the issue should also check because the sooner I get confirmation it works the sooner I can rush out an update.

Confirmed that this restores familiar behaviour for my aircraft. Graph screenshot if you need it: https://flic.kr/p/GhBpfW

 

[SpannerMonkey(smce)]

Hi guys, I have a question, I'm not a FAR user myself, so I know very little about the depth of effect  this rework has, but a lot of players who use my mods are.  I've just thrown together an EVA parachute mod, nothing flash, just piggy backs on KIS, and several of the players who have tried it in FAR equipped installs  have reported the chute not fully deploying,  Whereas it deploys perfectly in my FAR less game. SO in an effort to nail down the issue( not pointing any fingers here) , does FAR effect parachute behavior? From my reading of the thread I'm surmising that if you can fly a brick, Far effects everything.   If Far does effect chute performance is there a way to make them compatible? If it doesn't thanks for your time

[Jim DiGriz]

On 5/15/2016 at 10:17 PM, ferram4 said:

FAR v0.15.6.4 "Kleinhans" is out.  Bugfix release, plays nice with Tweakscale, fix some drag issues.  Changelog has info, as always; have fun with it.

I think I picked this release up this morning.  With DRE it appears that everything got a bit more explode-ey.   With my gravity turn script I used to be able to accelerate at 49,000m to raise my Ap to 200,000m without overheating, and today at that velocity things go boom.  Don't know for certain it is this FAR update that is responsible (I have lots and lots and lots of other mods), but is that expected/desired behavior of the drag tweaks?  Based on what I'm seeing I imagine aerobraking also got a lot more exciting and people will need to adjust their typical periapsis upwards.  I've been updating once or twice a day and DRE hasn't had a release and nothing that came by recently 'smells' like it would have caused this change, but I can dig into it more if necessary...

(and i'm playing with stock sized kerbin and not with Real* mods).

EDIT:  it looks like my delta-V to orbit also dropped precipitously.   I had tested before that clamping Max-Q didn't matter, so I was just punching it at like a launch TWR of 2.5 at full throttle and not worrying about drag -- was that a bug that just got fixed?  It did seem to violate my physical intuition...

EDIT2:  yeah, i'm hitting max Q of almost 70 kPa and drag of almost 200 kN now.  max Q looks similar to prior release, i don't recall what numbers i was getting for drag.

EDIT3: mods that were updated:  EditorExtensionsRedux, KerbalKonstructs, CommunityTechTree, MagicSmokeIndustries, FerramAerospaceResearch

Edited May 16, 2016 by Jim DiGriz

[hyf97ca]

I collected some pictures of interesting behavior in FAR Kleinhans, with and without the new DLL. The center of mass seems to unexpectedly shift off-center when placing wings in VAB. Upon launch, the rocket does turn by itself in the direction of the red arrow provided by RCS build aid, so I believe that the information that the mod provided is correct. The same rocket is in all the pictures. Craft file

I do have mods installed. The only ones that change physics are Claw's Stock Bug Fixes + Stock Plus, and FAR.  I don't think Claw's fixes changes the center of mass though, unless the body lift fix jams with FAR code or something.
If this seems like a promising lead, I can try reproducing this with a clean install.

[silvermistshadow]

I'm still in the previous version before this latest one, and I appear to be having minor issues with one of the stock FAR craft. The FAR Firehound MS, namely. I'm sure it works great in flight... but unfortunately, upon spawning on the runway, it immediately falls over onto its side. To be more precise, it falls forward-left. Naturally, when I launched again to take a screenshot, it took a bit longer to do this, because my computer likes to have weird issues that no one else has and generally toy with me. 

I did change the insides of the fuel tanks (removed all oxidizer, put in more liquid fuel because I have Modular Fuel Tanks and can do that), but since the actual mass didn't change, I don't think it would affect much. 

 

I tried to just turn on the engines straight away, but then it just fell forward-right instead. 

 

Edited May 16, 2016 by silvermistshadow

[cantab]

@silvermistshadow can you reproduce the issue in only stock KSP + FAR? If not, I suspect the evidently modded runway you have is contributing to the problem.

[silvermistshadow]

23 minutes ago, cantab said:

@silvermistshadow can you reproduce the issue in only stock KSP + FAR? If not, I suspect the evidently modded runway you have is contributing to the problem.

Possibly, yes. I do have some things that add bases. I will go ahead and try again after uninstalling most of the mods I have on CKAN- the others are AD, and I think there's only two, including FAR naturally, since I didn't want to be sent to the other thread. There's 111 mods on CKAN though... Wish there was a button for 'uncheck all of the boxes'. The other manually installed thing is called modular flight integrator. I think it's somehow related to FAR, but I'm not sure.

 

Uninstalled the CKAN mods, then had to delete folders and other stuff it left around. Now all that's left in there is 'FerramAerospaceResearch', 'ModularFlightIntegrator' and 'Squad'. As well as a wheeldeploypatch.cfg. I'll try it out in a bit here, should take a lot less time to load with just this. Also just put back in module manager since it was in FAR's stuff; I keep manually installed mods in a safe area so that I can always grab anything I need out of them. 

 

Test results: It definitely looks like something else was causing it. While the vessel did still have a minor tilt toward one side or the other, that just seems to always be there in everything that I ever fly. Even stock without mods, it's just kind of there.

 

Incidentally, the runway in the above picture isn't even KSC either. Now I get to wonder if it will do the same thing at KSC when I put all the stuff back... eventually. I think I'll go with a lesser amount this time. 111 mods was kind of crazy. Initial loading of the game would take 5 minutes or so when I had that many, and general instability was a thing.

Edited May 16, 2016 by silvermistshadow

[longhornchris]

11 hours ago, cantab said:

Confirmed that this restores familiar behaviour for my aircraft. Graph screenshot if you need it: https://flic.kr/p/GhBpfW

 

@ferram4 I can confirm this fixes the issue I was having with the Mk1 cockpit.  Aircraft behaves like it did in the previous version.

[ferram4]

@SpannerMonkey(smce): Yeah, it's probably that.  In the process of turning off stock's strange dragcube implementation, FAR breaks all parachutes, so it introduces its own RealChuteLite to replace it.  You could either attempt to write a config to convert the parachute over (poking @stupid_chris) or apply the forces directly (given the way stock parachutes work, this is probably better).

@hyf97ca: Confirmed and will be fixed in the next FAR build.

[Benmush]

Hey Modder,

It appears that FAR is modelling drag on the attachment nodes for PF. 

I clean installed KSP 1.1.2, installed PF, all working fine. Installed FAR and attachment nodes start to cause drag.

Tried the previous version of both mods and the problem is still present. I don't have an older version of KSP to test, sorry.

 

[SpannerMonkey(smce)]

9 hours ago, ferram4 said:

@SpannerMonkey(smce): Yeah, it's probably that.  In the process of turning off stock's strange dragcube implementation, FAR breaks all parachutes, so it introduces its own RealChuteLite to replace it.  You could either attempt to write a config to convert the parachute over (poking @stupid_chris) or apply the forces directly (given the way stock parachutes work, this is probably better).

@hyf97ca: Confirmed and will be fixed in the next FAR build.

Hi , now i've installed this version of FAR i can see exactly whats happening, and without a doubt I'd rather have the chutes compatible than not.  

   I've tried derailing the MM procedure by creating a final; and switching the Farrealchute back to the original module, not the ideal fix, , needless to say this has not been altogether successful , So if some kind chap more familiar with the RealChutes and FAR's application of them could give a few pointers as to possible fixes I'd be very grateful, (and so I believe will  the the bereaved families of the many hundreds of Kerbs who have passed away during tests, help stop the slaughter)

[Svm420]

On May 8, 2016 at 4:49 PM, Svm420 said:

@ferram4

Figured out another "issue" with B9 Pwings. No tweakscale involved this time promise . It seems FAR takes the basemass from the part config, I.e. 50kg, and uses that as the mass it increases and decreases. So no matter how small and how low I tweak the wing strength slider they have a base 50kgs. I think that seems rather absurd for wings on a model rocket to weight an excess of 100lbs! So we can either ask the B9 maintainer to change mass in the cfg to 0, or rather insignificant amount like .001 in the presence of FAR simple, we(you) can make some changes to FAR code or we can have 100lb model rocket wings if we do nothing. For now I rolled option 1 myself will keep an eye out for any oddities. Thanks!

This was can be tested with latest dev Far and latest release b9wings.

1 Go into VAB place mk1 pod.

2 Attach b9 wing in default shape.

3 check total mass before and after wing note total of 805kg difference.

4 check FAR slider for current wing mass reads ~755kg

50kg difference  tweak it as small and low as the slider will go note total mass of at least 50kg.

@ferram4 Still think this still not possible  . 

[ferram4]

@Benmush: There is no code in FAR that applies drag to parts based on attach nodes, especially not for procedural fairings.

@SpannerMonkey(smce): Yes, switching the module back to the stock module doesn't work because, as I mentioned, FAR turns off the dragcube model completely, thus breaking that module.  That's why there's a RealChuteLite module to begin with; prior to KSP 1.0 FAR just left the default parachute model alone because it worked well enough, but that doesn't work anymore.

Looking at your mod, I don't see any reason why it would not work as is.  Replacing the ModuleParachute with a RealChuteLite module should work fine and it should have the proper behavior due to the fact that it appears to be completely identical to stock modules.

@Svm420: Yeah, I found that.  This is what I get for assuming part.prefabMass would always have a valid value, even in PartModule.Start().  Never assuming that again.

[SpannerMonkey(smce)]

@ferram4 I couldnt see any obvious reason why it will not work, that's why I came here .  So I'm baffled , I see that there is nothing to tweak in the RealChuteLite.cfg presumably it's all hard coded?.  The only other thing i can think of, that I have encountered elsewhere is that for some reason that set of modules does not play nicely with KIS EVA parts, it certainly isn't unusual, but it is sad..  Unless it's just a bleepin fluke that they work in the first place.  Thanks for sparing some brain power for it though, much appreciated

Edited May 17, 2016 by SpannerMonkey(smce)

[Benmush]

6 hours ago, ferram4 said:

@Benmush: There is no code in FAR that applies drag to parts based on attach nodes, especially not for procedural fairings.

@SpannerMonkey(smce): Yes, switching the module back to the stock module doesn't work because, as I mentioned, FAR turns off the dragcube model completely, thus breaking that module.  That's why there's a RealChuteLite module to begin with; prior to KSP 1.0 FAR just left the default parachute model alone because it worked well enough, but that doesn't work anymore.

Looking at your mod, I don't see any reason why it would not work as is.  Replacing the ModuleParachute with a RealChuteLite module should work fine and it should have the proper behavior due to the fact that it appears to be completely identical to stock modules.

@Svm420: Yeah, I found that.  This is what I get for assuming part.prefabMass would always have a valid value, even in PartModule.Start().  Never assuming that again.

Thanks for response, however something strange is going on and only occurs once FAR is installed.

The below screenshot shows Stock KSP with just PF installed. You can see the little blue spike in the center showing the attachment node for the fairing and it does not change from launch to thundering through the atmosphere.

As soon as I install FAR the following drag is applied to those node points, making the craft flip around them, barley able to keep control. The other vessel drag vectors are obviously expected.

Any help will be much appreciated.

BTW: The voxels all look good when editing the craft as shown below.

Edited May 17, 2016 by Benmush

[tetryds]

@Benmush That is a known issue, there is no real drag, only the dreag indicators displaying data incorrectly for occluded parts, disregard them.

Your rocket is unstable, btw.

[Benmush]

Just now, tetryds said:

@Benmush That is a known issue, there is no real drag, only the dreag indicators displaying data incorrectly for occluded parts, disregard them.

Your rocket is unstable, btw.

That makes perfect sense, thought I was going made!

Yep, rocket is gash just to highlight issue, amazing how stock aerodynamics are so lame.

IMO. FAR, RSS, RO and RP-0 = Simulation ELSE Fail

[ferram4]

@Benmush: The fairing is made up of 4 parts, right?  And there are 4 drag/lift arrows attached.  So that means that each of those arrows accounts for 1/4 the drag o the fairing and has nothing to do whatsoever with attach nodes.  Internally that's probably an issue, but if that problem doesn't show up with the latest FAR dev build then that has already been fixed.  It's just waiting on confirmation that that doesn't happen anymore so that I can actually make a stable release.

@tetryds: No, this is correct.  Please don't repeat incorrect information.

[Mine_Turtle]

I am not sure if it either mod related issue or just my poor design skills however my new ssto can hardly make past 10km from Kerbin. All of the parameters from static and dynamic analysis in FAR seem to be ok, however at around 10km my plane falls into sideslips and dies to aerodynamic failure. I have also tried running simulation analysis and according to it with specified parameters any lateral movement causes divergent oscillations. I am not sure if I can trust the simulation though, as my other plane(a small jet plane) manages to recover from sideslips rather well and flies solid, although simulation again shows divergent oscillations.

Here are some images of the plane and corresponding parameters when RUD happens:

http://imgur.com/a/ZdKgV

I can provide craft file to anyone who wants to have a closer look, but note that I use a lot of parts from different mods: KSPI, IR, B9 and Tweakscale.

I run latest FAR release with new dll.

[MaxRebo]

@Mine_TurtleI'd try reverting to 0.15.6.3 Kindelberger. Kleinhans has completely borked every single one of my planes (which always worked flawlessly through many FAR iterations up to that point), and I have yet to figure out what to do differently to make them work with the new FAR. The dev dll didn't change a thing for me. If your plane works in Kindelberger, then that just means like me you'll have to learn FAR all over again.