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

[ferram4]

No, the one in the GameData folder in the repo itself. That's the dev build.

[BudgetHedgehog]

No, the one in the GameData folder in the repo itself. That's the dev build.

I think this is where I'm getting confused:

CHANGELOG

0.14.1.1v------------------------------------ Features: More Get functions for the FARAPI

Bugfixes: Fixed some vessel-switching FAR GUI issues

0.14.1.1v------------------------------------ Features: Ensured 0.24.2 compatibility

Tweaks: Un-nerfed air-breathers in overall thrust and thrust curves

Bugfixes: Fixed some issues where FARControlSys GUIs could be wonky

Just so I'm clear, the dev build is the one updated 7 days ago here? I'm not terribly good with Github so my apologies for being a bit slow :/ EDIT: I see the 0.14.1.2 README but unless the actual dll is different to the one I linked above, I can't find it. If by some miracle I have found it, I've just installed it so we'll see hoe we go.

Edited August 5, 2014 by ObsessedWithKSP

[ferram4]

Never trust dev builds to make sense. They're not proper releases (or even pre-releases) for a reason.

[Elmetian]

Would it be too much to ask that B9 SABREs are un-nerfed? My 0.23.5 SSTO is a reasonable 50 tons without cargo and I've spent a long time designing the compound delta Pwing and adjusting the CoM and CoL. Before the nerf it could get 23 tons of cargo to orbit. Now it barely pulls up without cargo, can only just pass mach 1 and tops out at about 15km.

Reaction Engines reckon a real SABRE might produce about 2000kN at sea level and has a mass somewhere around 20 tons. The SABRE M is 6 tons in-game, so it'd need to produce around 600kN (SL) to retain a similar TWR rather than the 330kN it does now. A Skipper currently has half the mass and twice the thrust, so to me it feels like FAR is killing SSTOs in favour of conventional rockets.

If an un-nerfing is out of the question is there a way for me to revert back to previous settings? I love FAR and I feel like I'm cheating now by wanting this, but I don't see any other alternative. I can't see the point in challenging players to make aircraft with somewhat realistic aerodynamics and then making it almost impossible to have them deliver meaningful cargo to orbit. If I wanted my game that realistic I'd have deleted the SABRE engines entirely...

Edited August 5, 2014 by Narcosis

[R0cketC0der]

Would it be too much to ask that B9 SABREs are un-nerfed? My 0.23.5 SSTO is a reasonable 50 tons without cargo and I've spent a long time designing the compound delta Pwing and adjusting the CoM and CoL. Before the nerf it could get 23 tons of cargo to orbit. Now it barely pulls up without cargo, can only just pass mach 1 and tops out at about 15km.

Reaction Engines reckon a real SABRE might produce about 2000kN at sea level and has a mass somewhere around 20 tons. The SABRE M is 6 tons in-game, so it'd need to produce around 600kN (SL) to retain a similar TWR rather than the 330kN it does now. A Skipper currently has half the mass and twice the thrust, so to me it feels like FAR is killing SSTOs in favour of conventional rockets.

If an un-nerfing is out of the question is there a way for me to revert back to previous settings? I love FAR and I feel like I'm cheating now by wanting this, but I don't see any other alternative. I can't see the point in challenging players to make aircraft with somewhat realistic aerodynamics and then making it almost impossible to have them deliver meaningful cargo to orbit. If I wanted my game that realistic I'd have deleted the SABRE engines entirely...

Go to the "FerramAerospaceResearch" folder inside your GameData folder. Inside that folder is a file called "FerramAerospaceResearch.cfg". Inside this file remove this part at line 238:

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

This will unnerf all engines except for the stock ones. If you want the stock ones unnerfed remove this part too:

@PART[turboFanEngine]:FOR[FerramAerospaceResearch]
{
	@MODULE[ModuleEngines*]
	{
		@maxThrust = 110
		@velocityCurve
		{
			@key,0 = 0 0.8 0 -0.00098

			@key,1 = 140 0.7 0 0

			@key,2 = 400 0.8 0.00049 0.00049
			@key,3 = 900 1 0 0

			key = 1800 0 -0.00098 0
		}
	}
}
@PART[RAPIER]:FOR[FerramAerospaceResearch]
{
	@MODULE[ModuleEngines*],0
	{
		@maxThrust = 100
		@velocityCurve
		{
			@key,0 = 0 0.8 0 -0.00098

			@key,1 = 170 0.7 0 0

			@key,2 = 400 0.8 0.00049 0.00049
			@key,3 = 1100 1 0 0

			key = 1700 0 -0.00098 0
		}
	}
}
@PART[JetEngine]:FOR[FerramAerospaceResearch]
{
	@MODULE[ModuleEngines*]
	{
		@maxThrust = 150
		@velocityCurve
		{
			@key,0 = 0 1 0 -0.005
			@key,1 = 250 0.2 -0.001 -0.001
			@key,2 = 350 -0.005 0 0
		}
	}
}

[Juncoph]

