Jump to content

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


ferram4

Recommended Posts

@linuxgurugameri did some more tests, 700 is definitely a good altitude for far :)

 

@ferram4 it seems the big s delta wings are producing significantly less lift in the later dev builds?  seems specific to these wings, if I build a 737-alike craft from mk3 and FAT parts it flies as expected... is the big s lift correct now, or was it correct before?

Link to comment
Share on other sites

15 hours ago, Drew Kerman said:

I still vote this thread be locked till Ferram updates. We have a thread to talk about craft design, we have Github to report issues - all anyone is ever going to talk about here until a new release is when the mod is going to get a new release, which is really not going to make Ferram release it any sooner. Sooooo....

This is not a democracy, votes don't matter. You are welcome to stop following the thread if it bothers you.

Link to comment
Share on other sites

On 4/14/2017 at 10:24 PM, ss8913 said:

@linuxgurugameri did some more tests, 700 is definitely a good altitude for far :)

 

@ferram4 it seems the big s delta wings are producing significantly less lift in the later dev builds?  seems specific to these wings, if I build a 737-alike craft from mk3 and FAT parts it flies as expected... is the big s lift correct now, or was it correct before?

I can concur on the 700AGL is a good altitude.  400 is pushing it but I have had a kerbal bounce and survive. 

 

 

Link to comment
Share on other sites

A couple of questions.

1. How does FAR (latest/dev) work with TweakScale?

2. About making part/wing mods compatible with FAR.  If there a guide/wiki to explain all the parameters and features needed to play correctly with FAR (e.g., I love OPT, and would love to make a FAR patch for it - if only I knew how; same for procedural wings, although, presumably, the latter is going to be a lot more complicated).

Thank you in advance.

Link to comment
Share on other sites

1 hour ago, Tau137 said:

A couple of questions.

1. How does FAR (latest/dev) work with TweakScale?

2. About making part/wing mods compatible with FAR.  If there a guide/wiki to explain all the parameters and features needed to play correctly with FAR (e.g., I love OPT, and would love to make a FAR patch for it - if only I knew how; same for procedural wings, although, presumably, the latter is going to be a lot more complicated).

Thank you in advance.

No part patches should be necessary, the current FAR model is based on part colliders so as long as the colliders are set up properly on the part FAR will do it's thing. I know that B9 procedural wings works just fine with FAR and i believe the other procedural wings also work fine. I haven't used OPT in a long time but it should work just fine right out of the box.

As for TweakScale I have no idea.

Link to comment
Share on other sites

23 minutes ago, Akira_R said:

No part patches should be necessary, the current FAR model is based on part colliders so as long as the colliders are set up properly on the part FAR will do it's thing. I know that B9 procedural wings works just fine with FAR and i believe the other procedural wings also work fine. I haven't used OPT in a long time but it should work just fine right out of the box.

As for TweakScale I have no idea.

I know that procedural wings "somewhat" work, but it looks like the lift and drag are not correct; control surfaces are barely functional.  Same of OPT wings and controls.

Judging from config files included in the latest releases, lifting and control surfaces must be reconfigured to use FAR aero model, and I would like to know more about what each parameter means and how it is related to wing's original stats and geometry.

 

@PART[wingShuttleDelta]:NEEDS[FerramAerospaceResearch|NEAR]:FOR[FerramAerospaceResearch] {
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    !MODULE[ModuleLiftingSurface] {}
    %MODULE[FARWingAerodynamicModel] {
        %b_2 = 4.7827
        %MAC = 3.49113
        %TaperRatio = 0.19983
        %MidChordSweep = 23.885
        %maxdeflect = 20
        %rootMidChordOffsetFromOrig = 0, 0.969895, 0
    }
}
@PART[wingShuttleElevon1]:NEEDS[FerramAerospaceResearch|NEAR]:FOR[FerramAerospaceResearch] {
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    !MODULE[ModuleControlSurface] {}
    %MODULE[FARControllableSurface] {
        %b_2 = 2
        %MAC = 1.21936
        %TaperRatio = 0.667627
        %MidChordSweep = -6.9283
        %nonSideAttach = 1
        %maxdeflect = 20
        %ctrlSurfFrac = 1
        %transformName = Elevon
        %rootMidChordOffsetFromOrig = 0, 0.09375, 0
    }
}

 

Edited by Tau137
Link to comment
Share on other sites

17 minutes ago, Tau137 said:

I know that procedural wings "somewhat" work, but it looks like the lift and drag are not correct; control surfaces are barely functional.  Same of OPT wings and controls.

Judging from config files included in the latest releases, lifting and control surfaces must be reconfigured to use FAR aero model, and I would like to know more about what each parameter means and how it is related to wing's original stats and geometry.

  Hide contents

@PART[wingShuttleDelta]:NEEDS[FerramAerospaceResearch|NEAR]:FOR[FerramAerospaceResearch] {
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    !MODULE[ModuleLiftingSurface] {}
    %MODULE[FARWingAerodynamicModel] {
        %b_2 = 4.7827
        %MAC = 3.49113
        %TaperRatio = 0.19983
        %MidChordSweep = 23.885
        %maxdeflect = 20
        %rootMidChordOffsetFromOrig = 0, 0.969895, 0
    }
}
@PART[wingShuttleElevon1]:NEEDS[FerramAerospaceResearch|NEAR]:FOR[FerramAerospaceResearch] {
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    !MODULE[ModuleControlSurface] {}
    %MODULE[FARControllableSurface] {
        %b_2 = 2
        %MAC = 1.21936
        %TaperRatio = 0.667627
        %MidChordSweep = -6.9283
        %nonSideAttach = 1
        %maxdeflect = 20
        %ctrlSurfFrac = 1
        %transformName = Elevon
        %rootMidChordOffsetFromOrig = 0, 0.09375, 0
    }
}

 

Ah that, look on the github page

https://github.com/ferram4/Ferram-Aerospace-Research

Spoiler

MODULE  
{  
	name = FARControllableSurface / FARWingAerodynamicModel  
	b_2 = 0.5				//distance from wing root to tip; semi-span  
	MAC = 0.5				//Mean Aerodynamic Chord  
	nonSideAttach = 0			//0 for canard-like / normal wing pieces, 1 for ctrlsurfaces attached to the back of other wing parts  
	TaperRatio = 0.7			//Ratio of tip chord to root chord generally < 1, must be > 0  
	MidChordSweep = 25			//Sweep angle in degrees; measured down the center of the span / midchord position  
	maxdeflect = 15				//Default maximum deflection value; only used by FARControlableSurface  
	controlSurfacePivot = 1, 0, 0;		//Local vector that obj_ctrlSrf pivots about; defaults to 1, 0, 0 (right)  
	ctrlSurfFrac = 0.2			//Value from 0-1, percentage of the part that is a flap; only used by FARControlableSurface  
}

 

For control surfaces, use above but replace FARWingAerodynamicModel with FARControllableSurface and add maxdeflect value

Set all the other winglet/control surface values to zero

As for Procedural Wings idk, as I said, B9 PWings seams to work just fine, however I haven't done a lot of testing.

EDIT:

Also https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7

Edited by Akira_R
Link to comment
Share on other sites

OPT wings have *never* worked right with FAR, although there is/was a patch for that.  The maintainer of OPT has said that when FAR goes official, he may include the MM patch to make his wings work correctly.

I'm venturing a guess here that FAR may not go official until 1.3, however, since that will require more work/etc... in the meantime, the dev build seems to work as well with 1.2.2 as the previous official version worked with 1.1.3.  My opinion, anyway.  It seems release-quality at this point.

Link to comment
Share on other sites

I've noticed far calculates all wings with a flat airfoil meaning planes have an unrealistically high stall speed making things harder than is realistic. But I have an idea, maybe you could have a button on wings that could change the airfoil shape like how you can toggle a flag on and off on some parts maybe the option between flat and 3 or 4 other airfoils and far would treat the wing like it has that specific airfoil. But I understand this will be hard to get to work with stuff like p-wings so you should still focus on releasing the 1.2.2 version of 1.15.7.

Link to comment
Share on other sites

28 minutes ago, ItCameFromDuna said:

I have read this, and I keep hearing about the dev release, but I can't seem to find it. I have looked on GitHub, and I have no idea where it might be located. Can someone post a direct link to it? Thanks!

ferram4 said that he only wanted people who know where to find the dev build to be using it. The logic behind this was that the type of people who can provide useful bug reports will, most of the time, know where stuff like this is and he really only wants dev builds to be used for bug hunting. If you haven't found it on your own then you are sol.

Link to comment
Share on other sites

Okay... I waited patiently since the release of 1.2 for FAR to update, since it feels necessary for my KSP experience. So I'm currently still stuck with KSP 1.13 (luckily still availible on steam; thx KSP team; steam is a b**** when it comes to running older versions).

But well I notice that there seems to be no visible progress. Multiple times it was stated by Ferram, that FAR for 1.2 will probably be done in 1-2 weeks. This tells me that it actually seems to be pretty much done, but seemingly some additional problems occured. I also think I have a quite good idea on where to get the dev build.

So I justed wanted to ask those who are already playing the dev build:

Are there still severe issues (from your experience), and what issues are there? Would you generally recomend testing the dev build? I mean, I don't know if I could contribute a usefull bug report, but I certainly understand that it's a dev build and so even if most of it runs well, there might be some things still in need of fixing.

 

P.S: Finally - many thanks to Ferram for his good work. It's a pity the KSP team didn't include FAR as standard air interaction model for KSP.

Link to comment
Share on other sites

Same results here as well. I really have no idea as to why it hasn't been pushed to at least release candidate with so many people wanting and waiting patiently. It feels wrong for me to be able to play with a (personally) completely stable 1.2.2 build while I see everyone else that doesn't know how GitHub works get slapped down by not knowing how it handles branches. Not everyone is a mod / software developer, so it makes sense that they wouldn't know how GitHub works. Not everyone that consumes your mod should know how to work the website. In fact, the most they've probably used it for is to download the latest release of the various mods they use.  

If the entire reason this is done is to stop the less technically minded people from submitting bug reports, or even asking for help, then I don't know what to tell you. In software development, mod development, or anything that gets consumed by more people than just yourself, there are going to be stupid people, and stupid bug reports. The best way to handle them is to either reply with a FAQ, a type of auto-response message, or, if they're at the maximum level of stupidity, stop contact completely. If they continue after multiple times with no improvement, then there are reasons that a block user / auto delete message feature for email were created.

I feel as if the people that encourage this, or want this practice to continue, enjoy being propped up on some sort of high-horse. All this does is make some people feel better because they know how to do something that someone else doesn't know how to do. While everyone else that isn't on that same level gets the short end of the stick. It's the textbook example of elitism.

I'm sorry if this type of comment is frowned upon, but it has finally bothered me enough to speak up about it.

Link to comment
Share on other sites

I am probably doing something wrong here so please help me.

So, I tested the Dev build on a clean install. Only Modular Flight Integrator 1.2.4 an ModuleManager 2.7.5 installed. With FAR 15.7 I have no GUI and control surfaces don't work. With FAR 16 everything works but as I approach an another vessel (only tested with splashed down) to 177 m distance the game crashes or the vessel disapears and I have a NaN error on the nav ball (the Tracking station reports that the plane is now landed on the sun).

Did I mess something up with the install or is this a genuine bug?

 

P.S. Thank you Ferram for a great mod and the willingness to maintain it through all this years.

Link to comment
Share on other sites

1 hour ago, Mighty1 said:

I am probably doing something wrong here so please help me.

So, I tested the Dev build on a clean install. Only Modular Flight Integrator 1.2.4 an ModuleManager 2.7.5 installed. With FAR 15.7 I have no GUI and control surfaces don't work. With FAR 16 everything works but as I approach an another vessel (only tested with splashed down) to 177 m distance the game crashes or the vessel disapears and I have a NaN error on the nav ball (the Tracking station reports that the plane is now landed on the sun).

Did I mess something up with the install or is this a genuine bug?

 

P.S. Thank you Ferram for a great mod and the willingness to maintain it through all this years.

Might as well test both possibilities. Replicate and grab logs.

Link to comment
Share on other sites

 

On 5/1/2017 at 7:50 AM, parachutingturtle said:
On 4/30/2017 at 4:16 PM, Mighty1 said:

With FAR 15.7 I have no GUI and control surfaces don't work.

I had this problem when I forgot to install ModularFlightIntegrator.

I have the latest version of ModularFlightIntegrator (1.2.4.0) installed, but am also having this problem. Should I open an issue on GitHub or does anyone have a fix?

EDIT: My mistake, I forgot to check my KSP version. I was running 1.2.2, which FAR doesn't support yet.

Edited by Pazmivaniye
Link to comment
Share on other sites

On trying to pin-point which mods write settings outside the Plugins/PluginData folder I checked for file *.cfg changed within the last hour and found:

GameData\FerramAerospaceResearch\CustomFARGUIColors.cfg
GameData\FerramAerospaceResearch\CustomFARAeroStress.cfg
GameData\FerramAerospaceResearch\CustomFARAeroData.cfg

Fact is, that I didn't use FAR (open the GUI) at all the last session, I onlöy changed from RSSVE / scatterer to RSSVE-Lite only.

Is this the reason?

But why GUI colors?
Should not be changed because of RSSVE-Lite I guess...

Link to comment
Share on other sites

On 5/3/2017 at 7:57 AM, Pazmivaniye said:

 

I have the latest version of ModularFlightIntegrator (1.2.4.0) installed, but am also having this problem. Should I open an issue on GitHub or does anyone have a fix?

EDIT: My mistake, I forgot to check my KSP version. I was running 1.2.2, which FAR doesn't support yet.

I guess that's why my blue center of lift is in the ground all of the time and planes keep crashing...

hoping for an update soon

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...