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

[ferram4]

@Gordon Dry: Everything in there appears to be correct.  It looks like you have a lot of constant animations occurring on your vessels, which triggers a revoxelization.  No issue here.

@Bookstore44: 1) Fins in the front of a rocket with mass behind is unstable in FAR, as it should be.  Note that wings do not have the same aerodynamic behavior as not-identical shapes.  Note that the main source of low stability on your second craft (with the structural panels at the back) is due to the body lift created by the nose of the craft.  On the version with the structural panels at the front the increase in cross-sectional area near the front of the vehicle produces a stabilizing pitching moment, like on command pods.  In both cases the overall vehicle is only barely stable / unstable, which is why you can see a noticeable change with such a small cross-section adjustment with the structural panels.

2) FAR Flight Data has it in flight, Stability Deriv tab has it in the editor.

[ss8913]

Noticed something new... not 100% sure it's FAR or if it's a stock bug.  Note that I'm not using any wind/weather mods as there are none certified for 1.1.x yet.  I've had several landings now where, once stopped on the runway and MJ2 says 0.0m/s surface speed, my navball still says something between 40-65 kts EAS.  This is new behavior, but now I'm not sure if the airspeed indicator might be reading too high in flight as well, causing incorrect approach/stall speeds to be used.  ~50kts makes a big difference on approach

[Gordon Dry]

5 hours ago, ferram4 said:

@Gordon Dry: Everything in there appears to be correct.  It looks like you have a lot of constant animations occurring on your vessels, which triggers a revoxelization.  No issue here.

I used 4 IR extendatrons with OKEB-500 at the ends but they were only fully deployed after I reached a minimum periapsis of 400 km - could it be that they sway in a hardly visible minimal way?
The probe's engine does not provide enough TWR to make them bend in a hard way but of course an acceleration could make them bend slightly and sway afterwards...

But if there is no dynamic pressure because there is virtually no air (there is no air, but scientifically the Earth atmosphere goes up to 10,000km) why does a revoxelation occur?

 

Edited May 31, 2016 by Gordon Dry

[starikki]

18 hours ago, Van Disaster said:

Crzyrndm has a mod called "Dynamic Deflection" which will do the second part of that - you might find you want a little more than just Q involved though, seeing as high altitude supersonic flight & low altitude subsonic will share Q figures.

I had a go at it, partially solved the problem. but yes you are right, we at least need deflection scaling by Q as well as Ma at least,  may be PID gain scaling as well to make it even better.

So far for the same control input behavior, say via BDA AI in air combat, there's PIO on high speed due to high Q, but lower max AOA achievable due to increased stability margin at higher Ma;
With same AI input at low speed however, it would cause the aircraft to stall easily due to lower pitch damping and lower stability margin.

We had a BDA AI air combat competition within a fan community, I have to limit the useful g limit a lot lower than the aircraft's actual limit to avoid low speed stall issue, would be great if we have more control scaling setting on each control surface.

=============================================

Dear @ferram4

Could you please, if possible, at your convince,  add a deflection scale setting for Q and Ma on each control surface? 

This would greatly increase the realism of the simulation on S&C side, and help people design more realistic aircraft.

It will be four more input on the control surface setting panel (base Q, Q scale factor, base Ma, Ma scale factor), so that we can run many aircraft on the same competition with their own settings.

Many thanks!

[ferram4]

@ss8913: Never seen it; I need full reproduction steps then.

@Gordon Dry: No, it is not due to swaying.  No revoxelization occurs on swaying.  It is that the parts continue animating, and the animations require a revoxelization because they could indicate large changes in the craft shape.  Alternatively, another mod is continuously forcing FAR to revoxelize.  In either case, FAR is doing exactly what it should do in this scenario.

As for why it happens even in space, 1) needed for reentry when that starts and 2) also handles radiative heating / cooling.

@starikki: Not happening at any time in the foreseeable future.  For one thing, 4 numbers will not properly model what you want and will likely introduce lots of confusion.  For another thing, the right-click menu is already bloated for FAR control surfaces.  For another, there is no easy way to create the full curve variation that I'd rather use.  Until those can be solved, nothing is being implemented in FAR.

[tetryds]

@starikki I would personally rather if that was never implemented on FAR, it's out of the scope of the mod and a problem with the AI controller rather than the aerodynamics model.

Also, the pitch rate scaling is based on Q/v, so they should scale together through a constant. Another problem would be saving those settings per craft since FAR module applies to the vessel rather than a part.

I did suggest that this scaling gets applied to BDA but since the development stopped we will have to wait.

[Van Disaster]

