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

[kcs123]

16 hours ago, ferram4 said:

That code already exists, it simply drops in at a lower speed.  The problem is that if I code the water drag so that that particular plane, with almost all of it out of the water has high drag, then anything with any significant amount of stuff underwater simply won't be able to move.  Even worse, it'll ensure that anything that goes deeper underwater during ditching will submarine and then break up due to the forces.

I don't think there's anything I can really do; this is how things behave under low-speed drag.  I'll break everything if I try to make it stronger.

I was afraid that game engine could be limitation. Is it possible to externalize speed when this formula kick in trough config files ?
Water in KSP does not follow real life behaviour and real life formula could not be aplied. Attempts to find "good" values that work for game purposes might be tedious and tiresome to do. I'm sure you have more important things to worry about, but if we got some of those water related values trough config files, members from community might help with tedious tasks.

Also, something else is odd with water behaviour. It feels more like a rubber surface than like a water. When some object splashes in water at high speed, assuming that speed is not too high to destruct object, you expect to get in water much deeper and then slowly pop up on surface, depending on object density compared to water or boyuancy.
Currently it is like craft bounce from water surface and when finally craft land on water without destruction (under speed limit of parts in water) it takes too much time to slow down than it should be.

I understand that some trade off have to be made for water boyuancy due to much higher weight of parts used in KSP (cockpits, fuel tanks, etc.), but it might be good to fine adjust boyuancy effect too. It will be good if that can also be changed trough config files too. Might be that already is, but I'm not aware of it, some points in right direction would be nice.

It is not just that plane showed on picture in previous post, all other water related crafts behave odd, I didn't bothered until recently with boats or seaplanes, so I didn't think too much about it. Also, some other thing that poped on my mind while I wrote this post, it might be a good idea, if possible to add extra +20 m/s or something like that to already existing crash speed limit for parts that is good for solid surfaces.

[d4m1ty]

12 hours ago, tetryds said:

@d4m1ty if you look a few pages back you will notice that the flaps issue has been reported several times, never heard of the spoilers being inverted.

Try out the dev build.

Thank man.  I googled for like 45 minutes with every iteration of Flap, KSP, FAR, Gui analysis, you name it and could not find it reported.  Just didn't pop on the search.

 

[EDIT]

How to reproduce the inverted spoiler/flap issue on B9

 

Load Plane

click FAR button

run Stability Derivs

Hover over Spoiler/Flap, hit J, make any adjustment - spoiler/flap will invert and stay inverted

 

You can do this over and over.  Did it 4 times like this before posting to make sure it was that easy to reproduce.

 

 

Edited December 27, 2015 by d4m1ty

[kcs123]

3 hours ago, d4m1ty said:

Thank man.  I googled for like 45 minutes with every iteration of Flap, KSP, FAR, Gui analysis, you name it and could not find it reported.  Just didn't pop on the search.

 

[EDIT]

How to reproduce the inverted spoiler/flap issue on B9

 

Load Plane

click FAR button

run Stability Derivs

Hover over Spoiler/Flap, hit J, make any adjustment - spoiler/flap will invert and stay inverted

 

You can do this over and over.  Did it 4 times like this before posting to make sure it was that easy to reproduce.

 

 

One page back - spoiler bug was reported and it is already fixed in dev build. Mentioned by ferram few post after that linked one. Just grab dev build and test it too see if you can find any other bug prior official release.

[d4m1ty]

25 minutes ago, kcs123 said:

One page back - spoiler bug was reported and it is already fixed in dev build. Mentioned by ferram few post after that linked one. Just grab dev build and test it too see if you can find any other bug prior official release.

I just downloaded the dev build today. It still flips the b9 parts if you adjust it through the J menu.  The flap not setting to 0-3 is fixed though.

 

 

[ferram4]

10 hours ago, kcs123 said:

I was afraid that game engine could be limitation. Is it possible to externalize speed when this formula kick in trough config files ?
Water in KSP does not follow real life behaviour and real life formula could not be aplied. Attempts to find "good" values that work for game purposes might be tedious and tiresome to do. I'm sure you have more important things to worry about, but if we got some of those water related values trough config files, members from community might help with tedious tasks.

