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

[Naten]

Is relaxed stability a good idea for a maneuverable plane? I've tried it and even with AoA limits on many different values it's too uncontrollable to be practical.

To increase maneuverability on a stable aircraft, can I just increase wing area so it brings the prograde vector towards the nose's position faster? I'm working on fighter planes right now, so tips would be much appreciated!

[ferram4]

@Gigeran: I can reproduce the exception, but no crash. I suspect the crash is from something else in your install, not FAR, because exceptions being thrown shouldn't cause crashes.

Edit: Fixed in dev build, still dunno what the crash is about though.

@steve_v: And every time I update there seems to be a new CKAN screwup with metadata or with figuring out the version number... I think it's safe to just treat it as permanently broken rather than hope it doesn't screw up.

@Naten: Relaxed stability is a good idea, but outright uncontrollable instability isn't. There's a fine line there.

Edited July 25, 2015 by ferram4

[MugWanaBe]

Ferram I am running the latest versions I was just using the older post for reference. Anyway at about 4800 meters 257ms and mach .7ish makes and un controllable turn putting the rocket on its side and braking apart in the proses. The SAS can fight past the flip a 100ms but you can see an the navball an the way the thrusters gimbal that the rocket is swaying in a mall circle around the prograde marker. If I touch the controls to try to fix the swaying the rocket will make a large turn an put the vassal an its side. But the rocket can get through the swaying by gong straight up but as listed above at 257ms the goes to its side an breaks up. There seems to be a large amount of drag on the side on the rocket that the shorter tank extension is on. If there is a fix for this I am not smart enough to figure it out on my own. That is why I bring up post #2352 because it seems to house a fix to this problem but I cant figure it out.

Thanks

[Ralathon]

Ferram I am running the latest versions I was just using the older post for reference. Anyway at about 4800 meters 257ms and mach .7ish makes and un controllable turn putting the rocket on its side and braking apart in the proses. The SAS can fight past the flip a 100ms but you can see an the navball an the way the thrusters gimbal that the rocket is swaying in a mall circle around the prograde marker. If I touch the controls to try to fix the swaying the rocket will make a large turn an put the vassal an its side. But the rocket can get through the swaying by gong straight up but as listed above at 257ms the goes to its side an breaks up. There seems to be a large amount of drag on the side on the rocket that the shorter tank extension is on. If there is a fix for this I am not smart enough to figure it out on my own. That is why I bring up post #2352 because it seems to house a fix to this problem but I cant figure it out.

Thanks

Sounds like your rocket is just aerodynamically unstable. So not a problem with FAR, but a problem with your design. Put some fins on the bottom and make sure the center of lift is close to the center of mass in the VAB

[blowfish]

Center of lift is meaningless in FAR.

[ferram4]

@MugWanaBe: There is no fix, this is all proper behavior, and the ancient post has a fix for very, very abnormal behavior from an ancient version of FAR. This is why you should never use 2 year old posts as reference for something in active development, because now you're confused and looking to implement a fix for a system that doesn't even exist anymore. That fix was implemented for the drag system in FAR v0.12, before all of that system was ripped out in favor of the current voxel-based system.

For now, you need to use active control to maintain stability. Everything is being simulated correctly, you simply need to adjust and handle it.

[Amedee]

While I completely understand Ferrams stance on CKAN, after a bit of wrangling with it there's only one major issue I can see: CKAN doesn't clean up old files or directories properly (specifically when files are created after install), which can confuse ModuleManager horribly.

So make sure you completely remove mod directories on uninstall/reinstall - manually.

If you're having issues with a CKAN installed FAR, wander over to the appropriate thread. I'm seeing far less than the expected traffic volumes over there.

Also, be aware that you may still experience issues even with a manual FAR install - if you have other mods that were installed/uninstalled via CKAN.

Your best bet for getting in on the support racket here is to reproduce your issues in a simple stock+FAR install, no CKAN in sight.

I have my entire KSP directory in Git, so it is *extremely* easy for me to compare different versions of files.

I had FAR installed with CKAN, version 0.15.4. I uninstalled that and then made sure that the directories FerramAerospaceResearch and ModularFlightIntegrator were gone. Then I installed FAR 0.15.4 manually, from a zip file I downloaded from kerbalstuff. Finally I did a git status, to see if there were any changes. Result:

amedee@kerbol:~/Games/KerbalSpaceProgram$ git status 
On branch develop
nothing to commit, working directory clean

