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

[DivisionByZero]

Use the aero viz tool to see how much the nosecone helps.

[smjjames]

I would use the aero viz tool myself, but I have absolutely no idea how to interpret it.

What is the aero viz tool? The button down on the hotbar at lower right?

Edit: oh nvm, it's flight/launch mode only, how do I get it to show in VAB/SPH?

Edited January 10, 2015 by smjjames

[bdito]

It should, though I don't think you need THAT big a nosecone, and a fairing might be useful.

It is rather comical but its the only one that was large enough to cover the large dishes. If I used a fairing the parts would be shielded and should have no drag.

Use the aero viz tool to see how much the nosecone helps.

Thanks, I didn't think of that.

Well it looks like it doesn't really do much. Here's a couple pics of it with and without the nosecone. I guess going with a full fairing is the only way.

[ferram4]

@karamazovnew: There are no errors there. I gather that the log is still truncated.

@smjjames: You don't, it's flight only and will remain that way.

@bdito: No, that's supposed to happen. If that was really as effective as you think, there would never be any need for a full heavy fairing. Attaching the nose cone does slightly help with the drag, but you've still got those great big dishes that you're doing nothing about.

[taniwha]

bdito: that is, actually, to be expected. While in reality the cone will shield the dishes a little, the difference isn't worth modeling compared to the difference a fairing makes.

[bdito]

Thanks guys. I know it wouldn't be like having a full fairing but I was just curious if it would make a noticeable difference versus having nothing.

[Camacha]

Ferram, I am making a part that uses nodes in a sort of grid formation to attach to other parts. This means there are a lot of exposed nodes. I remember that FAR looked at those as points of high drag. Is that still true? Can I do anything about that and do I need to take anything else into account? Attachment node size perhaps?

Proper FAR compatibility is important

At the risk of being too insistent I repost my question, as I want to take FAR into account designing parts.

[ferram4]

Oh, I must have missed it. Well, yeah, it's gonna be really draggy. If you try to set the nodes tiny, they'll be ultra-flexible connections without KJR.

[Camacha]

If you try to set the nodes tiny, they'll be ultra-flexible connections without KJR.

My current problem is that they are way too stiff for the part I am making, so maybe that will work out. I am also looking into the option to turn off the nodes, that might help FAR behaviour.

Well, I know what I need to know, thanks

[karamazovnew]

@karamazovnew: There are no errors there. I gather that the log is still truncated.

To be honest, I didn't expect much from the log, as I've been watching it quite carefully. It's an interface problem, probably with Unity itself. I was just hoping that since it only affects parts with the new "mass/strength" bar, you might have some idea. I'm also guessing you couldn't replicate the problem. Thanks for taking the time anyway.

@bdito In the aero viz view, nosecones don't have any effect on the part immediately below them. Notice the drag on the small fuel tank. Also notice that all radially attached parts produce drag in all cases. However, the rocket behaves quite logically, only becoming unstable in the last pic, as you'd expect from the shockwave hitting the gap and the radial parts. On the same rocket I've also placed different antennas, instead of the small structural boxes. As you'd expect, the ones that "stuck out" were immediately broken, while the smaller ones which fitted in the diameter, didn't. In conclusion, always use fairings with FAR. (BTW, I'm using physics for all of my physicsless parts).

Edited January 10, 2015 by karamazovnew

[Camacha]

I am also looking into the option to turn off the nodes, that might help FAR behaviour.

Just for those who might be tempted to do the same: turning nodes on and off by using JSIPartUtilities does not change drag. You can turn off physics for that part completely by using PhysicsSignificance = 1.

[tetryds]

@karamazovnew: The cone/intake not covering what is below them was a bug that was fixed on the git version.

[ferram4]

@karamazovnew: Known issue, fixed in dev build.

@Camacha: FAR applies drag regardless of that flag's setting. Reason? The 3.75m decoupler is physicsless, and FAR needs to apply drag to it for decoupled 3.75m stages to make the proper amount of drag.

[7499275]

Hey guys! Looking for a 0.25 version of this. Went to ferram's mediafire link for older versions but the newest one is april of 2014 which I believe is 0.20? Something like that.

[Crzyrndm]

Old releases are all on github

https://github.com/ferram4/Ferram-Aerospace-Research/releases

[Dr. Death]

Hi ferram, can i suggest that you just dont take feedback at all from 64-bits users instead of having to just disable the mod for that version? i understand that you dont want to fix the 64-bit version of FAR or NEAR, but to me FAR is a must-have and with B9 and FS7 installed my RAM consumption is just WAY too high and i will need to change to 64-bit KSP just with a few parts mod.