Water drag in KSP behaves the same as air drag in KSP.  They both use the proper realistic equations and result in proper, realistic behavior under FAR.  The problem is that things don't actually slow down that quickly when they're barely submerged like most KSP vehicles are.  Drag at low speeds really isn't that high.

10 hours ago, kcs123 said:

Also, something else is odd with water behaviour. It feels more like a rubber surface than like a water. When some object splashes in water at high speed, assuming that speed is not too high to destruct object, you expect to get in water much deeper and then slowly pop up on surface, depending on object density compared to water or boyuancy.
Currently it is like craft bounce from water surface and when finally craft land on water without destruction (under speed limit of parts in water) it takes too much time to slow down than it should be.

I understand that some trade off have to be made for water boyuancy due to much higher weight of parts used in KSP (cockpits, fuel tanks, etc.), but it might be good to fine adjust boyuancy effect too. It will be good if that can also be changed trough config files too. Might be that already is, but I'm not aware of it, some points in right direction would be nice.

That's not buoyancy.  That's body and wing lift operating based off of the increased density.  You're skipping across the water just like you would skip a rock, but slightly amplified by the discrete timestep behavior.  Really, it needs additional energy loss when hitting the water, but that's already coded and increasing it more could cause very strange things, especially since it doesn't appear to be properly directional or account for the effect of water being thrown into the air / outward during a splash that would dissipate energy.  Something that should be done on the stock side, really.

Look, my only method of "fixing" this is to create a situation where seaplanes are impossible or any traditional jet with engines podded under the wings will automatically faceplant on ditching when the engines grab too much.  This is relatively correct behavior, and any changes to it will make it less realistic.

[kcs123]

I have created several seaplanes. Landing/takeoff from sea behave more/less correct, craft slow down relativly quickly down to ~10 m/s. But from 10 m/s to zero takes eternity.
That is not only problem. Just before I checked forum I droped some buoy probe on sea. No engines, I parachuted it to the sea. When I switched from map to that probe, it tiped over.

After splashing down, instead of slowing down, it started magicaly to accelerate. from 0.5 m/s to 2 m/s and speed slowly increases further over time. I have lost patience, so I exited game. I understand that you want to create close to realistic behaviour as possible, but due to stock game engine code it is not always possible. Probably KSP kraken hits when you expect least.

Anyway, thanks for answer, if nothing is possible to improve this than we have to be patient and wait to see if something will be improved from SQUAD side in future.

[kcs123]

2 hours ago, d4m1ty said:

I just downloaded the dev build today. It still flips the b9 parts if you adjust it through the J menu.  The flap not setting to 0-3 is fixed though.

 

 

Perhaps I don't have latest FAR version and something become broken with dev version I grabed and the one you have ?

Also I tred to grab the same behaviour of that probe that accelerate by kraken engine on pictures. It seems that it happens to accelerate on the moment when game engine apply physics. When switch from tracking station to probe or when accelerate time and then switch to 1X time. I will try to create more kraken friendly buoy probes in future.

[ferram4]

Well, obviously the source of the velocity was due to it falling over and the potential energy in that being converted into kinetic energy sideways.  Drag isn't capable of adding energy to the system, simply removing it, so that's not the cause, and buoyancy should not add energy to the system.

[kcs123]

Well, whatever hacky code you have created last night, it worked. That buoy probe no longer accelerate by itself after tiping over. Kraken no longer pushes it.
I have tried few other planes to splash by  taxiing from runway to sea on wheels, hiting sea at speed 5-7 m/s sec and those have stoped much quicker than before.
Also performed landing/taking off to/from sea and that is still feasible. Although that small plane still have some long time to stop, but that is no wonder, it is lightweight plane with only small surface submerged. That is no problem at all for that craft, because engines can have reverse thrust and can be used to slow down craft more quickly.

So, seaplanes were not broken and Kraken no longer pushes small buoy probes.

Didn't  not have much time to do other tests, but it seems that nothing else is broken for now.

[steve_v]

On 25/12/2015 at 8:44 AM, ferram4 said:

...anyone willing to give the dev build a shot and report back anything weird that they find would be very helpful