This means that, at least for FAR 0.15.4 and at least on my machine, CKAN FAR and manual FAR are identical.

I understand that this may have been different in the past and that it may be different again in the future, but as far as current evidence tells me, the two ways of installing FAR are byte-per-byte identical.

- - - Updated - - -

@Amedee: Need reproduction steps and craft file, along with full list of all mods. If any of this involves CKAN though, I can't help you; CKAN is known to cause installation issues with FAR and possibly other mods, so there's no support for CKAN users here.

I just spent a day replacing over 200 mods from CKAN installation to manual installation, and verifying that the CKAN and manual installs were identical. They were - verified with git status because I have my entire KSP directory in Git. The only differences are config files that are created after install, but I also have them under version control so rollback is trivial.

Steps to reproduce: I hope this Youtube vid is ok:

Craft file: http://pastebin.com/Te24hv6g

Full list of installed mods, as exported from CKAN before I reinstalled them manually: http://pastebin.com/R7eP6RfY

That was the easiest way to also get the version numbers. To be very clear: my current KSP install is CKAN-free. Or to be precise: CKAN is in my master branch and CKAN-free is in my develop branch, and I can now switch between the two with a simple `git checkout`.

[taniwha]

amedee@kerbol:~/Games/KerbalSpaceProgram$ git status 
On branch develop
nothing to commit, working directory clean

This means that, at least for FAR 0.15.4 and at least on my machine, CKAN FAR and manual FAR are identical.

I understand that this may have been different in the past and that it may be different again in the future, but as far as current evidence tells me, the two ways of installing FAR are byte-per-byte identical.

That test is valid only if you ran "git status" before committing the changes from installing FAR. "git status" tells you only whether you have uncommitted changes.

A more correct method would be:

1. Install FAR via CKAN.
   
2. Commit changes to git.
   
3. git tag far-ckan-install
   
4. remove all FAR and FAR dependency files and directories.
   
5. commit changes
   
6. Install FAR and its dependencies by hand.
   
7. commit changes
   
8. make sure FAR is working fixing anything you missed and commiting along the way
   
9. git tag far-hand-install
   
10. git diff far-ckan-install far-hand-install
    

If "git diff" comes up blank, then you know there are no changes.

[ferram4]

@Amedee: First, the craft you linked is not the craft from your video; I can't even get it to lift off the pad. Second, the behavior in the video is behavior that has never been caused by FAR; the camera moving away from the vehicle above 6 km implicates another mod. FAR may be the cause of everything flying apart during staging, but the camera indicates that something else breaks first and is the true initial cause of any issues. Work through your mods and find that one, because FAR doesn't do anything different at the 6 km origin shift.

Also, I don't particularly care whether any individual CKAN install is identical to a manual installation; one correct installation is not proof of future correctness, especially considering that several months of it correctly installing FAR didn't prevent it from screwing up so royally lately.

[Mekan1k]

Hey Ferram,

Is there a point at which you expect FAR to be able to work independently of cfg file edits? I ask because a few of my favorite mods don't have FAR configs.

[blowfish]

Hey Ferram,

Is there a point at which you expect FAR to be able to work independently of cfg file edits? I ask because a few of my favorite mods don't have FAR configs.

The only thing that definitely requires custom FAR configs at this point is wings.

[Mekan1k]

The only thing that definitely requires custom FAR configs at this point is wings.

Exactly! Any plans to phase that out? Eventually?

[ferram4]

In an ideal world, it would already be gone. The problem is getting the computer to properly classify what is and isn't a wing and get all the geometric data from it, and do it all perfectly. This is basically aero-DeepDream, that has to be perfect, and run fast. This is obviously probably not going to happen soon, if ever. If it was a nice, simple problem, it would be long, long gone.

And even if something like that worked, it would be imperfect and probably require some amount of configs to deal with those situations.

[Drew Kerman]

And even if something like that worked, it would be imperfect and probably require some amount of configs to deal with those situations.

Ferram is the Wiki tutorial on wing data still accurate? I haven't done anything for 1.x.x yet so I'm unsure. Since it's understandably not feasible to have FAR handle wings automatically anyone looking to do wing configs should be pointed to the wiki. If it's not up to date though...

[ferram4]

It should be, the config definitions haven't changed in a long, long time.

[sashan]

Well, here am I again with revoxelization problems.

