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

[Entropius]

@Entropius: Ack! What happened to the formatting it's just a wall of text?! Anyway, best I can tell is that you're running an out-of-date version of FAR; it looks like this is a bug that was fixed several versions ago.

The text formatting appears fine to me. Maybe your text-editor just doesn't like translating unix/mac/windows style line-endings?

Anyway, if my FAR is out of date, what is the proper FAR-version to use with KSP 0.23.5?

[Renegrade]

So version 0.14.1 is out, fixing some issues, 0.24.1 compatibility, and tweaking the air-breathers down a bit, thanks to Renegrade, so blame him if you don't like it.

Hehe~

Thanks for the update! I'll be over here in my flame-resistant bunker trying it out

[softweir]

@output_log.txt - ok, that thing got 16.9 MB and I really don't want to post the whole thing here

Use dropbox or other similar file-sharing site.

[ferram4]

v0.13.3. Which has bugs that have been fixed; you will need to update to v0.14.1 or else you're outta luck for getting bugfixes.

[TeiwazVIE]

I need the whole thing in order to know what happened before everything started to break and how the breaking occurred. There's a reason I specified the whole thing, and it's not because I like downloading huge files.

Just because the rest of FAR works doesn't mean the wings work, since they run on different code.

http://www.file-upload.net/download-9267839/output_log.rar.html - there you go.

[ferram4]

I don't see any obvious errors. What parts are causing this issue? If it is not all of them, then that means that it is an issue with parts that have not been configured to support FAR; at that point you would be best served by contacting the mod author to get them to support FAR.

Does it happen on a clean-built craft? Does it only happen on saved crafts?

[TeiwazVIE]

I don't see any obvious errors. What parts are causing this issue? If it is not all of them, then that means that it is an issue with parts that have not been configured to support FAR; at that point you would be best served by contacting the mod author to get them to support FAR.

Does it happen on a clean-built craft? Does it only happen on saved crafts?

Just happened with the plane I built with stock parts. Haven't tried any other plane. Will do that though (with saved crafts from FAR, if there are any, don't know from memory) - but tomorrow

[thylordroot]

@thylordroot: Probably a minor asymmetry in the craft design caused by floating point errors that's compounded over time. That should be easily controllable with thrust vectoring.

This is a perfectly reasonable hypothesis, and I can see how it would cause phantom forces on my rocket. I haven't had the time to look at the source code you've graciously provided to the community, but do you posit that there may be a minor numerical stability issue at play here (though perhaps out of your control)? At any rate, I am impressed by the promptness of your reply. Let me know if your project accepts donations and I will send some beer money your way.

@thylordroot You have to make sure you aren't running too much TWR as going too fast will cause a ton of drag on top of your vessel. My rule of thumb for surface TWR is 1.2-1.6 at launch and no more than an ending TWR of 3. Anything faster and you'll cause too much drag loss. Anything less and you're losing too much to atmospheric drag to be decently efficient. Also make sure you start your gravity turn very early (anywhere from just past the tower with shuttle analogues up to 691 meters if I'm using MJ for ascent). Also make sure your center of lift is well below center of mass to give you a solid amount of stability. Also if you know your upper stage will be inherently unstable (due to wide fairings producing a large amount of drag; use your first stage that has control surfaces to loft the rest of the rocket higher; see below for further information on that)

This seems consistent with what I've read on the topic. I've been initiating my gravity turns at 60 m/s, usually with a TWR around 1.2. To that extent I am probably excessively paranoid; I try to never let the TWR exceed 1.6 until 30K (which has caused me to avoid solids), but it is good to know I have a little leeway here. Part of my issue must be over-correction. I am trying to break the habit of flying without SAS (especially since it now causes positive feedback), but I have to admit that my biggest problem is that I have no idea what I'm doing. To have feedback of this kind is great, because for many of us, KSP is that game that makes us yammer incessantly about what we've learned from it.

As an example: My typical two-stage to low kerbin orbit puts a payload in position to circularize on its own anywhere from 75-100 kM. I'll go over TWRs and D/V totals shortly. This should give an idea as to what I look for when I'm building rockets. First stage is around 1800-2500 D/V depending on payload size / mass etc. My typical burn time for the first stage without boosters is anywhere from 2:15 (two minutes 15 seconds) to 2:30. With SRBs mounted the burn time stays the same for the main engine; but the SRBs can vary wildly; I just look to end them with the main stage TWR above 1.2. My OCD dictates that they be a nice number but that is just for orderly purposes and has no bearing on functionality.

My upper stage starts off anywhere from 1.00 to 1.4 TWR; I sometimes run less depending on my flight profile.

