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

[Tiron]

Okay monsieur Ferram, here's a dumb question. I've been experimenting with a very alpha part from a B9 expansion pack. It's a helicopter rotor that folds into a cute little V-Shaped wing. Using firespitter, natch.

The question is, it's using FSLiftSurface (firespitter) for the wing mode, and I can't tell if it's working with FAR or not. It completely overrides the CoL in the VAB and it's not showing aero forces(yes I turned them on) or a 'stalled' gauge in flight. It also seems to produce an absolutely ENORMOUS amount of drag.

And I'm not getting much in the way of illumination from reading the docs, unfortunately.

I just slapped it on my science plane to play with it, the sheer unrealism of which does bug me a bit so I may design a new vehicle if I decide to use it.

Edit: I talked to Snjo and what he said (I'm not sure he understood exactly what the part actually was) implied that the FSLiftSurface is supposed to turn itself off if it detects FAR...but since there's no FAR module in there, it might not be. He also said something about how adding one would make the lift 'static', which so far as I can tell it already is, at least when it's in 'wing' mode and not 'rotor' mode. If I add a FAR wing module to it, how bad is it gonna blow up on the rotor mode?

And here's a short vid of the thing in action:

Edited May 7, 2014 by Tiron

[Cakeofruit]

hi all

i wanna know if is possible to get FAR data to K-OS ??

[bludclot]

Thank you ferram! I have not thought to look for it there.

Also it is because of this scale thing I think things disintegrate a bit too easily. Specially since struts seem to have no impact on things breaking.

I am having a hard time flying anything like I do in this video:

. Not even that thing. The wing parts break off from the centre fuselage as soon as I pull back on the stick. I used to have it working wonderfully in 0.13 with deadly reentry being my Gforce limiter. Working on a complete rebuild though.

@softweir That!

[softweir]

The question is, it's using FSLiftSurface (firespitter) for the wing mode, and I can't tell if it's working with FAR or not.

IIRC, Firespitter uses its own lift/drag model which completely overrides FAR for Firespitter parts.

[HeadHunter67]

There are lots of people who think that 300 m/s is slow (for some reason)

That boggles my mind, since at typical flight altitudes, that's supersonic!

I just started a new game with FAR and noticed that Kerbal Engineer no longer shows terminal velocity. I know the FAR window does, but there's a lot of other stuff there I don't need. Is there a way to re-enable it? Nothing in the KER settings, it's possible that there might be something in the FAR settings but seriously I get information overload just looking at all that stuff.

[AndreyATGB]

300m/s seems slow because most people probably started building rockets first and the typical speed for that is 2200m/s. For me all I need to do is multiply by 3.6 and jaws will be dropped, like when I first realized my "slow" rover was only going 40m/s which is rather fast IRL. Also because nobody is willing to wait hours for a plane to fly somewhere as opposed to orbital velocity at which it only takes a couple of minutes.

[Yar987]

This is more an overall suggestion, but seeing as this mod strives for realism for in-atmo flight I thought it'd be a good place to bring it up. I've seen it mentioned a few times here and there, but not seriously implemented. Fuel should primarily be carried in the wings, not the fuselage. It's how actual aircraft manage to be so stable, it keeps the CoM as close as possible to the CoL. It's especially important for low mount wings, which tend to have a low center of lift.

For larger planes, CoM limitations and the actual CoM are expressed in references to mean aerodynamic chord. That's used to calculate the chord for tapered or swept wings (most airplanes), and it gives you the aerodynamic center (center of lift) of the wing.

Just some food for thought!

[Dirt_Merchant]

This is more an overall suggestion, but seeing as this mod strives for realism for in-atmo flight I thought it'd be a good place to bring it up. I've seen it mentioned a few times here and there, but not seriously implemented. Fuel should primarily be carried in the wings, not the fuselage. It's how actual aircraft manage to be so stable, it keeps the CoM as close as possible to the CoL. It's especially important for low mount wings, which tend to have a low center of lift.

For larger planes, CoM limitations and the actual CoM are expressed in references to mean aerodynamic chord. That's used to calculate the chord for tapered or swept wings (most airplanes), and it gives you the aerodynamic center (center of lift) of the wing.

Just some food for thought!

This is something that has been discussed in this thread time and time again. It is too easy to add fuel to the wings yourself, and leave yourself responsible for the balance. Educate yourself on Modular Fuel System or Real Fuels, and learn how to add fuel tanks to parts.

[ferram4]

@Tiron: The way the rotor is currently set up there is absolutely no way for FAR to support it. FAR doesn't include code for turning wings on or off at will, nor does it include code for even figuring out the orientation of lift on a part like that. Hell, you won't even be able to get proper lift out of the thing since it'll all be offset to one end (due to how the wing modules work).

Unfortunately, I think that there is no way to make that part FAR compatible without a large amount of code changes on my part that simply won't be useful elsewhere. It'll also add a lot of additional computational overhead to make all that work. Sorry, I think you're going to have to leave it incompatible with FAR. The alternative is to include a ModuleManager patch to the FARPartClassification node to make FSLiftSurface exempt from FAR's drag modelling and then figure out something else yourself.

@Cakeoffruit: Not currently supported. Maybe in the future, but not now.

@bludclot: Struts have no affect on things breaking since it is meant to model internal failure on the pats, leading to it breaking off of the vehicle, not part-to-part failures. As for what you were doing, without seeing a velocity readout I can't compare what you were doing then to what it takes to cause FAR to break things. For all I know you're flying with a Q of 30 kPa half the time, with the attendant risks in destroying the aircraft.

@Yar987: This mod strives to model aerodynamics properly. Location of fuel and CoM on a vehicle, while crucial to building stable airplanes, is out of the scope of this mod.

[Tiron]

IIRC, Firespitter uses its own lift/drag model which completely overrides FAR for Firespitter parts.

Actually, FSliftsurface contains code to shut itself off if FAR is detected, but apparently, due to the fact that there's no FAR module anywhere that applies to it/the sheer weirdness of it, it's using it anyway.

@Tiron: The way the rotor is currently set up there is absolutely no way for FAR to support it. FAR doesn't include code for turning wings on or off at will, nor does it include code for even figuring out the orientation of lift on a part like that. Hell, you won't even be able to get proper lift out of the thing since it'll all be offset to one end (due to how the wing modules work).

Unfortunately, I think that there is no way to make that part FAR compatible without a large amount of code changes on my part that simply won't be useful elsewhere. It'll also add a lot of additional computational overhead to make all that work. Sorry, I think you're going to have to leave it incompatible with FAR. The alternative is to include a ModuleManager patch to the FARPartClassification node to make FSLiftSurface exempt from FAR's drag modelling and then figure out something else yourself.

I was afraid of that. It's already *got* 'something else' set up, namely firespitter, and I'm honestly not at all sure it actually *is* 'turning the lift off' when it switches into Rotor Mode as it is (at the very least, during the transition, there isn't a *hint* of instability, even when the wings are out of position). Somehow he managed to get the lift oriented correctly with FS though: it's centered a bit behind the rotor shaft when they're folded, which is what you'd expect from a wing swept like that, I'm pretty sure.

The mod it's from is technically in Pre-Alpha, and I myself am at this point merely experimenting with it (which is why it's on a plane even though that makes NO sense at all.) It occurred to me how a helicopter would be nice for landing to collect science/visit anomalies, but also that helicopters and Tilt-Rotors are...not exactly fast. Patience is not exactly my strongest suit, so when I saw something that could 1.) Give STOL/STOVL/VTOL capability 2.) Still be absurdly fast 3.) Not have useless parts hanging off in one flight mode or the other, I said 'Okay, I'm trying that.'

