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

[Pikachu8091]

Pikachu8091: You're thinking of RemoteTech.

Okay, many thanks!!

[crashman1390]

I'm getting a glitch where when I spawn on the runway my plane breaks apart and physics also breaks as well. The parts are indestructible when I have the mod so I have infinite explosions and lag when the plane or ship breaks apart.

[Malcolm182]

Hi so im haveing a problem with far. If i use B9 parts for e.g. canards, they go to full deflection stay there 4 like a sec and snap back to starting position. the stock parts are fine and it only happens if i use the newest build with the 12.5 its fine. any ideas ?

[NathanKell]

Oh yeah, kept meaning to mention this. I get this too with most control surfaces. It seems to only be a visual bug though.

[dbmorpher]

I'm using the latest version of FAR and MechJeb and am trying to make a base on duna so I am using the landing autopilot. I like using far but the landing was not calculating right so I had to uninstall it. I want to play with FAR but I also don't want to have to drive my base parts for kilometers. Any suggestions?

[ferram4]

@crashman1390: That does not sound like an issue that would be caused by FAR, since FAR doesn't make any parts indestructible nor does it mess with anything that could cause ships to fall apart on load. All of your mods are up-to-date, correct? Can you post a copy of your output_log.txt?

@Malcolm182 & NathanKell: Under what circumstances? Is this when you make a control input, the control surfaces lag the input slightly? Because that is intended behavior, partly realistic, partly to keep SAS from freaking out and making planes wobble like mad (though people somehow still manage that). I need more information, because I use B9 myself and have never encountered any issue like that.

@dbmorpher: FAR or MJ aerobraking and landing predictions on atmospheric bodies: pick one. MJ is (currently) not capable of simulating FAR's aerodynamic properties (though the code is open for it to do so), and even when it will be capable of doing so the predictions are likely to be very inaccurate compared to what you are used to, since the stock drag model is completely unaffected by craft orientation. You will either have to become better at making your own predictions with using FAR or you'll have to abandon it.

[dbmorpher]

@ferram4 I think I'll keep FAR for liftoff and remove it for landing. Best of both worlds!

[crashman1390]

@crashman1390: That does not sound like an issue that would be caused by FAR, since FAR doesn't make any parts indestructible nor does it mess with anything that could cause ships to fall apart on load. All of your mods are up-to-date, correct? Can you post a copy of your output_log.txt?

I was wrong with the mod, I figured out that I had an outdated version of a re-enforcement mod for part joints to prevent 'wobbly rockets' and squad fixed a bug on that so the parameters were reversed. So yeah... Sorry....

[B787_300]

Hey Ferram, does FAR have ground effect coded in or if not how difficult would it be? it would be neat to make a eukranoplane

[ferram4]

@B787_300: Every time I've tried adding ground effect it ends up being either unnoticeable, extremely expensive, or just plain wrong. It's not simple to model and is too dependent on wing design and fuselage configuration for me to even hope to have a good model in place. At this point, it's not happening.

[NavyFish]

