Taverius

You have to do stuff like KSPi and bypass the resource system, because you really want to split the engine and the nozzle, and you want more data than the 'amount' of exhaust, you want volume/density/speed/temperature. Then you do new models (pretty simple, they're just cylinders) and textures for all engines. Redo the masses for nozzles and engines. Would definitely be a lot more interesting to be able to choose fixed/variable/2d/3d vectoring nozzles separate from the engine. Well, you don't have to split every engine - the B9 civilian turbofans and SABREs obviously don't need it, but most do.

- v1.6.2 New RAPIER curves. Mk2 node sizes back 1. Fix broken floatCurve replaces. Support MM patches changing ModuleEngines to ModuleEnginesFX. Hopefully that should be all bugs squashed, 1.7 using TweakScale after I'm done with the new B9 release (so a few weeks at least).

Getting the right value for Oswald's Efficiency is really, really hard. Here is an excerpt of a PM I sent ferram about it: Its related to a lot of things that are not surface area. Essentially, copy whatever ferram gave a stock wing of the same general shape.

Sure. At a very basic, you can get the worldspace positions for the vertex in question with 'n' in edit mode and selecting world co-ordinates. You can also turn on angle lenghts, though you have to edit the colours in preferences because the defaults are an utterly useless unreadable colour. I was trying to use the ruler to get angles, but the snap function is rubbish.

So it turns out I've been using Maya for so long I can't use blender to save my life. Therefore, all I have is a short stub on the generics of how to approximate an wing's mesh. At least it will (hopefully) help you figure out b_2, MAC, and so on. There's an image! With colours! Plus tips on several assumptions FAR makes one must keep in mind when doing this. Hopefully someone more familiar with Blender will be able to write a more detailed step-by-step.

Looking great

Non-omnidirectional billboard fx are a major pain in the behind. Me and bac9 tried setting some up for some B9 engines we're working on, and in the end gave up We did send it to nazari so maybe he/she will be able to figure it out how to make it work, but it was definitely non-trivial.

That's a good point. I'm going to put a little tutorial on the wiki with instructions on how to use blender to import the model and get 'accurate' measurements for FAR's trapezoidal approximation, the same way I did the values FAR uses for the stock wings. In the meanwhile you want to install blender and taniwha's .mu importer for blender, you can find it in the tools forum.

1.6.1 is out, mainly fixes to some uh ... oversights I made with the last release. Also explicit compatibility with stupid_chris' Stock Rebalance Project.

Oh, something I forgot in my other post: When using model.scale, model.scale * rescaleFactor must be = 1, because of a bug.

Because its a major pain in the ass to do. Since its a spaceplane and it has to come in belly-down, it cant have RCS ports on the bottom. The ones pointing down have to be on the side, like on the S2 (and the shuttle). Take a good look at the S2 with RCS Build Aid in SPH and remember it has to provide balanced thrust on those axes. I hope you're good at trigonometry and vectors. Anyway, if you're gonna do it, the constraints are: They gotta face all 6 axes. They cant be on the bottom. They gotta give balanced forces on those axes. RCS transforms in unity use the green arrow, not the blue like engines. Be careful though, cause if you start down that road you'll be adding them to every other cockpit too. I hope you like texturing, because you'll have to add them all in

I even went so far as to make an issue in the bug tracker, but the devs never look there anyway.

I shudder to think how heavy an HL pod would have to be. Guess it would be worth it for the stupid amounts of people you could stick inside it. Mind you don't end up in the final with those RCS vents in the nose's texture

Waiting on approval from Curse, but in the meanwhile you can get 1.6 here. This release is ... somewhat tested. I didn't add any parts or make any functional changes, but moving much more stuff to MM files might have introduced issues.

Pizza 1.6 is currently waiting for approval on Curse ... should be trivial for you to update support if it needs any changes at all.

Anywhere I try to do something like this !mesh = DELETE MODEL { model = some/model/url } in a +PART I get an array index error in log and no part. Help? EDIT: It seems you can't delete/replace MODEL nodes, only add/edit.

Pretty sure its so you can set the pitch control input used during the simulation, ie how much, if any, you're pulling/pushing on the stick.

fx_gasjet_white sounds like a PREFAB_PARTICLE. These are old effects running under compatibility mode. Only about 50% of them point the right way when attached via ModuleEnginesFX to the same point they were attached to with ModuleEngines. I don't know why this is so. If you want to experiment with the new FX, you want to play with MODEL_MULTI_PARTICLE/MODEL_MULTI_PARTICLE_PERSIST stuff. The latter is from SmokeScreen.

I'm liking the general shape a lot. Would be awesome if you can make the windows wrap the right way, might be quite a lot of editing though

The thrust is overpowered for a good reason - it has to fight against the stock drag model. Edit: oh and the runway being much shorter than whats actually used for for airliners and will be used for SSTOs if we ever make some. Taking off in KSP is much harder than it should be, if you give engines realistic thrust values with stock drag you never lift off before the end of the strip.

Could you set the assembly name to something so it can be targeted by ModuleManager? In the current release, the 'File description' is empty.

I actually haven't tried this yet (too busy updating B9) but here's some notes on scaling and stock balance from making Pizza and B9: Engine thrust scales by cross-section surface area, with a small ISP bonus/penalty as you shrink/enlarge. Mass also does so, regardless of how it would be IRL, with the same bonus/penalty. I've never actually curve-fitted it, but it seems to be about 5% penalty in both ISP and TWR when going from 1.25m to 2.5m. Engine heat is related to thrust/mass ratio. For example, if you scale an engine by just doubling its thrust and mass, heat stays the same, as ratio is identical. Non-FAR wings are an unholy mess of random values. The code in pWings to scale lift/drag (which I wrote) is probably your best bet for hints on scaling those in a pseudo-realistic way, but abandon all hope of taking 2 stock wings of similar shape and scaling them to be the same size and getting the same values, unless a) you use my code from pWings and you're stating from Pizza Pack lift/drag values. The stock lift/drag values are just semi-random numbers C7 and Nova put in way back when, and have little to no relation to the actual dimensions of the wings, not even the surface area. The first rule of rescaling wings is: drag scales with mass and lift, so as you change the mass and lift of a wing when you rescale, the dragCoefficient does not change. It is determined purely by the shape of the airfoil. Intakes are horrific. Specifically, their drag scales with mass as with everything else, so changing the mass of an intake when resizing can drastically alter performance in unexpected ways. There's 3 variables you can use to fix it so a smaller area (to give the right drag for the mass) performs like one of the right size, but because of a bug in the code, one of the values is used twice. The formulas are: area: divide by (mass/0.01). Intake drag in stock assumes an intake weighs 0.01. This means that the stock Air Scoop (mass 0.1) has 10x the drag it should. unitScalar: default is 0.2, multiply by sqroot(mass / 0.01). supposedly a flat multiplier on the amount of air coming in, buut. maxIntakeSpeed: default is 100, * (unitScalar + sqroot(mass / 0.01)) / (unitScalar + 1). Is used twice in the code instead of once. written as intakeSpeed in the stock .cfgs ... which is a parameter the module does not have. [*]Also, when shrinking intakes, its best to not change the amount of IntakeAir they can store, or you can get rolling flameouts on the runway even though you technically have enough airflow, just because of how resource requests work.

Hey Tiberion, the NP Heavy Winglet needs converting to the new ModuleControlSurface PartModule. Just change the module to Part up top, and wrap the 4 winglet parameters in: MODULE { name = ModuleControlSurface }

Feel free to scrap the windows and make ones that give a decent pilot FOV. In fact, please do so.

More importantly, you can't simulate without data, and all SCRamjet hard data is top secret. They're also ... well, not very good. Very High weight, Very High fuel consumption, Very Low thrust, and you have to build the plane around the engine to make it work at all.