[0.90]NEAR: A Simpler Aerodynamics Model v1.3.1 12/16/14

[PDCWolf]

Hi there!, been using NEAR since... well, can't really remember, but I love it. Quick question: I downloaded 1.2.1 and tried a few designs and it doesn't matter what kind of design it is, I just don't seem to get enough pitch authority. I made an SR-71 look-a-like, a "normal" mk1 based compound delta, an A-4, etc, to no avail, nothing has enough pitch authority unless I place my control surfaces as close to the CoM as possible (or at least that's what I could figure with my tests). I also made a Skylon thingy and if I disable pitch on the main wing, then I have no pitch authority at all.

TL;DR (and probably clearer): I have to put my control surfaces close to the CoM or I don't get pitch authority (whether I use deltas, cannards, both, or conventional designs, pitch authority always comes from the control surfaces closer to the CoM)

[ferram4]

What? That basically means that KSP's physics simulation is broken. Alright, let's find out what's up. Follow the steps here: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

[PDCWolf]

What? That basically means that KSP's physics simulation is broken. Alright, let's find out what's up. Follow the steps here: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

Well, I left NEAR alone (and left real chute to load some of my already made designs which include the chutes), the problem still persists.

Here's the output log: http://pastebin.com/8BWua9sv

I also ran a quick test to make my problem really clear. I'll leave the images as links as to avoid uselessly clogging the thread with huge images.

First, I made a "conventional" plane, main wing is forward, right at the COM. I disable pitch on the ailerons and leave it only to the stabilizer. Take off speed is about 200 m/s and I can't pitch any further than the image, the most violent turn I can get is about 2g. Image is about one second after take-off: http://i.imgur.com/iq0whLI.png

For the second part, I enabled pitch on the outmost control surfaces on the main wing and the stabilizer, take off speed is greatly reduced and pitch authority is better (still lacking, but allows for actual flying). Again, picture taken about one second after take-off, the difference is greatly noticeable: http://i.imgur.com/nBShV7U.png

Anyways, I realized I'm using MM 2.5.1 and NEAR comes bundled with 2.5.0, maybe that's the problem?

As per reproduction steps:

1-Make a spaceplane using either a pure delta, compound delta, or any other delta based design without canards (sr-71, Avro Vulcan, HAL Tejas, the space shuttle, etc)

OR

1-Make a spaceplane using any conventional (Main wing forward and stabilizers back) design and disable the pitch on the main wing's control surfaces

2-Hit Launch

3-Continue with normal take-off procedures

4-Craft should be lacking in pitch authority

5-Finish flight on any desired way

6-Go back to spaceplane hangar

7-Enable pitch on main wing control surfaces (for conventional designs)/move the delta wing way forward to get control surfaces closer to the CoM (On delta designs)

8-Hit Launch

9-Continue with normal take-off procedures

10- Craft should have better pitch authority now

[Corovaneer]

Trying NEAR for the first time here. Getting unexpectedly grave results with very basic rocket - 1SRB+1Liquid engine+Payload. Disintegration of vehicle at about 300m/s speed while passing through lower atmosphere. Every destruction happens with a good deal of "bug force" - one was strong enough to fling debris out of solar system in few seconds. Gonna try FAR now, see if there's difference.

[ferram4]

@PDCWolf: Reproduced and confirmed behavior when both control surfaces on the tail and main wing are active. Could not confirm that plane pitched better only with control surfaces closer to the CoM as you originally indicated. Confirmed that control effectiveness is related to distance from CoM as intended. This is not a bug, your planes are just too stable for the control authority they have. In particular, your CoP needs to be closer to the CoM. Shift the wing forward a bit.

@Corovaneer: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 <- follow the steps here. I will need full reproduction steps, since I don't experience that behavior.

[PDCWolf]

@PDCWolf: Reproduced and confirmed behavior when both control surfaces on the tail and main wing are active. Could not confirm that plane pitched better only with control surfaces closer to the CoM as you originally indicated. Confirmed that control effectiveness is related to distance from CoM as intended. This is not a bug, your planes are just too stable for the control authority they have. In particular, your CoP needs to be closer to the CoM. Shift the wing forward a bit.

