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

[ferram4]

@Motokid600: Why do you need to send the thing up fully fueled? Drain it of fuel using tweakables and then send several refueling missions to fill it up. That should cut the payload down to ~250 - 300 tonnes, which is a lot more manageable. I'd suggest using some fins and a series of short, fat SRBs at the bottom to help put most of the drag at the bottom before you're high enough up for the thrust vectoring to be enough to make it controllable.

@celem: So... where's the vertical tail? That tiny little thing in the back isn't enough for your purposes. What's happening is that the plane is starting to sideslip, which causes different sweep angles on the wings, which causes more lift and a lot more drag on the less swept wing, which leads to rolling. Besides that, softweir is right; your control surfaces are assigned completely backwards.

@S4qFBxkFFg: Yeah, it's the double attach nodes on that pod. Unfortunately, there's nothing I can do, since I need to use attach nodes to determine the size of the blunt end of objects. So basically, it's not going to be compatible with FAR unless that lower attach node is scrapped.

Yes, it makes sense to build swing wing aircraft if you can design around the structural issues inherent in that type of design.

@Agathorn: I suppose that makes sense. I'd rather do it the "right" way if I can though, but I'm not exactly sure what a proper API would entail. Any suggestions on that end?

@Boamere: It's easy to make your plane less stable: move the CoL forward. Without pictures though, I can't tell if there are other issues that you're not mentioning.

[Surefoot]

@Boamere: look at the delta design i posted a few pages ago. I use a combination of anhedral and CoM manipulation (tanks to the rear..) in order to get some unstability, also the CoM closer to the control surfaces make it better at transonic (mach tuck almost gone, the plane only shudders briefly when going over mach 1 and that's it).

[Agathorn]

@Agathorn: I suppose that makes sense. I'd rather do it the "right" way if I can though, but I'm not exactly sure what a proper API would entail. Any suggestions on that end?

A great example is RemoteTech2: https://github.com/Cilph/RemoteTech2/tree/master/src/RemoteTech2/API

Basically just make one class with public methods to access all the information you want to expose. It is then very easy to dynamically hook into it from another AddOn.

[Camacha]

We can't get the high-performance fly-by-wire in KSP

Not yet, I would say. We are currently looking into making this possible. The first part - controlling the craft directly via software - has already been implemented by erendrake. The plan is to make indirect user inputs possible in the future, probably including joystick controls. That way people can write their own scripts to translate user input indirectly into vehicle output - which means fly-by-wire is possible. This can be as simple as coordinating controls or limiting things like tilt, or as complex as balancing an inherently unstable aircraft.

Edited February 24, 2014 by Camacha

[Captain Sierra]

Personally, I'd like for the water to be Ferram'd as well. It'd make submarine style vehicles doable, and someone might be crazy enough to create a plane that can survive diving straight into the water... Not saying that this someone is me, of course.

Given the way that water currently works in KSP (at least based on my knowledge of it) I don't think that anything can really be done on my end to fix it. Also, fluid interfaces can be really, really nasty to work with, so that's an entire new bit of code to try and handle the switch from atmosphere to ocean.

-snip-

A plane underwater is possible if it has rockets and a properly shaped nosecone. Basically, it relies in supercavitation to create a gas bubble under the surface. Hydrodynamics is already some seriously difficult physics to simulate with any accuracy and adding realistic supercavitation, even if it's just a custom part module, would result in a physics simulation that would pretty much destroy your computer the second you get near water (because I would hope the simulation would model badass roostertails as we race over the ocean at 3 times the speed of sound).

[SSSPutnik]

I posted this query in Addon Support if anyone wants to have a look/comment.

http://forum.kerbalspaceprogram.com/threads/70666-FAR-Massive-drag-issue?p=987830#post987830

[Tidus Klein]

Hay feram I had an idea that may allow you to simulate the vacuum behind large, or small, blunt objects during reentry and sonic flight.

DRE simulates the shock-wave generated by a part flying through atmosphere.

The nose or heat shield that is cutting through the air first makes a shock-wave, and parts behind that object are registered as shielded from said wave, to a certain length (and with).

I was wondering if there was a way to implement this in to FAR, with any part shield by the shock-wave to produce even less drag then normal and depending on the speed and size of the shield to produce zero drag do to vacuum behind.

The only problem that I can see from this is when flying a space plane the front wing/fuselage making a vacuum behind it, confusing the program to generate zero lift for thous wings, thus ending sadly. ITS only an IDEA.

Edited February 24, 2014 by Tidus Klein

[Boamere]

@Boamere: look at the delta design i posted a few pages ago. I use a combination of anhedral and CoM manipulation (tanks to the rear..) in order to get some unstability, also the CoM closer to the control surfaces make it better at transonic (mach tuck almost gone, the plane only shudders briefly when going over mach 1 and that's it).

Thanks! will try now

[Aedile]

I think the big change on the back, has unnecessary big drag. I understand the low pressure reverse lift, but no, it's just too extreme. The heat shield at reentry having half the drag than the adaptor on the back, is not exactly the way it should be

[DragonEG]

ferram4

I have a minor bug for you: you forgot to check input values in FAR analysis system. If someone (like me) puts a, say, 0 in "Mach Number" input box for Stability Derivatives in SPH - this player immediately gets empty FAR window, unresponsible buttons of KSP and output log full of:

[EXC 20:23:44.567] ArithmeticException: NAN
[EXC 20:23:44.568] ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting

[ferram4]

@Tidus Klein: DRE actually doesn't simulate the shock generated by a part; it just uses raycasting to determine if a part should be heated and then uses a simple correlation to calculate the temperature.

The problem with your idea is that as a result a rocket flying through the air will only have drag on its nosecone; all the other parts will be "shielded." Further, it'll result in different results for different length parts, due to the location and length of the "shielded" section. Finally, creating the proper shape region for all this to happen is a complicated affair in itself.

@Aedile: What are you trying to reenter that has that kind of drag difference, a tiny heat shield with a gigantic adapter behind it?

That said, the low pressure drag behind vehicles has been artificially boosted to make rockets more stable; KSP rockets don't have the mass distribution, thrust vectoring or ability to be aerodynamically tailored that are necessary to make designing stable, controllable rockets easy. It's a hacked solution because changing thrust vectoring and engine masses is outside of FAR's scope.

@DragonEG: I'll look into that. Next time though, post the output_log.txt, not KSP.log; KSP.log doesn't have the valuable stack trace, so I don't know where the system is actually breaking.

[a.g.]

That said, the low pressure drag behind vehicles has been artificially boosted to make rockets more stable; KSP rockets don't have the mass distribution, thrust vectoring or ability to be aerodynamically tailored that are necessary to make designing stable, controllable rockets easy. It's a hacked solution because changing thrust vectoring and engine masses is outside of FAR's scope.

Since nodes on engines produce so much drag, I came up with this exploit recently using the service compartment tubes:

The tube is a cargo bay, so (with fixed FAR) it shields everything except itself, and its own nodes are both used. Incidentally, some cargo bays (MK2 bay in B9 for instance) may have nodes inside them, and it seems that FAR doesn't do anything to account for that in the code. Of course, another problem with those B9 bays is that their doors don't appear to have colliders, so FAR thinks they are always open.

[ferram4]

Yeah, I need to find a better, non-attach node way to work these things out, I'm just not sure how to do it. All of the possible solutions that I come up with fall apart when faced with things like the 6-way node, or the B9 HL fuselages, or the bi / tri / quad-couplers.

Unfortunately, I'm starting to think that the way that everything has been going that I'll have to require top-down, config-only setups for parts and that FAR won't be able to automatically set things up anymore, simply because it's at the point where I have to throw out all of the simplifying assumptions I've been using up until now.

[Aedile]

No no, very legitimate vehicle. 2.5m shield, battery, can, fairing base, adaptor (2.5-1.25 stock), docking port.

I set it on 40k reentry directly from mun escape, turn sas off. Once it reaches the atmosphere, can orients itself properly and enters really smoothly. (less than 40k nets me around 8G reentry) On closer observation, you see the adaptor starts draggin 0.2kN from 60k, and at attitude of 35k, the adaptor gets 50kN, while the shield gets 17kN.

At 15k my speed has dropped to around 250, I am almost vertical, and the shield gets around 8 while the adaptor 40kN.

At attitude of 1500m, I have reached around 50m/s.

It's basically the same with squad and KW and b9 adapters, larger than 2.5 m. Oddly enough if you actually leave the adapter, and leave docking port directly attached to the can (or fairing base), you get far less drag, and with 40k pe you'll need to do a double dip reentry.

Hope that helps

[Pockrtplanesairways]

Subtle warnings.

[a.g.]

Yeah, I need to find a better, non-attach node way to work these things out, I'm just not sure how to do it. All of the possible solutions that I come up with fall apart when faced with things like the 6-way node, or the B9 HL fuselages, or the bi / tri / quad-couplers.

What's the problem with those exactly?

Unfortunately, I'm starting to think that the way that everything has been going that I'll have to require top-down, config-only setups for parts and that FAR won't be able to automatically set things up anymore, simply because it's at the point where I have to throw out all of the simplifying assumptions I've been using up until now.

I think that requiring manual configuration for all parts would be bad, because of mods. For the most part things seem to be working tolerably, so maybe you can instead make it easier to supply override configuration where necessary - currently I have no idea how to configure a part manually, because of all the numerous and mysterious for me parameters. One simple thing may be to provide a way to export the automatically guessed data for a part as an explicit config, so you can then edit it instead of computing everything manually from scratch.

[ferram4]

If I try to detect the area the attach node covers for the mesh, then the B9 HL fuselages (which have attach nodes on the sides for the extension parts) will end up having a huge area detected for that one part, and it's especially problematic since the drag that should be applied by that is already taken care of it the modeling of the fuselage as a cylinder. As for the couplers, the problem is figuring out which area to give to each attach node; for the current ones we have it's the slightly less complicated matter of finding the total area that all of that group of nodes account for and then dividing it up evenly, but if a mod comes along and has different size connections in a coupler it breaks horribly.

I guess I can look into making it possible to export drag parameters and add more documentation on what stuff does. The main issue is that FAR has very specific assumptions that it's built around (convex part shape that can be approximated by a conical frustum, part diameter ends are only set sizes that can be defined with proper attach nodes, modders will set up attach node sizes correctly), and when those assumptions are violated it breaks, often really badly. Ultimately, the problem already comes down to mods, since those are the ones most likely to violate the assumptions; Squad already seems to have a bunch of ground rules for how to shape a part, I assume because they're looking ahead to some type of aerodynamic implementation.

Edited February 26, 2014 by ferram4

[Aedile]

I think assumptions are just fine, most models will have issues with some specific cases. And honestly compared with the stock model, the issues FAR is having are minor at best.

Anyway personally only thing which bothers me from realism PoV, is the excessive shape drag on the back.

Just made a reentry test with reentry from 100km orbit with 30km pe,with vehicle consisting of 1.25>2.5 adaptor, 2.5m lander can and adapter again. Seemed like the adapter in the front and the one on the back had almost identical drag (at 25k back was 49kN front was 53kN). It's consistent with a lone can or mk1-2 pod, but it just seems odd that you'll get almost same drag on each side.

As to why heat shield has so much lower drag, I have no clue.

[thorfinn]

Anyway personally only thing which bothers me from realism PoV, is the excessive shape drag on the back.

Yeah, that's a problem when you build shuttles, with all the idle engines at the back of the glider the tendency to lawndart can get really strong.

I don't remember, is there an extra drag boost specifically for engines or just for any unattached node at the back?

Edited February 26, 2014 by thorfinn

[ferram4]

@Aedile: I've got a fix in the works for the adapter, since that shouldn't be happening. I just need to test the numbers a bit.

@thorfinn: It's for all unattached nodes, forward and backward (not on sides though); they just use different values for front and back. The attach node drag on the back can be reduced by going into the config.xml and setting incompressibleRearDrag to 0.01 and additionalSonicRearDrag to 0.2, and then that will be at realistic levels.

[thorfinn]

Thanks a bunch, I was going to ask just that but then I though "he just said he wants to redo everything, maybe it's too much of a pain"

[SkyRender]

I can't believe how long I put off trying out FAR. I can believe even less how quickly I managed to master it enough to pull up about 1200 to 1500m/s extra dV in orbit with rockets and spaceplanes alike. This mod is amazing.

[drtedastro]

I would really love to be able to 'understand' more about this mod, it displays and its parameters.. Is there a "FAR for dummies", or what does everyone think is the best tutorial..???

Many thanks in advance...

[AbeS]

There is a Scott Manley video in the OP IIRC, it's part of his interstellar quest series. He explain most of the stuff, or at least what you should pay more attention to.

EDIT: Here it is:

[drtedastro]

Thanks AbeS...