Taverius

B9CompressedAir is marked NO_FLOW on purpose. Its only supposed to work a) in atmosphere have small reserves regenerated by the little generators in the parts. This is ... not really possible right now, without a custom plugin ... and we're already using one for the AirCS, so I can see a mountain of problems coming that way. velocityCurve { // Based on Fnet data from NASA EngineSim, curve fitted with MuMech CurveEd key = 0 1 0 -0.002 key = 500 0.67 0 0 key = 550 0.44 -0.01 -0.01 key = 605 0 0 0 } Its a limitation of ModuleEngines - it doesn't model jets anywhere near realistically, so its possible to do things like that with any air-breathing engine. I'm afraid the precoolers are inert/non-functinal/just for looks right now. We'd like to have them do things ... I'm planning to test something regarding that in the future. It was lights or window and we decided to go for lights in the end. We might enable it again, there's a way to do it now, but bac9 is currently just too busy. Its something Kine made for a project he never completed, its just happened to do exactly what we needed to animate intakes with airspeed. No they do not. atmosphereCurve only affects Isp. velocityCurve changes thrust with airspeed, which creates the effect you are seeing. Yes, its necessary.

Just wanted to let everyone know that while bac9 is very busy, I'm back in business and will be working on a small update. We have a couple of new parts for you to play with, likely a new stock craft, and I'll be going through 100-odd pages of thread looking for bugs to fix (not looking forward to it). Depending on how long it takes this may come after 0.22, but it is coming

@tiron: When you have engines in symmetry one will always flame out first - that's just a KSP bug. When bac9 is around I'll get the Unity files for the DSI and double-check the intake vector, in case something screwy is going on there. @ferram4: They lose net thrust because of ram drag, but all turbine engines (and ramjets etc) produce thrust as a function of airflow, so gross thrust always goes up (quadratically). Now, as you start moving you do indeed go from 0 ram drag to >0, so to start with net thrust goes down. But gross thrust is always increasing, and given enough speed it will overtake the ram drag. If the net thrust eventually goes back up above your zero-airspeed value before you overspeed depends on various design parameters but is most strongly affected by the bypass ratio, as that directly affects the thrust/cross section ratio and thus the gross thrust/ram drag ratio: The best tool to see this is NASA EngineSim. Unfortunately due to govt shutdown the NASA site is not available, so here's a link to my own copy of the downloadable version, if you want to have a play with. Its a java applet and its a little buggy, but it is useful to see general engine performance trends and such. But, when I was doing a velocity curve for the TJet I used the values I got from the 2 turbojets already present in EngineSim (you can make your own) and came out with: velocityCurve { // Based on Fnet data from NASA EngineSim, curve fitted with MuMech CurveEd key = 0 0.56 0 -0.0005 key = 200 0.52 0 0 key = 600 0.7 0.0013 0.0013 key = 900 1 0 0 key = 1100 0.5 -0.005 -0.005 key = 1250 0 0 0 } There's some fudging on the end, obviously, and the final velocities are somewhat arbitrary based on my desire to stick to realism - the fastest pure turbojet was in the MiG-25 and it would overspeed and melt if pushed above mach 3.05 for more than 5 minutes, but that gives you a rough idea. You can get CurveEd, so you can play with with floatCurves interactively and see a display of the exact formula used by KSP, here. Its an extremely useful little tool r4m0n made for me So, anyway, while thrust = 1 at speed = 0 is appropriate for the basic jet, its not for the turbojet. Can't remember where I found the data as it was nearly a year ago, and of course most of it was NASA/NACA images and thus not available atm, but from I found most turbojets (that I could get gross thrust/airspeed curves for) have a takeoff net thrust fraction (of the peak supersonic thrust) in the 0.5-0.6 range, while more modern low-bypass turbofans tend to be in the 0.7-0.8 range. Higher takeoff thrust, along with fuel efficiency and lower operating temperatures, was one of the main reasons why few things use turbojets right now. Notable exceptions are when you need to prioritize the compactness of the installation, or the ease of mainteinance, which is why the GE J85 is still widely used - its small, has a lot of thrust for its size, and since its a 40 year old design its extremely reliable. ......... The assembly-based version sounds very interesting, though I foresee the same problems with the hiccups when parts fall off (and thus you need to recalculate the assemblies) like you have in the raycast experiment.

1.5 is out. Only notable functional change is a fix to the intake parameters for the nacelles and all small intakes, thanks to a better formula found by someone over on the B9 aerospace thread, which I've had in dev for a while but couldn't release due to KSP bluescreening me. Intake performance of the nacelles and small intakes should now be as I originally intended it. As noted in the OP, if upgrading and you do not use a mod manager, please be sure to reinstall the Gamedata/Squad folder, as from 1.5 onwards this pack does not overwrite the stock .cfg files anymore, and leaving the old ones in could lead to duplicate parts and other weirdness.

Updated version using Module Manager incoming, in testing. Nothing new, mind, just making it work with the latest FAR the way I want to, and fixing a few bugs in taniwha's MM version - which I used as a base, thanks for saving me the work!

@feram4: There's a bug in the config file for the aero engines here: You're using 'key' in the thrust curve, but you should be using '@key,index'. Specifically, you're doing: @PART[turboFanEngine] { @MODULE[ModuleEngines] { @maxThrust = 140 @velocityCurve { key = 0 1 0 0 key = 300 0.7 0 0 key = 1400 0.8 0 0 key = 1800 0 0 0 } } } @PART[JetEngine] { @MODULE[ModuleEngines] { @maxThrust = 140 @velocityCurve { key = 350 0 0 0 key = 300 0.2 0 0 key = 0 1 0 0 } } } The result is that instead of modifying the thrust curve, you're adding to it: Instead, do this: @PART[turboFanEngine] { @MODULE[ModuleEngines] { @maxThrust = 140 @velocityCurve { @key,0 = 0 1 0 0 @key,1 = 300 0.7 0 0 @key,2 = 1400 0.8 0 0 @key,3 = 1800 0 0 0 } } } @PART[JetEngine] { @MODULE[ModuleEngines] { @maxThrust = 140 @velocityCurve { @key,0 = 350 0 0 0 @key,1 = 300 0.2 0 0 } } } Also, tell me who makes these magical turbojets that give 100% thrust on the runway, the us air force would like to know ;D

@tiron: The DSI Intake is a 100% stock intake with perfectly normal values ... nothing weird there, check yourself. Not sure what could be wrong with it, though I'll check. @ferram4:You can't mention something like 'assembly-based version' and not give out any details

rhoark, the AirCS in the B9 pack uses this. I think I had to recompile the plugin using the 0.21 libraries to get it to work, mind.

Anyone know what the defined behaviour of @foo is if there is no 'foo' value pair defined in the base part? Does it create it or ignore the line?

@ferram4: Finally have a computer that can run 0.21 without bluescreening, wondering if FAR auto-calculates e yet?

Plugins required for part functionality.

I have it and I'm using it as a base for the next version, but MM doesn't do anything positive for /me/, which is all I care about

So I just finished updating the reaction wheel/cockpit troque values for .21.1 and updated the crafts - mainly adding some hidden RTGs and some solar panels for the spaceplanes. Mass of the reaction wheels is off from stock because stock has no clue what its doing. Stock SAS: 20 torque, 0.3 tons. Stock ASAS 1.25m: 20 torque, 0.5 tons. Stock ASAS 2.5m: 20 torque, 0.2 tons. When whoever did those values sets a standard I can use I'll rebalance the B9 reaction wheel masses, until then I can't be arsed to chase an indistinct moving target, so for now the B9 reaction wheels do more torque per mass compared to stock. Hopefully that's all we need for a fully-0.21.1-compatible R3.4, as 0.21+ bluescreens my machine with frightening regularity.

The numbers are weird because: a) jet engines in KSP use the wrong formula for ISP. Let alone that they should use TSFC and not ISP. The base propellant/air mass ratios for the jets are wrong. (turbine engines are not stochioisometric). c) The bypass ratio of the engine (which gives the 45:1) screws you up even more. Essentially the Turbojet ISP is eyeballed from the default values, and for the turbofans I just add the bypass ratio and leave the basic ISP pretty much the same, except for changing the way it responds to altitude. Arguably I should tweak the basic ISP as well, but subsonic engines have such a narrow usage envelope at the moment that its fine as it is. Yes. I'm just dithering because I don't like Module Manager, as its making my life more complex for no advantage. It'll come when its ready.

That's KSP. We're set up like the default lights, but its not applying the light fadeoff during warp.

Install whichever one has the newest plugin last. Hell, if you have Firespitter as well as B9 you can skip installing the version of the firespitter plugin we provide, so long as you keep firespitter up to date. Its currently at 5.1.1 (Pre5) on spaceport. We could probably swing it with LookAtFX and FXConstrain but it sounds like a lot of work for a little piston geegaw.

Sounds weird. They all work here? The only thing I know that could break them is if you didn't install the various plugins along with the parts, or maybe overwrote the firespitter plugin with an older version that does not have FSanimateGeneric.

Yup. That's not a very descriptive error report. If you don't actually explain what's wrong nobody can help you.

Oh I'm fine with it, I just added a new block to my spreadsheets for this. But its funny just how many such issues there are. Can you please make an issue on the KSP bugtracker about this?

Yes you did. There's more than 1 part per folder. Counting the folders is not an accurate count of parts anymore. This is necessary to share textures and models. If you mean in-game, if you don't see all the parts you did not follow the installation instructions. You MUST have 0.20.2, and you MUST install in GameData in without changing the names of the directories.

Right. Report that to Snjo in the Firespitter thread, would you? In other news, thanks to some work by a.g. in the FAR thread I have the correct formula for ramp and S2W intakes, so the flow will be correct from now on. The intake speeds will give you meaningless values, mind.

Thanks! I'll fix the B9 intakes and Pizza Pack intakes ASAP. About intakeSpeed, it is indeed doing absolutely nothing. However, were you to fix the syntax of the stock intakes you would find yourself most likely flaming out on the runway. The fact that all the intakes have a base speed of 100m/s instead of 10m/s has so far masked a bug with intakes when speed is close to 0 which can cause the IntakeAir value to fluctuate wildly. So keep using the default of 100. Well, now the intake speeds are pretty meaningless, but oh well.

It still needs the MechJeb 1.9.8 plugin (MuMechLib.dll) for the camera rotation to work. Collision for the landing gears is wonky period. Whine at C7 to make it sensible Don't scale the rescales, make yet another copy of the stock one, give it a different 'name =' and apply your own rescale value. Default is 1.25.

So, I'm a little confused, is unitScalar in a linear relationship like I've been using it, or is it quadratic? If its the latter, I have a lot of intakes to fix

They're higher efficiency than the LV30-45, but they're not LV-Ns. They're closer to an aerospike.