Recently I installed B9 Aerospace ('cause I want them cargo bays) - yes, I know this is the FAR thread, but since B9 is closed (and Bac9 is "missing") this thread is the second best to go when it comes to airplane building - and I noticed some strange up & down flexing on the fuselage parts (think of that pencil wobbling while holding it with two fingers we all did when we're kids ). This can be solved by adding struts (making planes look ugly IMO) but I was curious if there might be another way to fix that, f.e. editing some values in part cfg files.

PS: I also found out that some of my issues with FAR were caused by a faulty ModuleManager install (thx, B9 landing gear going bonkers...) - had 2.2.0 in the right location, but somehow an older version got into the \plugins directory as well causing MM not to work.

How heavy was the aircraft? If it's a proper heavyweight you could install Ferram4's Kerbal Joint Reinforcement mod.

http://forum.kerbalspaceprogram.com/threads/55657-0-24-2-Kerbal-Joint-Reinforcement-v2-4-3-7-25-14

[BARCLONE]

Accompanied by GUI flicker as well, yes? I recently had this - taking a part on a flight for a contract, decoupled it and was met with this error and GUI flickering. Test part was scaled down with TweakScale if that matters and once landed, I quicksaved and reloaded and the game crashed.

Here is the output_log.txt. Hope it helps!

GUI flicker? YES! Makes me think the whole game is glitching out, about to crash.

TweakScale? No, I'm not using that mod myself. I do use TweakableEverything, so I can occasionally adjust the thrust vectoring of a booster engine.

[Master Tao]

BARCLONE,

Please see this post and the one immediately after it about the fix.

[TeiwazVIE]

How heavy was the aircraft? If it's a proper heavyweight you could install Ferram4's Kerbal Joint Reinforcement mod.

http://forum.kerbalspaceprogram.com/threads/55657-0-24-2-Kerbal-Joint-Reinforcement-v2-4-3-7-25-14

As I said in a later reply I already have them installed. And it wasn't that heavy, just a pretty basic Mk2 design with rotation wheels + 2 RCS fuel tanks (those are the parts where the flexing happens) behind the cockpit that looks a bit like a F-15/F-18 mix IMO.

[BARCLONE]

BARCLONE,

Please see this post and the one immediately after it about the fix.

OK, downloaded the dll from the Github location...

Situation: My lander was approaching periapsis around Mun, everything looked good until it reached the burn point, then it exploded suddenly and without warning like your typical Disaster Area love song. The aftermath screen seemed to indicate all the parts crashed into each other, like they ran into an invisible concrete wall.

Here are my logs from that session:

KSP.log

Player.log

[Master Tao]

BARCLONE,

Thanks for posting your player.log. It shows an enormous number of errors (> 500), most of them from EVE (Clouds) and Romfarer's plugin, and none from FAR. In any case, the explosions happened in space, where FAR does very little.

You'll need to narrow the problem down. Make backups of your saves, and then remove mods one by one until you can reproduce the problem with only one or two mods.

Also, it doesn't look like you have Module Manager installed. It's required for FAR.

[BahamutoD]

Known issue, get the dev build on github.

Thanks ferram4!

[BARCLONE]

Master Tao,

I dropped ATM, Romfarer, and EVE from the mods. MM should have been in there all along, version 2.2.1.

I'm still seeing a FAR error close to the start of the logs. In the KSP log, it's line 26. In the Player log (debug log) it's at line 104.

KSP.log

Player.log

ATM and EVE may have been giving me the bulk of those errors. I think it has cleared up a bit removing them.

[Master Tao]

Looks like a bad copy of FerramAerospaceResearch.dll. Try downloading it again and reinstalling.

[nli2work]

Hi ferram4,

how does FAR treat drag on engines? calculated based on collision mesh? my assumption was collision mesh, but without the drag value being visible on a part it's hard to tell if changes had any effect. Is it safe to assume if a part is compatible with FAR, it will be compatible with NEAR?

trying to get the radial mounted air engines in Karbonite to be more FAR/NEAR compatible.

Thanks!

[Renegrade]

Reaction Engines reckon a real SABRE might produce about 2000kN at sea level and has a mass somewhere around 20 tons. The SABRE M is 6 tons in-game, so it'd need to produce around 600kN (SL) to retain a similar TWR rather than the 330kN it does now. A Skipper currently has half the mass and twice the thrust, so to me it feels like FAR is killing SSTOs in favour of conventional rockets.

Just wanted to point out here - a real SABRE has (assuming it lives up to design specifications) a TWR of somewhere between 5:1 and 15:1. A thrust-oriented liquid rocket engine, on the other hand, typically has a TWR of 80 to 150.

The equivalent Skipper would have a thrust of ... 2,300 to 4,400kN. Or weigh as little as 0.44t.

That being said, I can understand the viewpoint of wanting to get things done, so if you follow R0cketC0der's instructions, especially the first code block, it will restore the full thrust of the engine.

Note that due to changes in FAR, drag has decreased some*, so you may want to instead change the underlined part to 0.8 or 0.9 or thereabouts instead of completely removing it:

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

* - this resulted in single-engine stock planes being able to go Mach 4 at sea level due to the overpowered nature of stock engines balanced for the thick, soupy stock air. The newer, lower drag is apparently more correct/realistic.