The Drag is just TREMENDOUS, though. There's a workaround for that(FSliftmodule has a 'drag multiplier'), but I figured I'd see if it could be done properly before I went there. Now I gotta decide if I wanna try to modify it to fit in better or just try to do a more traditional VTOL. (The plane in question turns out to be very well balanced, far better than I expected, but I don't know where the heck I'd stick VTOL engines on it.)

Edit: Preliminary testing suggests that it probably does just have the lift from the 'wing' mode active at all times, and the switch is just cosmetic (other than it being unable to generate thrust while folded). Switching into 'rotor' mode in the VAB doesn't change the CoL, and it also doesn't seem to have any effect in flight.

I'm still working on testing it with the rotor engine active, as the rotor uses the throttle, and thus for such a test I really need to have the throttle cut.

Edit2: Got a decent glide test. Lift characteristics don't seem to change based on what mode it's in. Given that it's (apparently) already acting as a combination of a static wing and a rotor, is there a way to make the static wing part at least FAR compatible or is it still a 'nonono' because of it being two wings instead of one.

Edited May 7, 2014 by Tiron

[Guest]

@Tiron: The way the rotor is currently set up there is absolutely no way for FAR to support it. FAR doesn't include code for turning wings on or off at will, nor does it include code for even figuring out the orientation of lift on a part like that. Hell, you won't even be able to get proper lift out of the thing since it'll all be offset to one end (due to how the wing modules work).