[goldenpsp]

Hi ferram, can i suggest that you just dont take feedback at all from 64-bits users instead of having to just disable the mod for that version? i understand that you dont want to fix the 64-bit version of FAR or NEAR, but to me FAR is a must-have and with B9 and FS7 installed my RAM consumption is just WAY too high and i will need to change to 64-bit KSP just with a few parts mod.

The mod isn't what's broken, which is kinda what drove it to the point of disabling for 64 bit.

[taniwha]

Dr. Death: he can't stop people from posting, and they were flooding the thread with messages about FAR not working when it was 64-bit Windows KSP that wasn't (and still isn't) working. 64-bit Windows KSP is broken. Do not use it. If you really need 64-bits, use Linux.

[KerbMav]

with B9 and FS7 installed my RAM consumption is just WAY too high and i will need to change to 64-bit KSP just with a few parts mod.

Is ATM not as helpful as it was or is it just not advertised enough?

(Or are some part packs just ridiculously large??)

[tetryds]

ATM efficiency is insane, you need a really excessive ammount of mods to start needing win64 with it.

Which means even less reasons to support it (and more to not do it).

AFAIK it's a must have for b9, maybe they should be bundled together.

About FAR, would text guides be helpful?

They may be simpler to make using the video tutorial scripts, not so easy to follow but faster to navigate.

So, I will consider it if people think it's a good idea.

Edited January 12, 2015 by tetryds

[Mołot]

Hi ferram, can i suggest that you just dont take feedback at all from 64-bits users instead of having to just disable the mod for that version? i understand that you dont want to fix the 64-bit version of FAR or NEAR, but to me FAR is a must-have and with B9 and FS7 installed my RAM consumption is just WAY too high and i will need to change to 64-bit KSP just with a few parts mod.

If you really really need it, you can compile it yourself, without that check. I did it, and so far it works. The best part? If you're the kind of user who hacks and compiles plugins, you probably have a good grasp of what comes from, and decency to test spotted errors with supported version before reporting anything.

[xrayfishx]

When I try to make shuttle styled air brakes, they often tend to go to the same side when I activate them, resulting in a huge unwanted yaw input. Is there a way to fix that? I tried searching the thread and found only one person asking the same thing and he didn't get any replies. It surprises me that this is such a rare problem, but I guess that means I must be doing something wrong.

Here's the aircraft I'm currently having this problem with, although I've never gotten it working right on any aircraft.

The boosters are there to easily test its flying characteristics.

In the SPH the brakes open correctly regardless of whether or not I have the boosters attached.

However, in flight the right half moves to left as soon as I detach the boosters. I did the whole flight with the brakes on and it happened just as the boosters decoupled. I've seen exactly this kind of behaviour on other planes, too. It's always fine until I detach the boosters.

Edited January 12, 2015 by xrayfishx

[tetryds]

When I try to make shuttle styled air brakes, they often tend to go to the same side when I activate them, resulting in a huge unwanted yaw input. Is there a way to fix that? I tried searching the thread and found only one person asking the same thing and he didn't get any replies. It surprises me that this is such a rare problem, but I guess that means I must be doing something wrong.

Here's the aircraft I'm currently having this problem with, although I've never gotten it working right on any aircraft.

http://i.imgur.com/9RtkeL2.png

The boosters are there to easily test its flying characteristics.

In the SPH the brakes open correctly regardless of whether or not I have the boosters attached.

http://i.imgur.com/yxKGoxVs.png

http://i.imgur.com/2FcouR8s.png

However, in flight the right half moves to left as soon as I detach the boosters. I did the whole flight with the brakes on and it happened just as the boosters decoupled. I've seen exactly this kind of behaviour on other planes, too. It's always fine until I detach the boosters.

There is no way to fix that by now.

Also, if you place two control surfaces like that FAR won't like it much.

[xrayfishx]

There is no way to fix that by now.

Also, if you place two control surfaces like that FAR won't like it much.

Well, that's disappointing. Are there any workarounds? Currently I'm planning to go with StripSymmetry which should make this an easy fix, but if there are any easier ones, please let me know.

Also, I know FAR won't like those control surfaces, but there is no alternative that I can think of.

[tetryds]

Well, that's disappointing. Are there any workarounds? Currently I'm planning to go with StripSymmetry which should make this an easy fix, but if there are any easier ones, please let me know.

Also, I know FAR won't like those control surfaces, but there is no alternative that I can think of.

You could try a V-tail.

Wait, did you try setting one of the flaps on the vertical stabilizer to have a negative deflection angle?

That would solve it... I derped.