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

[thorfinn]

@etheoma: Yep, it's great, ain't it? I've also noticed what appears to be a few MB of leak every editor -> flight -> editor cycle, and I'm not sure where it comes from, though I can reproduce it in stock KSP, so it's not anything I'm doing.

Could you post some details?

I'm pretty sure that this is the problem that's making the OSX version horribly unstable (and it crashes always on a scene change): if you can replicate it also in Windows then we might be able to show them where the problem exactly lies...

[4plains]

Hello Ferram4

Since upgrading to the 1.0.2 compatible version of TweakScale I have been getting odd behavior together with nuFAR. I have posted about this on the TweakScale development thread too.

FAR seems to get confused when I change the scale of parts as to the hitboxes and meshes it's supposed to use. This is a particular problem since it gets most confused when changing the size of the small Tail Fin, Standard Canard, and the 2 Small Winglets (AR-2 and AR-69 I think is their name). FAR calculates with the correct cross section of the wing, but lift calculated therefrom seems odd. I had a standard canard each side of the plane at 400% scale as main wing (a bit larger than a Big-S Delta Wing), plane weighs 20t. It needed 155 m/s to get off the runway at a AoA of ~10°. (I use Full Real Drag setting, the plane has a max crossection of 8 m^2 and wave drag area of 1.35 m^2).

Steps to reproduce:

1. Place a small wing (Standard Canard, Tail Fin, ...)

2. Scale up

3. Move it and other parts with the Offset building mode

4. Sweep AoA with the nuFAR build helper

5. Rescale

6. Repeat 1. - 4.; 1. and 2. not required; (Graphs don't really change, and sometimes the game thinks my part is at 100% scale)#

7. Launch, Revert/Recover craft

8. Graphs updated and part now seems to work (as it should)

or: Graphs update but parts are now treated by nuFAR as being at 100% scale and therefore producing not the results desired.

As of yet I have been able to repoduce this bug with the Standard Canard, the Tail Fin, The AR-68 Winglet, and the standard winglet. The new Big-S and FAT-455 parts seem to be immute to this as well as the Elevons(haven't tried rescaling either).

Thank you for looking into this.

Greets 4plains

- - - Updated - - -

So I am experiencing some odd design quarks in the NuFAR... This craft has a tendency to pitch up until it stalls. At first I thought it was the air brake on the back so I removed it. The craft still pitches up. I then moved somethings around and it still pitches up, not as bad though. Then I thought the CoL was ahead of the CoM so I did some minor rework in the wing design and it still pitches up.

This is where it is now, and it is FINE at supersonic speeds.

http://i.imgur.com/AkZPi9r.jpg

You seem to be using P-Wings or B9 P-Wings.

1. How are you getting them to work, I can't.

2. Have you looked at using the transsonic design tools that Ferram provides us in the FAR-window. Try so smooth out the yellow graph that appears when clicking on "Toggle Cross-Section Area Curves". The yellow graph is a representation of how much supersonic drag you have. Also it's displayed in a window as "Mach 1 Wave Drag Area" (my frikkin' part descripion window is masking that part of the FAR-Tab). You want that so be as small as possible and your yellow graph to be as close to 0 as possible. The yellow graph is the 2nd derivative of the green graph displayed. In laymens terms this means that the yellow graph is a representation of how thight the curves on the green graph are.

Picture below shows the 2 graphs and the FAR window.

Edited May 7, 2015 by 4plains

[Crzyrndm]

Hello Ferram4

Tweakscale needs to add this if they haven't already to notify FAR of changes in shape/size.

PS: Overwrite the B9 Pwings with the files here to get them working in 1.0.x/FAR

[cantab]

Is there a way to control flight (pitch) trim without the use of the alt key? The reason I'm asking is controllers and joysticks are going to become popular when flying airplanes, and constantly switching to the keyboard can be annoying. The stock game doesn't have an option to rebind the "alt" key (or any trim control).

It's not exposed in the game, but if you go into the settings.cfg you can add a second binding for the alt key. Making that a joystick button may help. Alternatively maybe an external program could turn the joystick hat switch into a Alt+WASDQE input. In my own case I need to combine those, and then holding down the XBox button and pushing the DPad does my trim - not a perfect solution but it works.

[tetryds]

@Hodo: That is it, most IRL deltas are not even pilotable without fly-by-wire systems.

It was always weird how they were so stable on the previous FAR versions.

As blowfish said, some -%AoA will help a lot, but if you are flying at high altitudes I even recommend some built-in negative AoA to them.

Also, you can improve wave drag on the rear, flat edges are a pain to deal with, this is one of the reasons why swept wings are better.

@4plains: Yeah, the wings issue was because FAR wings still use the old code for lift.

I also noticed many issues when using oldFAR and tweakscale, but if there is already a fix for that I will consider using it again.

Supersonic RC planes, hell yes.

[etheoma]

Could you post some details?

I'm pretty sure that this is the problem that's making the OSX version horribly unstable (and it crashes always on a scene change): if you can replicate it also in Windows then we might be able to show them where the problem exactly lies...

Question: are you using pure stock?

If so: That shouldn't be happening, and its not RAM that's your problem.

If not and you are getting to around 3GB with mod: if your getting this crash when you have cycled in and out of the editor into flight and back again repeatedly all you need to do is reduce your KSP RAM utilization first if you haven't use the Active Texture Management mod with the aggressive version you can get your KSP RAM utilization down by maybe 50% if your using a lot of large textures, more commen is a 20 - 30% reduction but that more than enough to allow KSP head room for the small memory leak of the Editor --> Flight --> Editor leak which isn't really that big.

A ok target for RAM utilization is around 2.4GB 2.6GB is pushing it and you will get crashes if your going in and out of the editor a lot I mean 20 - 30 times.

If your already using the Active Texture management system then I suggest deleting particular parts you never use, for example I never found my self using the massive parts in B9, personally my self I managed to keep the memory utilization in KSP down enough with ATM so I just left them because they weren't doing and harm.

the final solution is just cutting down on the really RAM heavy part mods and just taking from them what you absolutely need and getting ride of different sized versions of the same thing and using Tweek scales to rescale things as needed, also where you can use procedural parts use them because there much more RAM light, something I would like to see from B9 in the 1.0 version is to move to procedurally generated parts and just having pre-sets rather than totally different texture models.

Obviously not everything can be done that way, but a lot of things could and not look any worse for it. Extendible cargo bay rather than 3 different sizes models extensible fuselage's and Fuel tanks etc.

And not only would that decrease RAM usage it also increases the amount of flexibility of B9 which improves game play which is a WIN WIN. Only thing is developing it but there are a lot of moders who do procedurally generated parts which I'm sure one would be willing to help / collaborate.

Edited May 7, 2015 by etheoma

[Hodo]

@Hodo: That is it, most IRL deltas are not even pilotable without fly-by-wire systems.

It was always weird how they were so stable on the previous FAR versions.

As blowfish said, some -%AoA will help a lot, but if you are flying at high altitudes I even recommend some built-in negative AoA to them.

Also, you can improve wave drag on the rear, flat edges are a pain to deal with, this is one of the reasons why swept wings are better.

Fascinating.

I have been testing this design, and I found that it works at supersonic speeds just fine. As long as I am going mach 1+ it is quite stable.

But the Voxel diagram doesn't read the outter wing sections when set to display the blue arrows. So this maybe part of the problem I will test against another design made with the stock wing bits.

I have another simple training aircraft that I built to give my pilots the basic flight skill in career mode. It uses the B9Pwing and fuel in the wings, it works just fine. Granted I need to put airbrakes on it to slow down to landing speed, which is 65m/s but that is a minor design oversight.

[Dimenus]

@Dimenius: Upon my testing, I find that the CoL drops to where it should be. If you aren't absolutely certain that you're running the latest nuFAR and you're not absolutely certain you've installed every dependency right, don't post a bug report.

I understand that I'm not proficient enough at this point to be of much use to you, but the last comment is not necessary at all. Questioning someone else's competency serves no purpose whatsoever. Yes I have BOTH dependencies installed, yes they were the latest version at the time of posting. However, as of this morning, I've been unable to reproduce the behavior with the latest nuFAR installed. So I guess you're still right either way .

[ferram4]

@thorfinn: All I know is that every editor -> flight -> editor cycle seems to add 20 MB of RAM. I was hoping it was me being stupid with voxels and I could fix the leak, but nope, it's KSP. Dunno any more about it, but it's there, lurking. Seems to explain all the crashes after a long time of playing issues, tbh.

@etheoma: There's actually nothing stopping you from increasing the number of voxels for each vehicle from 250k to 2.5m if you want to. The only problems are that it's slower to generate and that you'll have fewer editor -> flight cycles before crashing. I've already optimized that whole thing about as well as I can based on profiling, unless I get some stroke of genius that lets me cut out a huge amount of overhead.

The voxel generation is already as multithreaded as I can make it. The actual in-flight aero calculations can't be multithreaded due to 1) not having strict control of when things run in the physics frame and 2) letting the forces come back one frame (20ms) later results in everything becoming horribly unstable due to the phase lag. Yes, I already tried this, no, it doesn't seem fixable.

If there were no hard limit I'm honestly not sure, mostly because anything that cuts out the bottom 10%-30% would cut out me; I'm running a 4-year old Lenovo T520 (with 16GB of RAM, granted, but it's not super-fast) so I'm more concerned about it working for me than for anyone else here.

@4plains: Hmm interesting. To the best of my knowledge, I've done everything required to make it work, unless it's doing something screwy and it's applying OnRescale multiple times on load, in which case, things are going to be very screwy. I'll see if I can do anything.

@Hodo: That would probably be stable were it not for the canards at the front and if the nose + cockpit came a bit further out. You've got a lot of lift far forward on that.

@Dimenius: Sorry if it came off as mean, but you'd be surprised how many times I've gone on a wild goose chase for what I think is One Of Those Bugs That Won't Die when it turns out that it's something to do with the user being on a different version or missing dependencies. It prevents development from going as fast as I'd like.

[etheoma]

@etheoma: The voxel generation is already as multithreaded as I can make it. The actual in-flight aero calculations can't be multithreaded due to 1) not having strict control of when things run in the physics frame and 2) letting the forces come back one frame (20ms) later results in everything becoming horribly unstable due to the phase lag. Yes, I already tried this, no, it doesn't seem fixable.

Humm I'm re-looking over the spec's for unity 5 and it looks like it will take care of the multi threading for you and prioritize things which will take longer to get it done in the same frame... But ehhhhhh... I dunno... U4 physics has left a bad taste in my mouth and my trust in there new physics engine being able to properly prioritize tasks is lacking and it looks like there still not going to allow you to mess with that so *shrugs*

One can hope it works flawlessly and Squad ports KSP to U5 One can also hope I win the lottery, and date a super model.

If there were no hard limit I'm honestly not sure, mostly because anything that cuts out the bottom 10%-30% would cut out me; I'm running a 4-year old Lenovo T520 (with 16GB of RAM, granted, but it's not super-fast) so I'm more concerned about it working for me than for anyone else here.

I was just about to say you don't do all your compiling on a laptop do you but I suppose FAR isn't that big so it shouldn't take that much horse power to compile relatively quickly. I was also going to say that CPU's haven't really changed much over the last 4 years but that's only true for desktop CPU's as CPU's have had leaps and bounds in TDP reduction and power draw reduction and for a laptop that REALLY affects performance.

Ok I'm going to stop not before I completely nerd out over computer hardware which isn't all that relevant.

Edited May 7, 2015 by etheoma

[Bakase]

Don't believe this bug has been reported before. I may be running an outdated build, so please disregard if this issue has already been fixed.

The axes turn diagonally when the landing gear is added

[tetryds]

http://i.imgur.com/Bnbi4Hn.jpg

Don't believe this bug has been reported before. I may be running an outdated build, so please disregard if this issue has already been fixed.

The axes turn diagonally when the landing gear is added

Sorry but if you don't download the very latest build and try it again to see if the bug persists, you are unfortunately not helping.

This bug has been fixed already.

If you download the latest version and it persists, then it would be interesting that you report it here again.

[Bakase]

Sorry but if you don't download the very latest build and try it again to see if the bug persists, you are unfortunately not helping.

This bug has been fixed already.

If you download the latest version and it persists, then it would be interesting that you report it here again.

Now that's hardly an appropriate response -- bordering on plain rude. As I said, I didn't know whether it had already been fixed (sorry, but I'm not going to look through 50 pages of this thread), but I hadn't seen it mentioned. If it had turned out to be an unresolved problem, an issue that might otherwise have been missed will get fixed. If not -- as in this case was so -- then what have you lost? Maybe had I reported it as an issue in the latest build it would have wasted everyone's time, but I didn't. I made sure to specify that I was using an older version for that exact purpose.

[Tarheel1999]

Dude, you drew that comment for two reasons:

1) Ferram has requested that only people who are 100% certain they are using the current version report bugs to prevent wild goose chases.

2) You didn't read the first page before posting. Look up/down and you will see a conversation between Ferram and Dimenius about this precise issue.

[Bedwyr]

Dude, you drew that comment for two reasons:

1) Ferram has requested that only people who are 100% certain they are using the current version report bugs to prevent wild goose chases.

2) You didn't read the first page before posting. Look up/down and you will see a conversation between Ferram and Dimenius about this precise issue.

Ditto. Your comment Bakase:

(sorry, but I'm not going to look through 50 pages of this thread)

Demonstrates pretty clearly you're not willing to be diligent in your work. You were asking for it. This isn't a take-it-or-leave-it playtest phase. It is absolutely the opposite of what Ferram needs right now. I recommend dropping the mod for the time being and wait or go back through and read all 50 pages you don't want to carefully, make sure you're testing the right things and giving the right information.

I don't have the time right now to do that, so I won't be testing this. Neither will I be asking for ETAs or lame queries. I'll be waiting. Patiently. Quietly. Help the right way or join me here on the floor and be quiet.

Edited May 7, 2015 by Bedwyr

[Bakase]

Ditto. Your comment Bakase:

Demonstrates pretty clearly you're not willing to be diligent in your work. You were asking for it. This isn't a take-it-or-leave-it playtest phase. It is absolutely the opposite of what Ferram needs right now. I recommend dropping the mod for the time being and wait or go back through and read all 50 pages you don't want to carefully, make sure you're testing the right things and giving the right information.

I don't have the time right now to do that, so I won't be testing this. Neither will I be asking for ETAs or lame queries. I'll be waiting. Patiently. Quietly. Help the right way or join me here on the floor and be quiet.

I'm not 'testing'. I'm playing with it, and I happened to notice an issue.

I read the exchange about past versions, which is why I SPECIFIED that I was using an older version.

Please learn to read.

[Hodo]

Now that's hardly an appropriate response -- bordering on plain rude. As I said, I didn't know whether it had already been fixed (sorry, but I'm not going to look through 50 pages of this thread), but I hadn't seen it mentioned. If it had turned out to be an unresolved problem, an issue that might otherwise have been missed will get fixed. If not -- as in this case was so -- then what have you lost? Maybe had I reported it as an issue in the latest build it would have wasted everyone's time, but I didn't. I made sure to specify that I was using an older version for that exact purpose.

Nothing anyone said was rude, you are just trying to be a victim here, so step down off that cross because your name isn't J-C.

All he said was if you don't have the latest version they can't help you. Ferram is not a developer he is a player just like you and eye, he just made a mod in his free time for us to use because he thought others would like a more realistic aerodynamic model. Not because he has to but because he wants to.

So dont come over here thinking you are entitled to anything because you chose to download his mod.

- - - Updated - - -

I'm not 'testing'. I'm playing with it, and I happened to notice an issue.

I read the exchange about past versions, which is why I SPECIFIED that I was using an older version.

Please learn to read.

Yet you called someone else rude for telling you how to fix the problem?

Edited May 7, 2015 by sal_vager

[Wanderfound]

Bakase: this is the third time today that this exact conversation has repeated on this thread. Ferram has been developing this (fantastically good, incredibly complicated, seen by many players as essential, done by Ferram purely as a charitable work) mod for years.

Do the math. Is it surprising that he might occasionally get a teentsy bit irritable when the same thing happens again and again? Or that fans of the mod might want to do what they can to deflect those irritations before it gets so bad that Ferram decides it isn't worth the hassle?

Nobody here is attacking you, and nothing you did was particularly objectionable when considered in isolation. But this isn't an isolated event. Please consider the context.

[4plains]

@Bakase:

2 things to make clear:

1. This is a response thread for Ferram4 to get feedback for Bugs in the code of nuFAR. Posting reports on bugs that don't have the correct dependencies installed and ensuring that you as a player are on the newest version of nuFAR, Module Manager and Flight Integrator will not help Ferram4. So if you want to have a bug free version of nuFAR out as fast as possible, make sure your issue still persists in the newest release of nuFAR before posting.

2. If you take it as rude when rules are being stated to clarify how we're supposed to interact here, chill out bro. Test it, play it, when you find a bug, see if it's the newest version you're on. If not, then update, try to reproduce it, if you were able to, make a post on how exactly to reproduce your bug.

Sincerily

4plains

[tetryds]

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

It's happening.

Edited May 8, 2015 by tetryds

[Clythoris]

Yes.

[peachoftree]

The soundtrack for this release is amazing

[Clythoris]

The soundtrack for this release is amazing

I know, right. I opened it a while ago and now it just keeps on playing Serious Sam tracks. It's pretty soothing.

[mic_e]

The soundtrack for this release is amazing

I also like that it has a codename.

[jofwu]

What's the lowdown on the "RealChuteLite" implementation? Sounds to me like stock parachutes don't know how to work with FAR, so they needed some adjustments in the part configs? RealChute parachutes will of course come with this functionality built in (that being stupid_chris's responsibility), but for those who don't use it... they need something for the stock parachutes to work. Is that the story?

Also, how will FAR v.15 play with stock heating? (until DRE is updated)

Edited May 8, 2015 by jofwu