Unfortunately, I think that there is no way to make that part FAR compatible without a large amount of code changes on my part that simply won't be useful elsewhere. It'll also add a lot of additional computational overhead to make all that work. Sorry, I think you're going to have to leave it incompatible with FAR. The alternative is to include a ModuleManager patch to the FARPartClassification node to make FSLiftSurface exempt from FAR's drag modelling and then figure out something else yourself.

Are you sure this wouldn't be useful elsewhere? Because I think it would. It works off Firespitter's lift module, which is used for built-in slots and variable sweep wings. Even if the rotor itself wouldn't work (if it would for some reason need more changes than just animation-dependent lift), could you consider accounting for stuff like variable sweep? In general, Firespitter's animated wings really need to be supported.

[Tiron]

Are you sure this wouldn't be useful elsewhere? Because I think it would. It works off Firespitter's lift module, which is used for built-in slots and variable sweep wings. Even if the rotor itself wouldn't work (if it would for some reason need more changes than just animation-dependent lift), could you consider accounting for stuff like variable sweep? In general, Firespitter's animated wings really need to be supported.

The Rotor's complicated as heck because it has to do entirely different things based on which mode it's in (which is why it's actually not doing different things in each mode.) I would think Variable Sweep would be more easily achieved, however. You would think, at least.

Not automagically, I suspect, as Firespitter and FAR use completely different setups for defining wing lift...

Edited May 7, 2014 by Tiron

[bludclot]

@ferram The way I see it the main benefit of using FAR is that lifting bodies is possible. Making these with KSP parts means having to use wing parts to sculpt fuselage parts. I would love if the disintegration would interact with the standard physics system so it would be possible to work around it with all the tools we have at our disposal. Our normal methods of reinforcement should work to this effect.

Can you not use the same rouitines but instead apply the force to the existing physics model instead of adding arbitrary point of disintegration?

Atm I feel like you are trying to force us to confirm to a single way of thinking when designing craft.

I see where you are coming from with this and I totally agree. I just think the method is too simple for simulating the problem.

Edited May 7, 2014 by bludclot

[ferram4]

@Tiron: Of course the drag is tremendous. There's nothing there telling FAR not to have a go at adding its own drag model to that thing, and it's probably setting it to have a very large reference area and a decent amount of drag. It's always going to be a no-no because FAR isn't set up to combine two wings with different sweep into one part, and that's not something I'm planning on adding. It would require double the computational overhead for that part as a normal wing part would take.

@Dragon01: No. There is no way for me to detect what the animation is actually doing, which means that every single change that happens will need to be defined by the part creator. And that is something that I've been trying to get away from and would only reinforce the need for FAR-specific configs on parts. It's currently necessary for wing parts, but I don't want it to be necessary forever and I certainly see no reason to entrench that further. Especially since most of the things that can be done with Firespitter parts can already be done (and much better, I think) with a combination of FAR's flap settings and Infernal Robotics.

@bludclot: Let me explain to you why that doesn't work. First, the aerodynamic forces applied to parts in the recent update did not change at all. But parts didn't break off due to aerodynamic forces prior to the recent update. That's because the new joint system uses the JointDrive parameter to apply forces to parts to hold them in place. The only problem is that forces applied by JointDrive don't count towards the forces needed to break a joint. And the JointDrive spring constant is set to the maximum stiffness that it can hold (Float.MaxValue) and the JointDrive max force value is also set to that value. So basically, barring a physics glitch that causes the parts to shift just enough that the underlying non-drive connection takes the hit, parts will never break due to forces. Have you noticed that joints never, ever fail due to forces applied since 0.23.5 hit? That's why.

So it's not possible for the current joint system to handle failures of the type that we would like to have. So I have to work around it. Only way to get them back is to either roll back to the old joint system or to recode the joint system so that PhysX will properly allow joints to break.

I'll also note that the "arbitrary" point of failure is based on the kind of loading that a wing would expect to have in flight. A large amount of math got calculated out to figure out those numbers, they're not just completely arbitrary.

[bludclot]

@ferram to me it just feels arbitrary because of the problem I illustrated. Since we are limited to using the same parts in many different ways and this method kind of narrows down what is actually possible to do by quite a bit.

I do not doubt your numbers as your knowledge on the subject is vastly superior to mine. However I feel the realism of it is questionable due to the sensitivity and complete disregard for variation in part usage.

To me simulating it in such an inaccurate way kind of beats the whole purpose of FAR as I see it.

[NathanKell]

Then, it comes down to FLYING: UR DOIN IT WRONG. It's perfectly possible to fly safely with FAR, you just have to lighten up on the controls, use the FAR flight aids, and design your craft well. Now, you can do one fewer impossible thing than you could do before. That's good. It makes you a better designer and pilot.

I can and will post Mach 3-at-sea-level, perfectly controllable aircraft if that's what it takes.

[Tiron]

@Tiron: Of course the drag is tremendous. There's nothing there telling FAR not to have a go at adding its own drag model to that thing, and it's probably setting it to have a very large reference area and a decent amount of drag. It's always going to be a no-no because FAR isn't set up to combine two wings with different sweep into one part, and that's not something I'm planning on adding. It would require double the computational overhead for that part as a normal wing part would take.

I hope by 'different sweep' you mean 'in opposite directions'. It isn't actually a movable wing, doesn't have variable positioning or sweep or anything. In fact, it appears that the model has an invisible, static 'liftsrf' component that functions as the lift generating portion, completely independently of the visible rotor.

In short, it *looks* like a rotor that turns into a wing, but functionally it's a folding rotor that has a built-in static wing attached to it(which happens to be invisible so it can pretend to turn into a wing).

I'll try flagging it as a greeble maybe, see what that does, but I'm pretty sure the drag's mostly coming from the fact it's using firespitter's lift system. When I turn on aeroforces display it doesn't show any, so I don't think it's interacting with FAR at all.

Edit: I exempted FSliftSurface, that's the only thing that I have which is using it anyway.

Edited May 7, 2014 by Tiron

[ferram4]

@bludclot: Yes, I agree. It's completely arbitrary that 2024 aluminum has a yield strength of 324 MPa. However, this is not my department, and I would advise you to send all complaints to whichever deity your religion has designated as the go-to for complaints/suggestions/requests.

Snarkiness aside, if you've got a better model for the failure strength, I'd be happy to hear it, but complaints about a functional system without presenting a working alternative is unhelpful. I've explained why it can't be done through the existing physics simulation, but simply complaining that you don't like it doesn't help.

Oh, did I mention that planes should fly apart a lot more easily, but I'm not simulating flutter? Maybe I should get to work on that...

@Tiron: Sweep in opposite directions is not supported. You might be able to manage it if you set it up as an oblique or straight wing, but as it currently stands, anything you try will be wrong.

[bludclot]

Flutter would be a very welcome addition.

Your butthurt aside.

The only reason I cared to share my points is that your plugin is the sole reason I still play the game after 2000 hours.

[Tiron]

@Tiron: Sweep in opposite directions is not supported. You might be able to manage it if you set it up as an oblique or straight wing, but as it currently stands, anything you try will be wrong.

Unfortunately, I'm not sure what the shape of the actual liftsrf is because invisible. I'm not sure it matters, because I gather FAR assumes that the lift in question is applying to the entire model anyway. Firespitter lets you designate, which is probably why the wing-rotor thing has has a separate component for the lift in the first place. Which is why the CoL of the part doesn't change when it changes shape, or when the rotor's flipped on (rotor = thrust, not lift.)

It *might* be possible to fake it as a non-swept wing, I have no idea.

Edited May 7, 2014 by Tiron

[ferram4]

@bludclot: Well, thank you for your input. Like I said, if you think the realism of it is questionable, propose a better model and cite the theoretical or empirical basis for it. Data, not feelings.

@Tiron: FAR doesn't really have any elegant way to handle that thing. Probably what it's doing is creating a cylinder to shove the entire thing into (axis parallel to the rotor axis), and that giant thing is where the problem comes from. You have to look at it and realize that FAR doesn't know much about the actual shape of the part and functions (for things not given a special FAR wing model to work with) as if the part is some type of elliptical-based frustum. This is why FAR has issues with LLL parts and similar things that move further and further away from stock-like shapes; it just doesn't have any way to analyze the shape in a reasonable way. FAR only works as well as it does because it can approximate and assume away lots of complications that can't be done for a model like yours. Hell, the thing I'm working on to replace FAR might not even be able to handle something like that properly.

[phoenix_ca]

Jesus-shiva-allah-lao-tsu-no. Not flutter. We already have enough problems to deal with as it is! I mean...our wings aren't even contiguous parts like they are on a real aircraft! And it's not like we can control the shape of the airfoil very accurately either. I could do much better with a slab of balsa wood (and have, actually...fun times of youth).

[Tiron]

@Tiron: FAR doesn't really have any elegant way to handle that thing. Probably what it's doing is creating a cylinder to shove the entire thing into (axis parallel to the rotor axis), and that giant thing is where the problem comes from. You have to look at it and realize that FAR doesn't know much about the actual shape of the part and functions (for things not given a special FAR wing model to work with) as if the part is some type of elliptical-based frustum. This is why FAR has issues with LLL parts and similar things that move further and further away from stock-like shapes; it just doesn't have any way to analyze the shape in a reasonable way. FAR only works as well as it does because it can approximate and assume away lots of complications that can't be done for a model like yours. Hell, the thing I'm working on to replace FAR might not even be able to handle something like that properly.

First off, it's not mine. It's made by a guy named PolecatEZ. I'm just not averse to modifying things. Second, so far as I can tell, it's not actually using FAR in the slightest: the drag's coming from Firespitter, which I can hack away with Firespitters drag multiplier if I really have to. This goes double since I added FSliftSurface to the 'modules to ignore' list in FAR.

I just prefer doing things properly to using dirty hacks, if it's possible, and I'm trying to figure out if I can modify my own personal copy of the part to work something like approximately correctly. Working a bit unrealistically in FAR would be better than working extremely unrealistically in Firespitter, from my perspective.

And I've Gathered FAR doesn't really reference the models like most people think it should (IE: Parts inside other parts still have drag, even though 'stuff in front lowers drag of stuff behind' is supposed to be one of the things FAR does.) That being the case just makes the possibility of the slightly-less-dirty hack I have in mind MORE likely rather than less.

It doesn't have a FAR module AT ALL. It's using EXCLUSIVELY firespitter. It has a single wing, unrelated to the rotor system, which is static and active at all times. The visual of it folding into a wing is purely cosmetic and has nothing to do with the operation behind the scenes.

Is it possible to attach a static FAR wing, which would necessarily also be active at all times (this is not a change from current), to this thing at all, under any conditions or requirements whatsoever or not?

[ferram4]

First off, it's not mine. It's made by a guy named PolecatEZ. I'm just not averse to modifying things. Second, so far as I can tell, it's not actually using FAR in the slightest: the drag's coming from Firespitter, which I can hack away with Firespitters drag multiplier if I really have to. This goes double since I added FSliftSurface to the 'modules to ignore' list in FAR.

Is there a FARWingAerodynamicModel PartModule attached to it currently? If not, and you're using FAR, FAR is going to add a FARBasicDragModel PartModule to it, since there's no exemption for FSliftsurface in the FAR configs. And FARBasicDragModel can really screw up on parts like that.

And I've Gathered FAR doesn't really reference the models like most people think it should (IE: Parts inside other parts still have drag, even though 'stuff in front lowers drag of stuff behind' is supposed to be one of the things FAR does.) That being the case just makes the possibility of the slightly-less-dirty hack I have in mind MORE likely rather than less.

FAR does reference the models, but it doesn't go into the complicated mess of "how much is this part inside this other part" unless it's looking at cargo bays and payload fairings. The "stuff in front lowers drag of stuff behind" is related to parts attached in a stack, which makes figuring out how the drag of one thing affects another thing easier.

It doesn't have a FAR module AT ALL. It's using EXCLUSIVELY firespitter.

See above. It will have a FAR module attached to it, applied in-game, not in the config.

Is it possible to attach a static FAR wing, which would necessarily also be active at all times (this is not a change from current), to this thing at all, under any conditions or requirements whatsoever or not?

It's perfectly possible for you to attach a FARWingAerodynamicModel to it, but you're going to have to hack it as an unswept wing and add "nonSideAttach = 1" to the MODULE node to get it to center the CoL. If you said you wanted an inaccurate hack to begin with, you should have just asked for it.

[AndreyATGB]

Is there any particular reason wings and control surfaces don't get shielded inside fairings? It's making launching tiny unmanned planes hell.

For example: