blowfish

RPM has an unofficial patch which makes it work with 0.90 IIRC.

FPS on crafts with many parts is limited by CPU (physics) rather than graphics, so you won't see any performance improvement in that respect.

Are there any design tricks to increase roll damping? I can fly my craft in level flight and control pitch without SAS, but when I turn I get roll oscillations, which die out over time but not very quickly - is there any way to damp those oscillations?

It's a know problem with the NodeSwitch module. I don't think a fix has been proposed yet.

[Moderator: not] here 10char

AJE engines won't flame out if there isn't enough intake. Does the intake area read 100% when you right click the engine?

That's also a problem with firespitter.dll. Update it.

Make sure the firespitter plugin is updated to the latest version.

The RL SABRE is a lot bigger than B9's version - about 3.8m in diameter at the intake and closer to 5m at the nozzle - it's a much bigger engine than B9's, which are really scaled for stock Kerbin.

Yes. Get this. Use with caution of course, results may not be 100% correct

The static thrust got nerfed significantly between versions 1 and 2. I believe that it makes more sense now but I can understand why some people might be unhappy. Also, I've been through the code and made a few notes: AJESolver.cs, line 256: Isn't mdot the total mass flux of fuel+air? Doesn't that mean that ram drag is being subtracted for fuel too and not just air? AJESolver.cs, line 249-251: I'm pretty sure 250-251 repeats the calculation on 249 AJESolver.cs (AJESolverTester only), line 275: 3600 should be changed to 101972 to reflect the change from imperial to SI units. For the compressor calculation iteration, wouldn't it be more computationally efficient to start with the prat3 of the previous thrust calculation (which is likely to be under similar conditions) rather than starting from the design CPR every time? Of course this might create an issue if the engine is shut down and then reactivated... I'm also thinking about how to implement variable bypass, but it seems to get more complicated the more I think about it. The basic idea would be to modulate the core/bypass areas in order to simulate bypass doors opening and closing, which is simple enough. The trouble is how to control it. You might want to close bypass doors in order to create more thrust for takeoff or at high altitudes to allow supercruise. On the other hand, you might want more bypass at very high speeds in order to create a turboramjet effect (since this is basically how the J58 operates). The only way I can think of to give the right amount of control is via action groups, but it might still be difficult to operate in practice.

That should theoretically work. The problem arises when the body you are launching from isn't Kerbin. But KK hasn't been tested with anything that high so unexpected results might occur.

It used to be acore, now it's just Area. Thrust should be proportional so just scale it how you want.

Much appreciated, and sorry it's causing you so much trouble - not quite sure how the math behind part clipping would affect my craft but I can see how it would be a pain to deal with in general. Yes. The easiest way to download it is to go the the main page and click download repository on the right side, then just copy over GameData/FerramAerospaceResearch as usual.

I was using the dev build, but the trick with the decoupler worked - thanks. Is there any way to get it to update without using a decoupler?

Hey ferram, do you have any idea why this fuselage might be causing so much drag (much more than any other part on the craft)? Maybe it has to do with the stack nodes? The node on the nosecone is defined as size 1 but the nodes on the fuselage have no size definition. Curiously, the coefficient of drag is showing up much higher in the flight scene than in the editor aero sim under the same conditions.

To those experiencing the issue of loosing mission progress when recovering a craft: I found a workaround - instead of clicking the recover button on the ground, go to the space center and recover from the tracking center (or the main screen if you're near the KSC).

Are the other Firespitter modules working (like fuel switch). I got a bad dll the first time I tried to update Firespitter to 0.90

Yes, because the 32 bit version of KSP can only address 4 GB and the 64 bit version is highly unstable.

Ok, here's a question for everyone: What's the smallest SSTO you've built with AJE (with or without RF)? What ascent path did you use? The smallest I've managed is about 23t, which is significantly heavier than the smallest pure rocket SSTO I've built (about 14t).

Good catch. I'm still not quite sure what's wrong with the docking bay though - FAR should be calculating a bounding box based on the mesh (not colliders) but evidently that process isn't working properly.

Sounds like a Firespitter issue. Either reinstall the dll from the B9 download or get the latest version from snoj's Github.

You'll definitely see the helium loop mentioned if you look around. There are two basic ideas involved: 1) Running fuel directly through the precook is problematic for various reasons so you want to have some inert intermediary and 2) If you're running that cycle, why not extract useful work from it?

FAR doesn't modify the Isp, but does modify the thrust of stock jets: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeAir]]]:BEFORE[FerramAerospaceResearch]:NEEDS[!AJE] { @MODULE[ModuleEngines*] { @maxThrust *= 0.5 } } @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 } } }

The SABRE really operates differently from normal jets - in a normal jet the turbine and compressor exchange work directly, whereas in the SABRE the helium loop acts as a heat engine, taking heat from the incoming air, doing work in the compressor, and dumping waste heat into the fuel. There's some data on how it operates but it may not be enough to create a full model.