Mkay, running it now. Water drag feels about right to me, but I am noticing that fins are now being ripped off my rockets @~10Km/mach 1.5/1°AoA (where they weren't before), I take it this is an intentional result of the drag changes?
They are admittedly set rather weak (0.4) and it's a monster SRB stage, so somewhat brutal. But hey, it worked before.
 

Ed: I think it's SAS roll oscillation causing this, but still, aero stress failures where there were none before.

Edited December 29, 2015 by steve_v

[Salawat]

Hey, ferram; think I found a good bug for ya. 

I'm using the latest version from CKAN, but I've also tested it from the latest code you've got posted on the master branch of GitHub. 

Symptoms: 

No body drag/lift. 

The wing based aerodynamics calculations appear to be working just fine, but the values of L and D reported in the FAR Flight Data interface is NaN in all instances that I launch a craft.  I'm using 1.0.5.  I've removed all mods with the exception of FerramAerospaceResearch and ModularFlightIntegrator on x64 linux. 

Repro steps: 

• Go to either VAB or SPH.
• Grab an OKTO Probe Core.  Slap some monoprop on it, and a bunch of Puff's (NOTE:  the exact parts don't seem to be relevant;  Wings/CtrlSurfaces will still work as wings/CtrlSurfaces, but parts that normally generate body lift seem to be effected[i.e. Mk2Spaceplane parts])
• Launch
• Note that once on the launchpad/runway, if you enable the Flt Data through FAR interface, L/D and V*L\D should be 0.0000
• Stage
• Once the vessel is in flight, L/D will register as NaN as will V*L/D

If you enable the Aerodynamics overlay, there will be no increase in magnitude of either the Lift or Drag vectors, so it's not just the GUI reporting an uninitialized value while the calculations are still happening in the background.

I've got the Player.log available if you'd like me to PM it to you.  But I haven't been able to find any significant exceptions coming from the FAR stack, but something is clearly up here.

[kcs123]

8 hours ago, steve_v said:

Mkay, running it now. Water drag feels about right to me, but I am noticing that fins are now being ripped off my rockets @~10Km/mach 1.5/1°AoA (where they weren't before), I take it this is an intentional result of the drag changes?
They are admittedly set rather weak (0.4) and it's a monster SRB stage, so somewhat brutal. But hey, it worked before.
 

Ed: I think it's SAS roll oscillation causing this, but still, aero stress failures where there were none before.

Don't know if it is intentional or not, but yes, wing surfaces are indeed riped off much easier on the same craft that was previously capable to deal with similar forces without problem.
If it is intentional, then we just have to create more stronger wings or control crafts more gently.

@Salawat, don't mention bugs if you have installed FAR trough CKAN here, there is link in OP for proper thread that provide support for FAR installed trough CKAN.
Maybe some of moderators might move your post there before ferram get mental breakdown.

[ferram4]

@steve: nope, that was me making a big screwup.  While changing things I tried to make some stuff more efficient by making use of FlightIntegrator's dynamic pressure calculation for the wing code.  Problem was, I put it into atmospheric density, so you effectively got forces proportional to v^4.  This is why dev versions need testing. Is fixed now.

As a nice bonus, this seems to have made water landings a lot better too; I was having some trouble getting planes with low wings to splash down nicely, now they grab a lot more.  Still skip a bit, but nowhere near the way they did.

@Salawat: You're basically telling me that every single non-wing part in FAR is broken.  No, I can't reproduce any issues with any of that, and I'm afraid that since you're using CKAN you're ineligible for support.  Since no one else has any issues like that, I'd say CKAN is probably somehow the cause of your issue through an install screwup of some kind, so you're completely on your own here.

[Phos]

I'm not sure if the dev build fixes this (cause I don't know my way around github and can't find anything labeled "dev build"), but...

taking a fresh KSP install,

adding FAR,

then launching the scenario where jeb is a bit away from his capsule, bring your periapsis down to about 35k, drop the engine

gives you entry heating but doesn't actually slow you down, no G forces are registered and your obit doesn't change.  

[tetryds]

@Phos not enough reproduction steps, we need to know EVERYTHING that happened on that session and an output.log.

[cantab]

I've seen goofy behaviour when hitting water in the current FAR release. And by goofy behaviour i mean a crash at subsonic speeds launched some parts over 5 km high.

Of course it may already be resolved in dev. I'm not making seaplanes or boats atm so I'm fine waiting for the release proper.

[Phos]

Ok, for some reason, trying to reproduce Salawat's problem fixed mine.  If I'm interpreting what's happening here right, It seems if you don't go through either the garage or making a new game (not sure which) once, something doesn't initialize.  

[steve_v]

6 hours ago, Phos said:

I'm not sure if the dev build fixes this (cause I don't know my way around github and can't find anything labeled "dev build"), but...

Hit the The source at GitHub link in the OP, You should see a "Download zip" button on the right just above the file listing, this is what you want - specifically the "GameData" subdirectory in that zip.

It's always worth giving the dev build a go before reporting bugs, your issues might already be fixed.

 

Edited December 30, 2015 by steve_v
D'oh, there's a direct link.

[tetryds]

@steve_v NO, that is FALSE.

You are missing some important things.

Do not tell people how to get a dev build, think about it as a requisite for testing something that can even be broken on purpose.

[blu3wolf]

I suspect that would make it a prerequisite, then.

[steve_v]

22 minutes ago, tetryds said:

 NO, that is FALSE

False as in not where the dev build can be found, or false as in NOT SHOUTING ENOUGH?
 

22 minutes ago, tetryds said:

Do not tell people how to get a dev build.

It's some kind of secret then? Not very well hidden if that's the case.
Besides, I wasn't suggesting that one should use the dev build, simply that testing the dev build first is better than reporting (possibly already fixed) bugs repeatedly.

Edited December 30, 2015 by steve_v
Horrible editor, as usual.

[Phos]

14 hours ago, steve_v said:

 

Hit the The source at GitHub link in the OP, You should see a "Download zip" button on the right just above the file listing, this is what you want - specifically the "GameData" subdirectory in that zip.

It's always worth giving the dev build a go before reporting bugs, your issues might already be fixed.

 

 

6 hours ago, tetryds said:

 

@steve_v NO, that is FALSE.

You are missing some important things.

Do not tell people how to get a dev build, think about it as a requisite for testing something that can even be broken on purpose.

I downloaded the "master" zip, and seeing no branch labeled "release" I assumed that's what master was, because the readme still described it as the same version number.  I guess it hasn't been updated yet?  

[steve_v]

8 hours ago, Phos said:

I downloaded the "master" zip, and seeing no branch labeled "release" I assumed that's what master was, because the readme still described it as the same version number.  I guess it hasn't been updated yet?  

The released versions can be found under the "41 releases" link on that page, "master" is the current unreleased/WIP code, aka. the dev version. The readme etc. generally get updated when a new release is made.

[soulsource]

On 22.12.2015 at 9:45 PM, ferram4 said:

@soulsource: I found the exacerbation, but it still seems like there's something left over in stock.  No idea what the source of that is though.

Sorry for the late reply - holidays kept me AFK. Thanks for looking into it. It's not really surprising it's a stock issue, given that one observes it in vacuum. ;-)

[Salawat]

On 12/30/2015 at 6:20 PM, ferram4 said:

@Salawat: You're basically telling me that every single non-wing part in FAR is broken.  No, I can't reproduce any issues with any of that, and I'm afraid that since you're using CKAN you're ineligible for support.  Since no one else has any issues like that, I'd say CKAN is probably somehow the cause of your issue through an install screwup of some kind, so you're completely on your own here.

My apologies.  Didn't realize the CKAN install was separately supported.  I've lurked in the thread a long time, so must have missed that edit.   

Though I should also refine the description by saying that when I pulled down the master build, that was installed ye olde fashioned way.  Package management is nice, but when stuff starts screwing up, that's the first thing I throw out. 

In the spirit of things, I'll double check with another straight from master pull of both the ModularFlightIntegrator and FAR. 

I understand how Herculean the task of supporting something like this is; I'm a QA by trade.  Let me see if I can't get you a bit closer in the stack.   

EDIT: 

Ah hah!  Found the issue.  I'd done ye olde fashioned install for FAR, but the ModularFlightIntegrator .dll seems to have been the source of the issue.  That's what I get for not verifying the dependencies fully. 

Remember folks, ALWAYS check your full dependency chain! 

Edited December 31, 2015 by Salawat