@starikki: believe me I've spent many many hours tuning BDA with DynDeflection for contests, but it is really a control issue & not a craft issue. It'd be nice if there was some sort of common FBW API that people writing control/automation mods could use so you could set a craft's performance envelope up in one & all the other mods would use it, but for now what we have is enough for usual BDA dogfighting at least - I had one fight in the last big contest which went from sea level up to about 9km, but usually they don't drift vertically all that much.

[habix]

On 5/29/2016 at 10:05 PM, ferram4 said:

@habix: FULL log, not snippet.  I need to have EVERYTHING.

Does it work without Remotetech, but still with BDB?  Does it happen with any other part in any way?

@AccidentalDisassembly: Confirmed, I know what's causing it.  Stupid fix that I had to add to fix a bug introduced in part transform layers for KSP 1.1.2.

Yes, it worked without Remotetech. Also it worked without CLS but with RemoteTech installed.

I did have some trouble reproducing error consistently after a clean install.. so I didn't wan't to bother you with half logs. 

Anyway the CLS author did say he found out why NRE is raised/how to handle it and he will have a fix soon (right now I'm not using CLS and everything works fine with FAR). I'll let you know if I have some more SOLID info (if NRE fix in CLS also fixes FAR in combination with all this mods).

[ss8913]

18 hours ago, ferram4 said:

@ss8913: Never seen it; I need full reproduction steps then.

@Gordon Dry: No, it is not due to swaying.  No revoxelization occurs on swaying.  It is that the parts continue animating, and the animations require a revoxelization because they could indicate large changes in the craft shape.  Alternatively, another mod is continuously forcing FAR to revoxelize.  In either case, FAR is doing exactly what it should do in this scenario.

As for why it happens even in space, 1) needed for reentry when that starts and 2) also handles radiative heating / cooling.

@starikki: Not happening at any time in the foreseeable future.  For one thing, 4 numbers will not properly model what you want and will likely introduce lots of confusion.  For another thing, the right-click menu is already bloated for FAR control surfaces.  For another, there is no easy way to create the full curve variation that I'd rather use.  Until those can be solved, nothing is being implemented in FAR.

I'm reproducing it by flying and landing a plane.  Happens every time... EAS is nonzero stopped on the runway after flying a plane.  If it's a mod conflict though, that'd be.. harder to debug since you'd need my entire mod list.

[ratchet freak]

On 30-5-2016 at 5:34 PM, kcs123 said:

Unfortunately, no, in this case does not help. At least not with my case that i encountered. For some reason, some part on craft is not voxelized properly, although, voxelization looks fine to me when displayed. "Bad" info happens as soon as I load craft in SPH, when just started to play game. You can wait forever, but graph will look always the same.

When you attach/de-attach something on craft, you get proper data on graph. For things to be even more strange, it happens only with craft that have high AoA stall angle, above 25 degree. On crafts that have lower, less insane AoA stall angle, it behave as expected. Things happen quite randomly when you get good or wrong data, so it is hard to enlist proper reproduction steps.

Without proper reproduction steps it will be nearly impossible to fix bug. It is better to spent time and effort to write wing overhaul code and chase down same bug if it persist after new wing code. It is more/less easy to get workaround of this bug, does not influence craft behaviour in flight at all, have to learn to live with it for now.

That's looks like a cache issue, especially when an invalidation (moving a part and forcing a revoxel) "fixes" it.

 

I'm  talking about when you go to run the analysis while the background voxelizer thread is still busy. @ferram4's statement implied that the analysis code will pull incomplete data and try to analyze that even though that makes no sense to do.

[ferram4]

@ss8913: Nope, nothing.  0.0 m/s EAS on the runway after taking off, flying to 5 km, and returning to the runway.  Even more confusing is that there is no mechanism in the code for there to be any constant error at all.  The air/water density is multiplied by vessel.srfSpeed, so that would imply that vessel.srfSpeed is wrong, or the air/water density is way, way, WAY wrong.  Post a stock craft that causes the issue.

[larkvi]

What are people's current best-case dV expended to LKO for rockets using FAR? I am trying to automate some repetitive launches with MechJeb and tune my ascent profile, and I cannot seem to get much below 3300 dV expended to 80x80km. I know some stock players are expending as little as 2900 dV, and I wonder if the 300-400 dV are something I am dropping in my design or just what FAR takes. If you have a craft that makes it with significantly less, would you mind sharing it with me so I can see where my design is falling down?

[Buisson]

Hello !

First thanks a lot for this mod, I wouldn't play without it

I have a problem with the Center of Lift, it does not show correctly in the VAB, and when I launch the vessel, I can clearly see that the CoL is on the top of the rocket (lots of wiggle, cant make it after 20km without breaking apart).

So I uninstalled FAR, launched again the game and now the CoL is working properly. Here is screenshots to illustrate my problem.

