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

[Hodo]

@ferram4: Very much enjoying the new release, I've no complaints or serious bugs to speak of at the moment, but I did want to revisit an idea I brought forth a few pages back regarding the control surface assignments. I have to admit that I absolutely deplore using the sliding tweakable menus to manipulate control surface deflections. I humbly implore you to at least provide the option for the use of the old style control surface assignment GUI page. That allowed me to do many things that I am no longer able to do, and it makes me a very sad tradesman of soil. Also, please, split aileron drag rudders that i can operate with my joystick instead of the action groups i used for the craft below.

Javascript is disabled. View full album

I submit this request with not but the utmost respect, and indeed gratitude!

Sincerely,

The merchant prince of dirt *bows and curtsies, drops mic, walks off stage left*

To post an album from imgur you should use this code [ imgur] xxxxx no # [/ imgur]

I fixed it in the quote of your post.

[Dirt_Merchant]

@Hodo: good looking out man, didnt realize I had left it in there.

[skiingrules88]

I'm having issues with FAR loading, that I think stems from toolbar issues, but I definitely have the toolbar folder in my GameData folder. Is there any configuration or something I need to do to get the toolbar to function? I've already done a clean install of Ferram and the toolbar and that did nothing.

[Narcan]

So ...I got the button for FAR in the VAB for planes, but no part available ...can you help me

[Hodo]

@Hodo: good looking out man, didnt realize I had left it in there.

Oh, and I love the aircraft!

[ferram4]

@ialdabaoth: I see what you're after here... so for the first problem you're looking at heat transfer through a boundary layer in both subsonic and supersonic flows (very complicated, but I think something can be worked out), which means that I'll need to drag out a lot of textbooks and probably come up with some kind of correlation for that. The second problem is a little bit simpler, since conduction is a little bit simpler of a problem than convecting fluid flow.

I figure I'll work out the math needed for the average temperature in the part and the peak temperature in the part, and you can use either of those for your purposes. I'll PM you when I have something that I think might work.

@JewelShisen: I can take a look at that, but given that his parts are quite a bit different than the standard types of parts that come with the game I don't think FAR will ever be able to properly support that. They end up violating quite a few of the assumptions that FAR uses, and that basically means that everything will be wrong for them.

@Dirt_Merchant: Unfortunately, I don't think that the old method is compatible at all with the current tweakables set up, and pretty much anything you could do with the old setup you can do with the current one (except perhaps very large negative deflections), and there are several things that you couldn't do, like combining flap and control surface actions. I haven't set something up for changing the zero-point of the control surface (that's still to be done) but I will see if I can set up split-aileron stuff. I'll see if I can find a way to make it useful in both pitch and roll as well, this way it can be used for that too (for madmen).

@skiingrules88: If you installed according to the instructions (moved everything over to the GameData folder), so that you have the Toolbar and FAR folders in there along with ModuleManager in the directory everything should work fine. The Toolbar should load up in the VAB / SPH and the flight scene with a FAR button and FAR's drag properties should be applied to your vehicles (right-click a part to see if it has a drag force readout). If that's not happening, I'll need you to post a full copy of the output_log.txt from KSP_Data so that I can figure out what the error is.

@Narcan: This is a partless plugin; it only changes aerodynamics, it includes no parts.

[Subcidal]

Not sure if it's been mentioned before but the fuel drop tanks in firespitter seem to cause some pretty crazy changes to CoL. If you place one on the bottom of a plane it will shift the CoL way down like you just put a wing down there. This results in your CoL being well below your CoM from a single drop tank. A bit of change to the CoL seems reasonable due to their size, but their causing waaaaay to much right now.

This is with 0.12.5.2, Not sure if this is the same in your experimental version.

Edited March 27, 2014 by Subcidal

[Tidus Klein]

@Tidus Klein: I'm going to end up nerfing all the jet engines a bit to compensate for the lower drag. Really, you should be using camlost's AJE for proper jet behavior.

A little late:

Ya sadly thou I dont want to have to download real fuels to use it, I also like the unrealistic power of the stock jet....0 to mach 5 is just soooo much fun

but i will try it.

[ialdabaoth]

@ialdabaoth: I see what you're after here... so for the first problem you're looking at heat transfer through a boundary layer in both subsonic and supersonic flows (very complicated, but I think something can be worked out), which means that I'll need to drag out a lot of textbooks and probably come up with some kind of correlation for that. The second problem is a little bit simpler, since conduction is a little bit simpler of a problem than convecting fluid flow.

I figure I'll work out the math needed for the average temperature in the part and the peak temperature in the part, and you can use either of those for your purposes. I'll PM you when I have something that I think might work.