Wait a moment there, nothing should work better when closer to the CoM, roll aside and at least longitudinally, yaw and pitch work better the further away they are from the CoM (you know, go to a seesaw and try moving it closer to the center or further away blablabla) or at least that's what I have been taught. Unless I misinterpreted what you said.

[ferram4]

That's what I mean. Your initial post said:

TL;DR (and probably clearer): I have to put my control surfaces close to the CoM or I don't get pitch authority (whether I use deltas, cannards, both, or conventional designs, pitch authority always comes from the control surfaces closer to the CoM)

This is not the case. For your test case, the extra (small) control authority from the control surfaces at the ends of your swept wings was enough to make the plane controllable. Disabling the control surfaces on the tail and trying to fly using only the control surfaces on the wings for pitch control showed worse control authority than using only the control surfaces on the tail. Your test case did not prove what you were saying was happening, and my attempts to replicate that resulted in expected behavior.

Your planes are just lacking in control authority. That's it. Make them less stable so the control authority you have is sufficient, or add more control authority.

[iFlyAllTheTime]

The TweakableEverything fix worked flawlessly! Thank you.

Although, I love seeing boosters being ejected outward with a bang. Reminds me of the Shuttle SRBs:cool:

Also, I'm guessing the stock game remains unaffected by this rotational force because of the aero model?

it is, but the FAR/NEAR drag model correctly models the behavior of the part when it's orientation changes, so the "nose" of the ejected booster suffers pretty sever torque due to wind resistance, where as the stock model causes the ejected part to just rotate at something like 1 deg per second, slow enough for it to drift away before scything your engines. you can see this by taking a similar booster up above the atmosphere and ejecting it. it won't whip around like snake, it'll just drift away, turning gently.

Oh, so this behavior exists for FAR users as well then?

I wonder if there a way to edit a cfg file somewhere to edit this behavior.

Thanks for the reply.

[AetherGoddess]

Oh, so this behavior exists for FAR users as well then?

I wonder if there a way to edit a cfg file somewhere to edit this behavior.

Thanks for the reply.

The behavior does appear in FAR, but again, it also appears in stock. stock doesn't model aerodynamics in any real way, so the rotational force that is applied has the same effect as it would in vacuume, a slow rotation that poses no real risk to the spacecraft.

FAR does model aerodynamics, so a small change in the pitch angle has a huge effect on the stability of the ejected booster.

In short, FAR is correctly modeling the physics, and the stock decoupler rotational force bug puts the SRB into a configuration where it will rotate into the spacecraft, instead of away from it. This is why tweaking the force to zero corrects the issue, because if there is no force on the decoupler, then there is no rotation, and the part drops away as expected.

Edited October 12, 2014 by AetherGoddess

[iFlyAllTheTime]

The behavior does appear in FAR, but again, it also appears in stock. stock doesn't model aerodynamics in any real way, so the rotational force that is applied has the same effect as it would in vacuume, a slow rotation that poses no real risk to the spacecraft. FAR does model aerodynamics, so a small change in the pitch angle has a huge effect on the stability of the ejected booster. In short, FAR is correctly modeling the physics, and the stock decoupler rotational force bug puts the SRB into a configuration where it will rotate into the spacecraft, instead of away from it. This is why tweaking the force to zero corrects the issue, because if there is no force on the decoupler, then there is no rotation, and the part drops away as expected.

I understand.Does anyone know if 0.25 still has the rotation bug?

[ferram4]

It's still there. Unfortunately.

[Captain Sierra]

How do I force enable this on Win_x64? I know you don't support it. My game crashes about once a day due to 64 bit instability anyway. I don't care. Due to memory issues, I refuse to go back 32 bit, and I really do hate the base aero model. What do I need to decompile, edit, etc.

And yes, I promise not to harass you about sh*t breaking. I know I'm straining the game's stability and I accept whatever hardware wrecking bugs I bring upon myself.

Edited October 12, 2014 by Captain Sierra

[ngianoplus]

Do you think Scott Manley will do a video about NEAR?

[AetherGoddess]

How do I force enable this on Win_x64? I know you don't support it. My game crashes about once a day due to 64 bit instability anyway. I don't care. Due to memory issues, I refuse to go back 32 bit, and I really do hate the base aero model. What do I need to decompile, edit, etc.

And yes, I promise not to harass you about sh*t breaking. I know I'm straining the game's stability and I accept whatever hardware wrecking bugs I bring upon myself.

you have already exceeded the quota of support for Win x64 with this post. yes, you can get the source and turn off the disabling code, and then recompile it and use it. that task works as a sorting filter. if you can make that minor code change and compile it for yourself, then you are certainly knowledgeable enough to tell the difference between a crash caused by FAR and a crash caused by KSP_x64. if you can't, then it doesn't mean you are dumb, and it doesn't mean that you are somehow unworthy, it just means that we can't be sure that you have the necessary skills to run and troubleshoot an unstable version. you can think of it as a driving test: if you can download the zip and install it, then you can drive an automatic passenger car. if you want to drive a F-18, then you need to pass a higher bar.

Do you think Scott Manley will do a video about NEAR?

He did one on FAR. the entire script of the video on NEAR could be "like FAR<annotation link> but simpler <outro>".

[octo]

Leaving orbit/atmosphere with rockets seems waaay too easy. Is there some mod i should have to counter balance this?

[FlexGunship]

How do I force enable this on Win_x64? I know you don't support it. My game crashes about once a day due to 64 bit instability anyway. I don't care. Due to memory issues, I refuse to go back 32 bit, and I really do hate the base aero model. What do I need to decompile, edit, etc.

And yes, I promise not to harass you about sh*t breaking. I know I'm straining the game's stability and I accept whatever hardware wrecking bugs I bring upon myself.

This is Ferram's code (from the source provided in GitHub):

        public static bool IsWin64()
        {
            return (IntPtr.Size == 8) && (Environment.OSVersion.Platform == PlatformID.Win32NT);
        }

        public static bool IsAllCompatible()
        {
            return IsCompatible() && IsUnityCompatible() && !IsWin64();
        }

He's doing two things here:

Firstly, generating a boolean return based on system pointer size (64-bit OSes use 64-bit pointers) and checking that the Windows version is post Win32NT (all systems after Win98 seem to carry this platform ID). If both of these are satisfied, the return is TRUE (and you're in a Windows x64 environment); this is presumably to prevent a false positive on 64-bit Linux systems.

Secondly, he is performing a logical AND of all of his compatibility checks. One of which is "!IsWin64()" or "is this system not Windows x64".

You could simply remove that check and IsAllCompatible() would return TRUE even if IsWin64() returned TRUE. Remember that, if you do, you are not allowed to redistribute the mod per his license. If you need to ask "how do I do that" then you probably shouldn't be doing it and you should respect Ferram's wishes.

I could do it in a heartbeat... but I choose to adhere to Ferram's rule; it's his mod. I hope he changes his mind. I'm using Win64 and KSP x64 and I sorely miss KJR and NEAR. A few bad eggs have ruined it for us all.

Edited October 13, 2014 by FlexGunship

[octo]

Played around with NEAR for a little, I like it. But getting into orbit with rockets just seems waaay to easy, like i'm cheating really. Is there some mod I'm supposed to have to counter balance this? I've read browsed through the thread and noticed some people mention real solar system..

(also accidental double post)

Edited October 13, 2014 by octo

[PDCWolf]

This is not the case. For your test case, the extra (small) control authority from the control surfaces at the ends of your swept wings was enough to make the plane controllable. Disabling the control surfaces on the tail and trying to fly using only the control surfaces on the wings for pitch control showed worse control authority than using only the control surfaces on the tail. Your test case did not prove what you were saying was happening, and my attempts to replicate that resulted in expected behavior.

Your planes are just lacking in control authority. That's it. Make them less stable so the control authority you have is sufficient, or add more control authority.

Well, guess I'll have to play more with moving the CoM and CoP around until things work. Thanks for your time.

[goldenpsp]

So apparently I am just a bad pilot. Or at least I am guessing. I figured I would come cry here to see if some NEAR experts could point me in the right direction.

Now I will say when using NEAR and planes (space or otherwise) I do quite well actually. Spaceplanes are the reason I decided to try NEAR.

But I have a horrible time with good old rockets.

As an example, I just restarted for .25 so I am early in my tech tree on career mode. I was building a simple Mun flyby rocket. from the top down it was basically:Parachute-small TAC LS can-Mk1 capsule- 2 antenna opposing for balance- stack decoupler- science Jr- 2 goo containers opposing for balance- fuel- LV909 engine- decoupler- fuel LT45 engine- and 4 boosters radially(set down to about 45% thrust to limit acceleration)- In between the boosters I had 4 fixed fins (haven't unlocked the ones that can move yet).

When flying this rocket in stock, it tracks up like an arrow. Controllable into my gravity turn. Everything is good.

When flying with NEAR it starts out ok. I usually try to gradually start my gravity turn earlier but that was not working out well. So I decided to just see about getting some altitude first. If I try and go hands off for the beginning (turn on sas and hit go) the rocket tracks well for the first couple thousand m, but then starts spinning. The spin if left unchecked will eventually knock the rocket out of control. However even trying to control it knocks me off vertical and then it is a constant fight to stay on track, in most cases failing horrible in a ball of fire.

So I love NEAR for planes but am an utter failure with rockets.

[ferram4]

Well, in that case you need to find what causes the spin. Either the fins are not straight, the boosters are not straight, or under thrust they flex enough to not be straight. It's probably the fins if it only started after adding NEAR, because they're suddenly a lot better at lifting than they used to be.

Odds are you don't need as much thrust as you have. If you've got a TWR > 2 when you start you're in for a bad time with NEAR or FAR. The key isn't to chase terminal velocity, the key is to go as fast as you can without losing control; going slower in the atmosphere reduces the chances of losing control.

[falken]

Okay, my shuttle is driving me mad. I've gotten it to glide perfectly, and it behaves well in upper atmosphere on it's own, but it exhibits... strange behaviour around 40km up a little while after SRB sep. It starts to yaw in each direction slowly.

Running latest NEAR, Mechjeb 2.4 (also the Sarbian plugins for KM Gimbal and NEAR), latest Klockheed Martian SSME engines, latest B9.

Tried various levels of torque from the cockpit's reaction wheels, different gimbal and trim from the engines, different vertical stabiliser settings. Without fail she just starts to sway around.

Pretty darn positive the issue lies with the KM engines, but I don't think there's any alternatives. Has anyone got any clues on what I'm doing wrong here?

e: I might try putting some small, subtle aero surfaces on the external tank to see if that helps. But surely there shouldn't be enough atmosphere 40/50km up to cause this?

Edited October 13, 2014 by falken

[goldenpsp]

Well, in that case you need to find what causes the spin. Either the fins are not straight, the boosters are not straight, or under thrust they flex enough to not be straight. It's probably the fins if it only started after adding NEAR, because they're suddenly a lot better at lifting than they used to be.

Odds are you don't need as much thrust as you have. If you've got a TWR > 2 when you start you're in for a bad time with NEAR or FAR. The key isn't to chase terminal velocity, the key is to go as fast as you can without losing control; going slower in the atmosphere reduces the chances of losing control.

More likely the boosters. I also had not yet unlocked struts so I could see the boosters strain with the radial decouplers.

I had toned down the thrust on the boosters to try and get about 1.2TWR. I do generally do better once I unlock more parts to enhance stability.

[falken]

Well, my issue lied with the KM engines. I just put on a set of LV-T45s that I modified to have 400 thrust each, and ran them with Sarbian's auto trim plugin. Shuttle went to orbit with no oscilations at all.

Anyone know of a good SSME engine that uses traditional gimbal?

[Matrix Aran]

Played around with NEAR for a little, I like it. But getting into orbit with rockets just seems waaay to easy, like i'm cheating really. Is there some mod I'm supposed to have to counter balance this? I've read browsed through the thread and noticed some people mention real solar system..

(also accidental double post)

If you check any of Ferram's posts you'll see he also makes a little mod call the Kerbal ISP Difficulty Scaler. Among its other handy uses, it can be used to rebalance the engines in the game to be comparable to stock performance, with NEAR installed. This is perhaps the easiest way to get a stock level of difficulty with NEAR installed.

Of course, should this not be enough of a challenge you might want to try the Real Solar System mod. I personally recommend the 6.4 scale version of it as it works well with stock parts and doesn't need any other mods to give you a reasonable challenge closer to real life deltaV values.

[ferram4]

Alright, version 1.3 is out, with quite a few cargo bay and payload fairing tweaks. Should work a little bit smoother than it has been.