I don't have a very powerful processor, so the procedure is quite noticeable in form of small stuttering. It isn't an issue with one craft, but when I have a full scene with BDarmory... Like 10 missiles, two planes, 5 ground vehicles and such, it becomes a pain.

So, small suggestion: Decrease frequency of update significantly for one-part ships, it would increase performance for those missiles, and debris.

Also, maybe it would be easier to check for part positions change being in certain marigin and animation states not changed and then abort revoxelization? Should save some cycles.

[Gigeran]

@Gigeran: I can reproduce the exception, but no crash. I suspect the crash is from something else in your install, not FAR, because exceptions being thrown shouldn't cause crashes.

Edit: Fixed in dev build, still dunno what the crash is about though.

Thank you and I will try to trace it further.

Tried removing infernal robotics, tac, alarm clock, etc. before I posted here.

Probably your error report is the only one catching something happening somewhere else earlier on.

[ferram4]

@sashan: I see no voxelization problems in your report; those are all things that need to be done to simulate aerodynamics. It already delays 600 ms between updates on the same vessel, I don't see how I can increase that any more without basically giving up on any attempt at actually simulating aerodynamics. None of this should even be a problem at all; you will only have revoxelization during missile launches (required to get changes in aero due to changes in external loadout) or during vehicle animations (required unless we've decided that swing wings shouldn't affect aerodynamics). Anything else won't happen unless another mod forces FAR to re-voxelize more often, and at that point it's out of my hands.

[natan]

hey, im getting some inconsistent ablator usage, about the same periapsis on two reentriess, one from low orbit, other from mun return, two slight different vessels, the mun one with some universal storage modules between capsule and heat sheild, and the heat shield was the stock one, while on the low orbit, i used the heat shield that comes with the corvus mod, i dont think that this is the problem because heat shields use the ablator resource, which is the same for both. So, on the mun return, i got 0 usage, thats right, pretty much a bug, on the low orbit i got about 98% usage, on others reentries, mostly low orbit, i got about 10% to 20% usage. The only mod that changes physics that i have installed is far, every other is parts or utilities, i always use around the same periapsis on my reentries and the vessels most of the time are capsules only, with one or other experiment part.

[ferram4]

You're trying to compare two completely different parts that likely have two completely different thermal masses and ablator configs. Of course they're going to have different usages; this doesn't sound like a bug anywhere in FAR, if it's a bug at all.

[Sady1969]

I'm interested in learning more about how FAR calculates drag in subsonic flight. How can I find out quantitatively how much drag is coming from "short and fat" vs "long and thin", how much from changes in surface area etc?

[nimaroth]

Hi Ferram !

First, let me thank you for your mod ... it's really well done !

Now, the issue at hand ... I've actually some troubles with a rotor engine for chopper. After talking with Blowfish, I've made another set of test with your latest dev version but sadly, not the result expected.

The engine is from KAX pack. I used KAX, AJE and of course FAR, AJE and FAR with the last dev version.

The engine name is Bell UH-1 Huey Engine&Rotor. And now, the steps :

- Activating SAS

- Activating the engine

- Cutting the engine with [X]

=> Sent to space

Messages from the log (those messages are repeated endlessly) :

[LOG 19:51:20.349] Look rotation viewing vector is zero

[LOG 19:51:20.350] Look rotation viewing vector is zero

[LOG 19:51:20.350] Look rotation viewing vector is zero

[ERR 19:51:20.353] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.353] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.354] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.354] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.355] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.355] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.356] Actor::setAngularDamping: The angular damping must be nonnegative!

[ERR 19:51:20.356] Actor::setAngularDamping: The angular damping must be nonnegative!

[EXC 19:51:20.357] ArithmeticException: NAN

System.Math.Sign (Double value)

SolverEngines.EngineThermodynamics.FromChangeReferenceFrame (SolverEngines.EngineThermodynamics t, Double speed, Boolean forward)

Second test :

- Activating the engine

- Cutting the engine with [X]

=> No trouble

Hoping it'll help ! (I have notified all three mods concerned)

[ferram4]

Looks like it's entirely under AJE, (or technically, the SolverEngines dependency), because that's what the error points to.

[blowfish]

That method will only throw an exception once speed is already NaN. I was able to replicate the black screen, but it seems to be fixed after adjusting AJE's wildcards.

[natan]

ok sounds silly compare the two now looking the configs, but, by it self the mun return reentry with zero ablator usage doesn't look strange?