Woohoo! While you're at it, an explanation of how FAR computes shape and surface area for a part would be awesome.

[toadicus]

Woohoo! While you're at it, an explanation of how FAR computes shape and surface area for a part would be awesome.

Just thinking out loud here: would it make sense for your eventual heat transfer mod to take advantage of the fact that FAR is already doing such calcs? IMO, it'd be a shame to implement the same model (more or less) two or more times on the notion that someone might not want to have both mods. Splitting that functionality into a third library against which both mods could link, or making one dependent upon the other (Ialdabaoth's Epic Heat Transfer Plugin of Power might depend on FAR, since FAR already does both shape and friction, at least after a fashion?), might both be good ways of consolidating the simulation and avoiding duplication.

[ialdabaoth]

Just thinking out loud here: would it make sense for your eventual heat transfer mod to take advantage of the fact that FAR is already doing such calcs? IMO, it'd be a shame to implement the same model (more or less) two or more times on the notion that someone might not want to have both mods. Splitting that functionality into a third library against which both mods could link, or making one dependent upon the other (Ialdabaoth's Epic Heat Transfer Plugin of Power might depend on FAR, since FAR already does both shape and friction, at least after a fashion?), might both be good ways of consolidating the simulation and avoiding duplication.

I would LOVELOVELOVE to just hand Ferram what I've got already and say, "here! Add thermodynamics and heat shielding to FAR!" - and then just have DRE be a damage system.

[Tidus Klein]

A little late:

Ya sadly thou I dont want to have to download real fuels to use it, I also like the unrealistic power of the stock jet....0 to mach 5 is just soooo much fun

but i will try it.

I tried it and you know what I think I like it.

a little tedious thou always having to tell the fuel tank what fuel I need. but manageable

[camlost]

I tried it and you know what I think I like it.

a little tedious thou always having to tell the fuel tank what fuel I need. but manageable

If you have anything to say regarding AJE, say it in my thread (see signature). All the engines use Kerosene, that's why you need RF. If you really, really, badly don't want RF, you can always convert name=Kerosene to name=LiquidFuel

[Motokid600]

So.. TWR.. is it not universal? I keep the same 1.44 TWR for ALL my rockets. So I was under the impression that I could follow the same ascent profile for all my rockets. I've been building small, 5ton payload rockets up until last night where I built a Saturn V. I noticed it took until 1km to hit 100m/s where id start pitching. Where in the past the smaller rockets with the same TWR hit 100m/s at 350 meters.

I also noticed my SaturnV started fighting gravity not long after pitching causing a stall so I had to up the TWR a bit and ease up the rate of pitch. It worked, but the ascent was a little steeper then id like. So why is it a larger rocket with the same TWR as all the others need a different ascent profile? The steeper ascent I can kinda understand with the rocket being taller, but not why it doesn't accelerate at the same rate.

[Diazo]

Control authority maybe?

The larger the rocket, the more control authority you need to make it turn as you want.

A small rocket that you tap A to turn significantly will be an easier ascent then a large rocket that would not even notice a tap on the A key.

Beyond that, I don't think TWR compensates for drag so a large vessel will actually be accelerating slower due to efficiency losses from the atmosphere.

D.

[Amaroq]

@Narcan -- download "procedural wings", you'll need procedural wings to get the balance right if you try to space-plane with FAR

[Dirt_Merchant]

@ferram4: As always sir, I trust your judgment here and look forwards to what you're working on. I had a thought, though that perhaps there might be a way to tie in spoiler deflection with a control axis, ie, if you tie it to yaw, it will deflect the same percentage (up to the deflection limits specified, either positive or negative) as would the rudder, regardless of its orientation relative to the rudder. With a setup like that applied to my example craft in my previous post, as I call for rudder imput, the spoilers would deploy as if they were rudders, even though they're not in the typical vertical stabilizing orientation. So ultimately what I'm asking for is a "dumb" ctl surface that would not deploy based on how it would affect the rotation of the ship, but would deploy based on what the control input for whatever axis(ies?) it was assigned. Does this make sense? I would imagine that would be easier than attempting to devise a way to build a split control surface system, or even a "smart" drag based control system and it would allow one to accomplish the same sort of functionality providing I employed the surfaces in a clever manner. This of course would also tie in to my desire for larger negative control deflections as well;) Thanks again for your hard work, I certainly would have walked from KSP long ago if not for you!

[Motokid600]

Control authority maybe?

The larger the rocket, the more control authority you need to make it turn as you want.

A small rocket that you tap A to turn significantly will be an easier ascent then a large rocket that would not even notice a tap on the A key.

Beyond that, I don't think TWR compensates for drag so a large vessel will actually be accelerating slower due to efficiency losses from the atmosphere.

D.

No control is fine. Plenty of that. Its the ascent profile. The rate at which you pitch the craft over. Is vastly different on my larger rockets then my smaller ones despite having the same TWR. My SaturnV is about 4 meters wide ( Stretchy Tanks ) so would an extra meter in diameter really make that much of a difference in the acceleration? Again despite having the same TWR? My SLS replica has trouble too. It needs a really steep ascent profile or it will stall and fall over.

[ferram4]

@Subcidal: Just checked in my current version and didn't see anything like that, so I don't know what the cause could be.

@ialdabaoth: I'm sure, but the problem is that the way FAR currently handles drag doesn't work so well for heating at all; it has nothing that would allow it to determine that it should add heating to only the heat shield and none of the parts behind it.

As for the way FAR currently determines shape and surface area, it takes the part's mesh and then assumes that it's some type of frustum of a cone. It takes a pretty good educated guess as to the axis, and then it determines the distances across the object perpendicular to that at either end. It averages them to come up with an approximate circular cross section to refer to and stores a ratio between the two axes for use handling body lift and drag. The tapering of the frustum is stored so that drag properties can be calculated from that and the surface area is calculated as the rounded area of the shape, ignoring the bases.

It works quite well for most parts, actually.

@Motokid600: Two rockets will only have the same ascent profile if and only if these things are the same between them:

TWR as a function of time (not just at launch)

DragArea:Mass as a function of time

Obviously, a rocket with a TWR that stays at 2 for the entire launch will have a much different ascent profile than one that starts at 2 and then reaches 6 before dropping down to 0.8, which then grows back to 1.5. It just sounds like you're not burning off mass at the same rate that you're used to, so the TWR isn't increasing like you think it should, so trouble. More massive rockets aren't as affected by drag, since mass goes with length³ but drag goes with length², so gravity easily overpowers drag at higher masses.

[camlost]

@Ferram,

I would like to have AJE use the atmosphere parameters from FAR. I need Mach number, static pressure and temperature. How do I access them from a FAR module?

-----Never mind, found FAR's code

Edited March 27, 2014 by camlost

[ialdabaoth]

@ialdabaoth: I'm sure, but the problem is that the way FAR currently handles drag doesn't work so well for heating at all; it has nothing that would allow it to determine that it should add heating to only the heat shield and none of the parts behind it.

As for the way FAR currently determines shape and surface area, it takes the part's mesh and then assumes that it's some type of frustum of a cone. It takes a pretty good educated guess as to the axis, and then it determines the distances across the object perpendicular to that at either end. It averages them to come up with an approximate circular cross section to refer to and stores a ratio between the two axes for use handling body lift and drag. The tapering of the frustum is stored so that drag properties can be calculated from that and the surface area is calculated as the rounded area of the shape, ignoring the bases.

It works quite well for most parts, actually.

Hmm. Will that work for say, Talisar's Spherical Tanks?

*thinks*

At one time, you were assuming one of various 'primitives' (cone, cylinder, sphere, plane) for each shape - is that code still present? Can parts tell FAR what geometric primitive to use for drag approximations?

[Motokid600]

Thanks ferram I would've never realised that.

[ferram4]

@ialdabaoth: Unfortunately, it won't. There's really not much to do there besides defining custom drag parameters for those parts since they violate the assumptions used by FAR's geometry determination.

The old "primitive" based code was removed a long, long time ago, back when I shifted over to much more exact measurements, and those methods weren't very good anyway. I suppose it's possible to set something up to take a primitive and work with it, but the problem is that I'd rather try to handle it in code rather than in configs; when FAR doesn't handle things automatically part modders get inundated with requests for FAR configs (as Helldiver and Nazari have been regarding the KSO), which they won't understand and don't want to mess with, or it gets given to me, and now I'm trying to make sense of someone else's parts and trying to figure out the best approximation to use on them. It's really not fun for anyone involved, and I've been trying to figure out a good algorithm to get rid of FAR's current dependence on config stuff for wings; I don't want to add more config dependency for regular parts as well.

[a.g.]

This results in your CoL being well below your CoM from a single drop tank. A bit of change to the CoL seems reasonable due to their size, but their causing waaaaay to much right now.

Note that shifting of the indicator along the vector it's displaying doesn't mean anything, because forces can be freely shifted along their line without changing their total effect. The exact position is thus inherently ambiguous and is just chosen to be 'somewhere near the center'.

[not-a-cylon]

I've been using b9 airbrakes to slow my supercruise-shaped crafts during landing to prevent stalling. It's quite effective- however, they feel a bit cheat-y to me. What's the consensus of using b9 airbrakes with FAR?