[Jovus]

I seem to be having the common problem with rockets. To be clear, I can get them to space reliably, and I know about the basic design principles. My problem is that whenever I try to do a proper gravity turn, one of two things happens:

1) If I try to do it according to the principle of 'start low, go slow', keeping my TWR near 1.2, I turn the rocket at, say, 100m/s 10deg east, which is usually around 2-3k. This invariably causes me to turn too quickly.

2) The way I'm launching now is to start turning the rocket at about 150 m/s with a TWR of around 1.4, but this means that I do things like hit a 30deg angle to the surface by 20k, which is much too steep - like I said, I can get to space, but I have to severely overbuild my rockets to do so.

Does anyone either have advice or links to help? Videos are especially appreciated, since they would allow me to look at the whole situation and see if there are other factors that the poster is unconsciously assuming. (I already know about this one:

)

I suspect in case 1) above I'm tipping the rocket over a little harder than I should, but I swear I'm aiming for the 5-10 deg mark on the navball. Do you do something like use fine controls to hit it exactly and hold the nose there until the prograde vector tips onto it, or something else? Is that probably not my problem?

I can reply with example craft that I know can get to space, and even pictures of both of these procedures, if that would help. And thank you for your time.

[Master Tao]

Jovus,

For 1, try pitching over 5 degrees east at 100 m/s, or 2-3 at 75 m/s. I find that generally works for two stage to LKO lifters.

For 2, you can play with the throttle on the way up to increase/decrease how quickly your pitch changes. I tend to use fine controls after the pitchover. Most rockets won't actually be able to do this, but every once in a while, you'll make one that can reach orbit without touching WASD, just the throttle.

I have an album online of a decent launch, but the pitchover wasn't aggressive enough, so I'll try to replace it and link back here when I'm done.

[ferram4]

@nli2work: It uses the entire visual mesh, excluding specific transforms used by Firespitter modules, since until now they have been the only ones where such values need to be ignored. I may need to add a way to add additional exemptions for Karbonite modules, depending on what you're doing.

@Jovus: <clippy>It sounds like you're having trouble finding that perfect middle ground between the extremes. Would you like some help?</clippy>

Anyway, the problem is that gravity turns are technically chaotic trajectories (the end conditions and path are highly dependent on small changes of the initial variables), which means that it's really easy to over correct from launch to launch. I've found something like a 5 degree initial turn at 100 m/s, holding that orientation until the velocity vector meets the orientation vector, and then following that up to about 30 km or so where you start trying to have your own ideas about what's a smart orientation to take tends to work pretty well. The specifics generally vary with the TWR curve of the rocket as a function of time.

[nli2work]

@nli2work: It uses the entire visual mesh, excluding specific transforms used by Firespitter modules, since until now they have been the only ones where such values need to be ignored. I may need to add a way to add additional exemptions for Karbonite modules, depending on what you're doing.

Ah okay, so it's mostly working by happy chance then. The two I am testing are in the upper left and lower left, http://i.imgur.com/wm9hUzE.png. Fortunately they already use Firespitter modules for the moving parts, so they both appear more or less as a tube to FAR. I was afraid initially their collision meshes would act as flat discs and generate too much drag. How does FAR/NEAR treat open meshes and/or back-facing faces? Is there a way to turn on the drag value display that was in v13.x?

[ferram4]

FAR and NEAR don't know about faces. They only know about verts, really.

Drag numbers can be displayed by activating them in the FAR debug menu in the Space Center scene.

[nli2work]

FAR and NEAR don't know about faces. They only know about verts, really.

Drag numbers can be displayed by activating them in the FAR debug menu in the Space Center scene.

Verts have normal direction as well. how does FAR/NEAR treat Verts normal that is same direction of air flow? For a basic flat surface, I'm assuming leading edge verts have normal opposite air flow; broad sides have normals at various degrees to perpendicular to airflow; and trailing edge have verts along same direction of air flow. correct? so a mesh with lots of verts with normal opposing air flow, generates lots of drag. and assuming that... a mesh's face smooth settings would change the drag characteristics of the surface as well, correct?

Edited August 6, 2014 by nli2work

[ferram4]

It doesn't care. It knows about vertex points in space, nothing more. It uses that to approximate a convex shape around the part. Anything more complicated would result in the drag calculations becoming really nasty and loading times would suffer as a result.

FAR mostly takes advantage of the fact that you find very few one-piece complicated messes to generate the approximate geometry used for it.

Stop over-complicating it. It's not that complicated. It never has been, and probably never will be, because then drag characteristics suddenly vary greatly based on not only visible part shape, but modeller style and skill (for how they handle normals and how many, and how quickly they change).

[nli2work]

Ok, thanks! Just checking because I don't know how complicated it was to begin with.

[Stephanie the Viking]

I was playing with Infernal Robotics and TweakSize installed, and decided that adding this one was the next logical step, but I can't even play for twenty minutes without the game crashing now. For the record I am using 64Bit KSP. With so few mods installed surely I shouldn't be having this sort of problem?