At this time, most of my rockets are fairly bulbous at the top (since I only have the 0.675 and 1.25 meter procedural fairings at the moment). It has therefore been my habit to utilize a single stage to get me suborbital; that single stage usually has around 3.2 m/s delta-V. The hope is that I can hold on to my control surfaces as long as possible so that I can use a second stage for orbital insertion. My upper stage is admittedly quite weak in these rockets (about 0.9 TWR), but the hope is that the tradeoff is that I will have substantially more time to perform my insertion burn.

If I run a more vertical ascent I can more easily get away with a sub 1.0 TWR and still get into orbit so long as my apoapsis is high enough to get above 1.0 TWR before reaching it; that's more based on experience and I'm sure there's mathematical formula to allow prediction of that; I just fly by the seat of my pants in that regard.

Upper stage due to DRE and FAR typically starts off between 20-30 kM depending on ascent profile and takes the craft to my final apoapsis.

If I run a three stage engine the first stage can go as low as 1500 D/V; I'm looking to loft the rest of the craft far enough away from the space center that when I decouple the first stage it lands in ocean east of KSP. The second stage pushes it out of the atmosphere and the third stage is used for circulizing and transfer.

I haven't messed around with 3-stage rockets yet, but it is an appealing prospect for the mission I am currently working on (which is a direct ascent landing on the moon). I'll keep these notes in mind as I work through this issue; I think I may have an idea of how to solve it now.

[Master Tao]

I'm seeing multiple NREs from FARControlSys.StabilityAugmentation any time I launch with DCA already enabled. The exceptions don't seem to affect gameplay – DCA still works.

My system: Mac OS 10.9.4, KSP 0.24.1, FAR 14.1. The only other mods are Module Manager 2.2.0 and ModStatistics.

Example NRE:

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)
  at Vessel.FeedInputFeed () [0x00000] in <filename unknown>:0 
  at FlightInputHandler.FixedUpdate () [0x00000] in <filename unknown>:0 

Full player.log: http://pastebin.com/ZWPX7EGe

Also, thanks for nerfing the turbojets. I'm not sure my poor laptop could handle AJE along with everything else. Are you planning on nerfing the basic jets, too? If not, I'll just do it on my install.

[Hodo]

v0.13.3. Which has bugs that have been fixed; you will need to update to v0.14.1 or else you're outta luck for getting bugfixes.

But what about this build you linked about 6 pages ago.

That is due to an error that resulted in improper placement of the aerodynamic center for wings at M > 1. Basically, I screwed up badly there; it was fixed for some dev versions that were still compatible with 0.23.5. You should be able to fix it using the version from this particular commit.

[Renegrade]

Also, thanks for nerfing the turbojets. I'm not sure my poor laptop could handle AJE along with everything else. Are you planning on nerfing the basic jets, too? If not, I'll just do it on my install.

From our discussion, it seemed like the basic jet engines were working as intended. Lots of static thrust, but very little at high speed (negative past mach 1 in fact)... I didn't actually notice any problems in NEAR or FAR until someone mentioned really fast turbojets, as I usually just use basic engines on my science planes.

[Hodo]

So this new build of FAR, I think Ferram you went a bit TO far on the nerfing of some engines. Right now the same SSTO I built in 14.02, with a SABRE-S engine, can barely get off the ground with the same engine running in open cycle.

The issue I am having with this nerf on air breathing engines is, I can still go closed cycle on the same SABRE-S and get to space without even needing intakes. So why nerf air breathing engines THAT much when rockets are left untouched.

It looks like you went close to 30-40% of stock thrust for all air breathers.

[NathanKell]

Read the last few pages, it's been non-stop people complaining they were OP!!!!111one and Renegade having some suggestions.

And then ferram4 says in the changelog: I'm going with Renegade's numbers, blame her/him if you don't like it.

[Hodo]

Read the last few pages, it's been non-stop people complaining they were OP!!!!111one and Renegade having some suggestions.

And then ferram4 says in the changelog: I'm going with Renegade's numbers, blame her/him if you don't like it.

I think its a bit of an over nerf.

Right now I have a single SABRE-S that is powering a 27 ton SSTO Space plane. Pre-14.1= 215kn of thrust Air breathing mode. Now - 61kn of thrust. To be quite frank, that isn't a nerf or a balancing, that is a castration. Might as well just slap rockets on everything or operate the SABRE and RAPIERs in closed cycle because they would be more efficient.

Simple fix, just replaced this file with the previous version.

FerramAerospaceResearch.cfg

All of the nerfing is gone.

Edited July 25, 2014 by Hodo

[Hodo]

So version 0.14.1 is out, fixing some issues, 0.24.1 compatibility, and tweaking the air-breathers down a bit, thanks to Renegrade, so blame him if you don't like it.

Yep, blaming him. And removed the "tweaks" already.

[Master Tao]