@ferram4: I just built a simple aircraft using only stock parts (haven't uninstalled any mods, same exact KSP install as before), and the editor analysis successfully plotted a graph.

I loaded the .craft I sent you and systematically removed parts until the graphs worked. Turns out it's the engines - they are showing NaN electric charge, until I adjust the slider, after which point the graphs work again. The engines keep reverting their charge to NaN, oddly, so I have to do this every time I want to re-plot.

The engines are the TFE731 Turbofan, part of the B9 pack. Stock jet engines do not have this problem (they don't even display electric charge as a tweakable).

I definitely have the .cfg file posted earlier in my GameData folder, so it doesn't seem to be fixing the electric charge bug, which is almost certainly the source of the FAR editor analysis problem.

It looks like this is not a FAR-specific bug, but probably a B9 one. Hope I didn't waste your time looking for a bug in your code.

I'll probably make a post in the B9 thread, but for the sake of completeness (and in case someone else experiences this glitch and comes across this post), are there any further suggestions for fixing the NaN electric charge bug, specifically on B9 parts?

-Navy

[NathanKell]

You do have the B9 fixes for .23 right?

Ooooh, it only fixes engines and not ModuleEnginesFX. I bet you're using HotRockets. Take that MM snippet, duplicate it, and change ModuleEngines to ModuleEnginesFX.

[NavyFish]

You're a genius..! I'll test shortly (currently in-game and my loading process takes ~5 minutes, so I'm going to hold-off for now). Will report back!

-Navy

Edited April 21, 2014 by NavyFish

[Boomerang]

So I finally got around to trying out FAR and while the jury's still out on whether I'll keep it, I wanted to express my appreciation for the well-maintained directory of older releases of the mod.

I often need older versions of many mods for saves that I run on older versions of the game, or, like today, because of a mod conflict I was trying to resolve. And usually it's a real pain to track down previous releases of mods - one of my few gripes about the otherwise wonderful modding community around here. So finding that link in the first post really made my evening, thanks.

[NavyFish]

You do have the B9 fixes for .23 right?

Ooooh, it only fixes engines and not ModuleEnginesFX. I bet you're using HotRockets. Take that MM snippet, duplicate it, and change ModuleEngines to ModuleEnginesFX.

I do have the B9 fixes for .23.5.

Added the following to a cfg in my GameData folder:

@PART[*]:HAS[@MODULE[ModuleEnginesFX],@RESOURCE[ElectricCharge]]
{
	@RESOURCE[ElectricCharge]
	{
		%isTweakable = false
		%hideFlow = true
	}
}

Unforutunately, it didn't work. The engine in question still displays electric charge as a tweakable.

The Modules section of the part's .cfg is as follows:

MODULE
    {
        name = ModuleEngines
        thrustVectorTransformName = thrust_transform
        exhaustDamage = False
        ignitionThreshold = 0.1
        minThrust = 0
        maxThrust = 225
        heatProduction = 600
        useEngineResponseTime = True
        engineAccelerationSpeed = 0.12
        engineDecelerationSpeed = 0.21
        useVelocityCurve = True
        fxOffset = 0, 0, 1.13
        PROPELLANT
        {
            name = LiquidFuel
            ratio = 1
            DrawGauge = True
        }
        PROPELLANT
        {
            name = IntakeAir
            ratio = 21
        }
        atmosphereCurve
        {
            // Based on Isp/TSFC data from NASA EngineSim, and Kerbin atmo.
            key = 0       1625  0   2.25E+07
            key = 7.5E-06 1772  0   0
            key = 0.0006  1492  0   0
            key = 0.11    1668  0   0
            key = 1       1440 -375 0
        }
        velocityCurve
        {
            // Based on Fnet data from NASA EngineSim, curve fitted with MuMech CurveEd
            key = 0    0.56 0      -0.0003
            key = 230  0.52 0      0
            key = 687  0.7  0.0011 0.0011
            key = 1030 1    0      0
            key = 1260 0.5  -0.004 -0.004
            key = 1430 0    0      0
        }
    }

    MODULE
    {
        name = ModuleAnimateHeat
        ThermalAnim = jet_turbofan_heat
    }

    MODULE
    {
        name = ModuleAlternator
        RESOURCE
        {
            name = ElectricCharge
            rate = 5.0
        }
    }

    RESOURCE
    {
        name = ElectricCharge
        amount = 0
        maxAmount = 0
    }
}

The hot rocket's MM cfg for the relevant engine has the following:

    @MODULE[ModuleEngines]
    {
        @name = ModuleEnginesFX
        //engineID = rocketengine
        runningEffectName = powersmoke
        directThrottleEffectName = powerflame
	!fxOffset

    }
    @MODULE[ModuleEngineConfigs]
    {
    %type = ModuleEnginesFX
    }

I'm new to the whole part module thing, but perhaps instead of ModuleEnginesFX, I should use ModuleEngineConfigs in my 'fixer' cfg?

[NathanKell]

NavyFish: weird.

2 things to try.

First, make sure you have 1 and only 1 module manager dll anywhere, and it's at least version 1.5.6. Then replace your fixer with this:

//Starwaster/NathanKell
@PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]:Final
{
	@RESOURCE[ElectricCharge]
	{
		%isTweakable = false
		%hideFlow = true
	}
}
@PART[*]:HAS[@MODULE[ModuleEnginesFX],@RESOURCE[ElectricCharge]]:Final
{
	@RESOURCE[ElectricCharge]
	{
		%isTweakable = false
		%hideFlow = true
	}
}

If that *still* doesn't work, just edit the actual part cfgs of the parts giving you trouble, and make sure their electric charge blocks look like

RESOURCE
{
	name = ElectricCharge
	amount = 0
	maxAmount = 0
	isTweakable = false
	hideFlow = true
}

[JTG]

Makes planes harder to fly?

Challenge accepted.

[NavyFish]

NavyFish: weird. *snip*

I just created a new aircraft, without making your final proposed changes, and the problem is gone! The engines do not display EC as a tweakable. Huh. I hadn't realized that parts which had already been created wouldn't be affected by the MM cfg.

Does this make sense, or are things getting weird?

Anyhow, problem fixed! Great success! Thank you for your help, both of you!

-Navy

[Malcolm182]

@Malcolm182 & NathanKell: Under what circumstances? Is this when you make a control input, the control surfaces lag the input slightly? Because that is intended behavior, partly realistic, partly to keep SAS from freaking out and making planes wobble like mad (though people somehow still manage that). I need more information, because I use B9 myself and have never encountered any issue like that.

Basicly everytime. on the launch pad, wihle flying. I just press roll 4 e.g. and hold it, and as i said it goes to full deflection stays there a bit and snaps back to default state. (just let me know what else u need)

Oh yeah, kept meaning to mention this. I get this too with most control surfaces. It seems to only be a visual bug though.

i dont thinks its only visual, + the lift value is also changes when it happens.

[whaaw]

why is my rocket tipping over ? all my rockets tipping over on lunch even when it is one capsule small tank and a little engine

[taniwha]

whaaw: sandwiches do not make for very sturdy supports of heavy objects

[BudgetHedgehog]

why is my rocket tipping over ?

No idea.

Course, it'd help if I knew what your rocket looked like.

(this is subtle way of asking for a picture so I can help)

[ferram4]

@NavyFish: More gets saved in the craft file than really should. So the MM file updated the properties of all the parts that will be added in the future, but not any of the ones added in the past. Any crafts where you've had this problem, swap the engines out and it'll go away since you'll clear all the problem data out of the craft files.

@Malcolm182: So you make a full deflection, you hold the deflection (and the control indicator in the bottom left corner of the screen continues to show a full deflection), but without messing with anything else on the screen (no other windows, mods or anything else that would prevent inputs from going to flight control), the control surface deflection zeroes out? I've attempted to reproduce this, but have done so unsuccessfully; all of my tests had full deflection maintained for as long as I chose, until I did something that caused focus to shift from flight controls and into another window.

whaaw: Because gravity tends to pull things towards the ground, so if the rocket ends up offset a little bit on the pad, it will fall over.

Of course, that's not the question you're asking, is it? You're asking, "why does my rocket lose control and flip around in the middle of flight?" or more simply, "why is my rocket aerodynamically unstable?" The answers, in no particular order, are:

1. You're overspeeding and aerodynamic forces are overpowering thrust vectoring control. Reduce TWR to ~1.2 - 1.6 compensate.\
   
2. You're sending the rocket sideways at a very high AoA. This will make the rocket unstable; gentle gravity turn, keep the rocket pointed prograde, starting shortly after getting off the launch pad, not go up 10km and yank sideways.
   
3. You've attached something really draggy to the top of the rocket and have a relatively streamlined rear end of the rocket. Shift more mass towards the top of the rocket and more drag / lift towards the back.
   
4. You're staging in the lower atmosphere, and while your rocket's configuration with the first stage was stable, without the first stage it is unstable.
   
5. You have a really, really tall first stage (relative to the rest of the rocket) that causes the CoM to shift backwards after the first bit of fuel is burned, making the rocket less stable.
   

[NavyFish]

I wonder if he has a text file on his desktop, ready to copy and paste that block of text every fourth or fifth page..

[NathanKell]

I hope so. That's a lot of typing.

ferram4: I'm seeing it on pwings too. I'll throw up some shots and check the log later today.