When I open FAR in the VAB, every value is at 0. The only thing that changes when I put the wings is the "Transonic design" data.

I tried to look for this problem on google and here on the forums, but can't find an answer. 

Thanks for your help on this matter ! 

 

Have a great sunday 

[cantab]

If you're tweakscaling wings, I suggest not doing that, there have been bugs with Tweakscale and FAR lately.

You have an awful lot of other mods in there. Can you reproduce the issue with just FAR and the required parts mods?

[Buisson]

Finally, after 4 hours, a Fellowship of the Ring (extended) and a pizza, I found what went wrong.

 

Ven's Stock Part Revamp is the trouble here, the engine section.

I don't really know whats wrong, maybe something with the drag part of the engines from ven's being rewrited ?

Tell me if I can do something to help.

[Cipher_077]

hi @ferram4, I really enjoy this mod and It is a must have whenever I play. However, sometimes, I have an issue. Back in 1.0.5 I wasn't being able to use it because the Center of Lift indicator was way far forwards. this sorted itself out for me in the version called     "Johnson". however in 1.1.2 , the CoL is way forwards then it should be again. what happens then is that my rockets need to have very large tailfins and my planes absolutely cannot have any canards and the rear wings have to be large. I don't think it's supposed to be this way because in some versions it seemed to work fine for me.

I don't know if I'm doing something with FAR itself or the intallation, so please help me if you can

Edit: I am using the newest version BTW

Edited June 6, 2016 by Cipher_077

[Starfire70]

I just want to say that I love this mod. Finally, a mod that (usually) causes your rocket to properly go BOOM when it flips.

I've laughed with glee watching parachutes get ripped off of a command pod that was going too fast too low (and watching Val's smile turn into an "AGHHHH!" in a heart beat).

Just great stuff, adds a new level of realism.

[cantab]

2 hours ago, Buisson said:

Finally, after 4 hours, a Fellowship of the Ring (extended) and a pizza, I found what went wrong.

 

Ven's Stock Part Revamp is the trouble here, the engine section.

I don't really know whats wrong, maybe something with the drag part of the engines from ven's being rewrited ?

Tell me if I can do something to help.

In the VAB/SPH FAR Menu there's an option to show voxels. Turn that on and see if they basically look right - bits that are ship should be voxels, bits that are not ship should not be. FAR just does drag based on the voxels it makes, which in turn are normally made based on the part colliders. The colliders should closely match the visible model for well-made parts, but sometimes there are considerable mismatches.

[Jim DiGriz]

@ferram4 There's a thread on reddit r/kos about an interaction between FAR and kOS producing sharply negative torque amounts from the torque APIs:

https://www.reddit.com/r/Kos/comments/4mocue/bad_cooked_steering_with_far/

I've definitely seen this as well (I'm not the OP there) and its pretty easy to reproduce on launches using kOS.  Unfortunately, I have to focus on packing for a trip today, so I can't afford to be more helpful right now.

 

[ferram4]

Well, I don't know if that's an issue with FAR or kOS.  None of the documentation on GetPotentialTorque states that it needs to provide positive values, and I can see lots of control issues if negative values are not accepted.  I'll try and find out if GetPotentialTorque must return only positive values, but if it isn't supposed to, then there's nothing I can do.

[Jim DiGriz]

6 hours ago, ferram4 said:

Well, I don't know if that's an issue with FAR or kOS.  None of the documentation on GetPotentialTorque states that it needs to provide positive values, and I can see lots of control issues if negative values are not accepted.  I'll try and find out if GetPotentialTorque must return only positive values, but if it isn't supposed to, then there's nothing I can do.

If you don't think its a FAR issue, I'll take a stab at the suggested kOS fixes in that reddit thread or whatever suggestions you can throw out once I get some time.

[Jim DiGriz]

@ferram4 is there any possibility that the busted voxelization from CLS could have been causing the negative torque issues?  I picked up the CLS update and now kOS is suddenly remarkably more stable.

[ferram4]

It looks like GetPotentialTorque is supposed to only report positive numbers.  And yes, if the old CLS was breaking FAR that updating that would probably cause FAR to be less broken too.

[Buisson]

19 hours ago, cantab said:

In the VAB/SPH FAR Menu there's an option to show voxels. Turn that on and see if they basically look right - bits that are ship should be voxels, bits that are not ship should not be. FAR just does drag based on the voxels it makes, which in turn are normally made based on the part colliders. The colliders should closely match the visible model for well-made parts, but sometimes there are considerable mismatches.

I can't really say if everything's looks fine. Here is some screenshots, do they look all right ?

 

Thank you !

[cantab]

That looks badly wrong to me. Others might be better able to help you get to the bottom of the problem.