From our discussion, it seemed like the basic jet engines were working as intended.

OK – I hadn't read the whole discussion. It just felt very odd that the turbojets had significantly less static thrust than the basic jets.

@Hodo: It's this section in particular that you want to cut to remove the nerf:

@PART
[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeAir]]]:BEFORE[FerramAerospaceResearch]:NEEDS[!AJE]
{
    @MODULE[ModuleEngines*]
    {
        @maxThrust *= [B]0.36[/B]
    }
}

You can also change the nerf percentage by changing the bold number.

Edited July 25, 2014 by Master Tao

[NathanKell]

A flat nerf isn't going to work right, since the B9 engines, because they were made by Taverius (who actually both (a) cares about, and ( knows about, jet performance) thus have reasonable figures.

[Master Tao]

A flat nerf isn't going to work right, since the B9 engines, because they were made by Taverius (who actually both (a) cares about, and ( knows about, jet performance) thus have reasonable figures.

I hadn't noticed that the B9 engines didn't already have configs for FAR. This nerf also stopped making any sort of sense when I realized the RAPIER's thrust more than triples after switching modes. AJE it is...

[ferram4]

The B9 engines have "reasonable" figures for the velocity curves, but the overall thrust is still in the "way too much" range, IMO. They are still set up to function in stock atmospheres.

[Renegrade]

In my defense, I was only doing testing on Stock parts (and 14.0 had engine specific stanzas). Although, I do think Ferram is right that the SABRE is designed for stock air (stock air is actually some sort of highly transparent liquid lead, FYI).

I actually was thinking that there was some bug in the drag code (it turns out it was actually a limitation of the old code that was fixed, not a bug)....

Anyhow I have a bug to report -- I'd seen it before but I assumed it had to do with some other mod.. however, now I only have FAR 0.14.1 and KSP(x86) 0.24.1(build 557) installed, and I'm still getting it. The stats are flickering from extremely low Q (like.. 122) and high Q (76k), with attendant changes in Cl/Cd and some of the other stats.

Not sure if this is related..?

LOG 01:44:56.292] ------------------- initializing flight mode... ------------------
[LOG 01:44:56.295] Loading ship from file: C:/games-ssd/KSP/0241_FAR/KSP_Data/../saves/SANDBOX/Ships/SPH/Auto-Saved Ship.craft
[WRN 01:44:56.313] [Part]: PartModule FARBasicDragModel at Mark2Cockpit, index 7: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.313] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.322] [Part]: PartModule FARBasicDragModel at MK1Fuselage, index 0: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.323] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.326] [Part]: PartModule FARBasicDragModel at MK1Fuselage, index 0: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.327] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.331] [Part]: PartModule FARBasicDragModel at MK1Fuselage, index 0: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.332] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.343] [Part]: PartModule FARBasicDragModel at turboFanEngine, index 5: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.344] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.374] [Part]: PartModule FARBasicDragModel at SmallGearBay, index 5: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.375] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.401] [Part]: PartModule FARBasicDragModel at SmallGearBay, index 5: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.402] ...no FARBasicDragModel module found on part definition. Skipping...
[WRN 01:44:56.408] [Part]: PartModule FARBasicDragModel at SmallGearBay, index 5: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:44:56.409] ...no FARBasicDrag

(I have saved copies of output_log.txt and KSP.log in case they're needed)

[Grunf911]

Hehe~

Thanks for the update! I'll be over here in my flame-resistant bunker trying it out

Well, instead of complaining regarding nerfing rapiers, i did some reengineering, kerbal style. Behold, my new reengineered SSTO.

Special thx to Renegade and ferram

[ferram4]

@Renegrade: The only way that could be happening is if somehow, the active FARControlSys is constantly switching between the current vessel and something else, but it's forced to go to the activeVessel, so unless some mod is playing with FlightGlobals.activeVessel there's not much I can do.

All the messages in the log are the way they're supposed to be. Ideally, they would have gotten to adding the one bool I wanted on PartModules that would allow me to flag them as "don't save this one" to avoid log spam, but that didn't happen.

@Grunf911: Seriously, you don't need that many engines. Take a more moderate ascent path, and you won't have to worry about tailstrikes like that thing will.

[thorfinn]

The thing I'm most interested in at the moment is the FAR API: will you be putting documentation on the Github wiki for it?

[R0cketC0der]

The thing I'm most interested in at the moment is the FAR API: will you be putting documentation on the Github wiki for it?

Look in the FARAPI.cs in the FerramAerospaceResearch folder in the GitHub repo. The code is pretty self-explanatory.

[thorfinn]

Oh, I see. Pretty easy stuff, right...

If I can suggest an addition, having cLmax available together with instantaneous cL would make lift reserve indicators possible (and I think those would help a lot in flying )