ferram4

Hyratel, I don't know what you're referring to. You shouldn't need a cockpit for the control surfaces to work unless you're using a 3rd-party command pod that does something really weird. The control surfaces should work as long as there is a part capable of receiving commands, and the stock pods have been modified to have the control systems GUI. Please get back to me about what you're using, since it probably means that I didn't test things as thoroughly as I should have. Also, for anyone interested, you'll be happy to know that in v0.5, you'll be able to analyze your planes in the SPH and have an idea of how they'll fly before you go on the runway. At least you will if you're familiar with aerodynamic data. So that means that a lot of people will crash a lot of planes while learning how to read the data. Oh well, it's not like that's anything new. But more seriously, this should lead to the ability to plan airplane design a bit more, especially at high Mach numbers.

@Mekan1k: Killing MechJeb's efficiency is to be expected, since it's optimizing for a different drag model. In addition, the optimum ascent is different between different rockets now, which is something that MechJeb never had to do before and which it is not equipped to handle. Given how much smaller drag is at this point, I would say it just makes sense to full throttle it the whole way and pitch over at ~150 m. As for "clocking" the Mach Number, I assume you mean taking down and saving Mach Number data from the mission, correct? I'll probably do something like this, but not for a while. @Oicani: It's possible that the control surfaces had their control axis values reset to nothing. You'll have to set them manually in the editor. Did you update from an earlier version of FAR, or is this your first install of the plugin?

Define "unfair" for mods. For example, my plugin completely changes the lift and drag models and sets them to more realistic values, as opposed to the current unphysical aerodynamic models. Would it qualify as "unfair" under your definition? (Just asking, because I have a bunch of planes that I could submit, but all of them use the plugin )

@Goldenpeach: I'm actually going to improve the dynamic control system to account for Mach effects in the next release (it won't be exact, but close enough). And yes, supersonic dis-assembly is probably one of the most awesome parts of this plugin. It makes all the effort put in SO WORTH IT! @Thorfinn: The speed of sound isn't constant and is dependent on air temperature and gas properties, so I don't have too much control over it. I'd prefer not to mess with the gas properties section, since that could get very nasty very fast, and besides, sound moves too slow as it is (Keep in mind, if you see a plane take off at the airport, it's moving at ~Mach 0.3--sound is really slow). If the gas properties get messed with too much then everything will feel very, very wrong, IMO. Also, whatever other questions you ask, I'll be happy to answer.

It's not jet engine turns into rocket engine, it's rocket engines all the way up, burning LH2 and LO2. However, in atmosphere the SABRE engine can use atmospheric oxygen in place of LO2, switching over as the atmosphere thins out. Here's how it should be coded: A fueltank with resource LH2 A fueltank with resource LO2 An intake that produces resource Air An engine that burns LH2 and (LO2 or Air) at a 2:1 ratio, prioritizing air With the shift towards PartModules that the devs have been doing, as well as the shift towards using resources rather than hardcoded fuel types, this shouldn't be hard to code in the coming updates. It can probably be done now with PartModules that have already been implemented in KSP, but which aren't being used yet. Also, I think the rocket at the back of the vehicle is a very large RCS.

You're correct, the old fuel tanks did hold 500 L and now they hold only 400 L. The other problem is that the efficiency of the engines has been nerfed quite a bit to make them more realistic. The Isp (specific impulse, if you don't know what it means, search around the forums a bit. I believe there's a thread in the Science Labs dealing with it) of the engines used to be ~500s, but is now droped to ~390s in vacuum and it's lower in atmosphere. In short, your rockets need to be larger or use more efficient staging than they did prior to 0.17 to do the same thing. That said, there are far more tools to work with (including the nuclear engine with an Isp of 800s) to make the job easier. Also, I have landed on the Mun with the 1-man pod, it is very possible and is easier to get there than the 3-man pod. Edit: Ninja'd by sal_vager. He's also right.

Very nice work on the spaceplane. I think the thing you're talking about is the spoiler tag. What you want to do is this: {spoiler="something"}{/spoiler} But replace the { and } with [ and ], respectively, to make the BB code work. Keep up the good work. This has great promise.

It sounds like it crashed while the ship was moving in atmosphere... which means the game wouldn't have been able to save it. Unless the ship is stopped on the ground or above ~25km, it won't save the ship, since it can't figure out the trajectory (it needs to do physics calculations rather than a nice simple "it's here on the planet" or "this is it's orbit, we have an exact solution" that saved ships use). Sorry to say it, but you'll have to relaunch.

Oh, of course the default wing physics are buggy. Lift is proportional to velocity rather than velocity squared, angled control surfaces can create thrust, no stall mechanic whatsoever, and drag includes mass by accident. Really, the only thing anywhere near realistic is the stability of airplane designs, since the basics are there. As olex said, it doesn't seem to be a priority for now, but there is an aerodynamics fix plugin (by myself--full disclosure ) that fixes a great deal of the problems. It's still in development, but is a vast improvement over what's already there.

Okay, update for everyone. I found a nasty bug that caused negative drag on wings at very high mach numbers (really only occurred during re-entry, but that's when we want aerobraking, so it's important), so I've fixed it and put the v0.4.2.1 revision up. This bug was probably due to the optimization of nonlinear supersonic flow, which probably needs some more tweaking. That said, if anyone else happens to like bringing space shuttles or winged missiles down from orbit, I would greatly appreciate any and all data that anyone can come up with this. Sorry to anyone who ran into this bug. To make up for it, you get the feature Thourion brought up.

@Thourion: I did not know it was possible to do that. It was simple to implement, and thank you for pointing it out. I wish I had that earlier. @Thobewill10: Yep! I believe there is a post I made earlier that goes over it in a little more detail.

Boojah: If you want to get to Mach 3, build a smallish craft, that is very sleek and aerodynamic looking and take time getting it up to speed. You need to slowly push the plane higher up into thinner atmosphere while trying to keep the engines getting enough air to run. Xune: I looked into what you were doing, it turns out that the class FlapAndSlatModel was not set up to handle the fix for the deflecting backwards bug... so I went and rewrote it quick and made a more robust solution that doesn't require anything in the part.cfg. As a reward, you get a new small flap part. Oh, did I forget to mention that version 0.4.2 is out?

7/10 - You post fairly frequently.

There was a demon that lived in the air. They said whoever challenged him would die. Their controls would freeze up, their planes would buffet wildly, and they would disintegrate. The demon lived at Mach 1 on the meter, seven hundred and fifty miles an hour, where the air could no longer move out of the way. He lived behind a barrier through which they said no man could ever pass. They called it the sound barrier. -The Right Stuff <iframe class="imgur-album" width="100%" height="550" frameborder="0" src="http://imgur.com/a/JFOzc/embed"></iframe>

The way things are currently set up, I don't see the need for a ramjet part, and certainly not a SCRAMjet, since a SCRAMjet wouldn't be necessary until ~Mach 5-7, which is orbital re-entry / ascent territory, and I really think that rocket engines should be needed for that. @Boojah: KSP does model exhaust velocity, and this is already appropriately set up for the engines in game. The basic jet engine acts as your "turbofan" engine already; it is capable of supersonic speeds if you really want to go that fast, but it won't be very efficient past Mach 0.8. The turbofan engine (which really should be labeled "turbojet") is already exactly like your "normal" jet engine. I don't want to add a ramjet engine until later though. I also don't want to add an engine that overheats at full throttle since even though in real life there are engines that are set up like that the reason they're set up like that is so that the engine can always maintain a given level of static thrust regardless of outside temperature and altitude (which isn't too much of a problem here). Besides, too many people would be annoyed with their engines exploding when they're trying to take off. Soon I'm going to take a look at implementing a version of an intake module and an atmospheric engine module that should help bring the thrust and exhaust velocity values closer to reality. I'll probably set it up like so: Fuel tanks carry fuel, probably set up to use the specific energy values of Jet-A or Jet-A1 Intakes provide oxidizer, and the amount it can provide is based on ram pressure and the intake power provided by the engine Engine nacelles burn fuel to the extent they can; this increases pressure inside and provides power to drive intake. Nozzles actually provide thrust based on difference in pressure from engine part and air pressure. This should make the actual engine nacelle parts useful and should allow for more varied types of engine design rather than the current "Do I use the small efficient engine or the large and stupid engine?" that we currently have. For example, I envision slapping two engine nacelles back-to-back as a way to increase engine pressure and thus create more thrust with one nozzle, but at the drawback of burning more fuel and increasing the temperature through the nozzle. At that point, the "TurboFan" and "Basic Jet" engines will become supersonic and subsonic jet nozzles, respectively, while the engine nacelles themselves will contain turbofan or turbojet engines.

@Boojah: Yep, it's designed to be that way. The jet engines were originally on-par with the rocket engines, which just isn't realistic--I'm sure you've seen people use them as first-stage engines for rockets, if you haven't done it yourself. Also, the Su-35 is very slightly unstable--as the real life one is--so if you want to fly it I would advise turning on the pitch damper and setting the gain value up to ~3. The Su-35 should benefit a great deal when I implement a leading-edge slat part so that it doesn't stall as easily. So, for everyone interested: I found a bug in the CoL calculation (which is used not only for the editor but is also used to place forces on the wings) where the CoL on the swept wing and tail fin would somehow be offset the wrong direction from the origin (and so not in the middle of the wing, as it should have been). This should make the lift and drag model more consistent (though it isn't game breaking, as no-one has complained yet). I've also been able to recreate the bug that narcillian found in this post, so I'm looking into what's wrong there. I'm also going to add some code in so that biplanes have their upper and lower wings interfere with each other. Which means that biplanes will not be as effective at lifting as they were before.

A result of my alma mater. For logins they used the first five letters of our last names, then the first initial. If wasn't available, they added a number to the end of it. I've stuck with it since.

I think I see the problem with this one. It has a "conventional" landing gear with two landing gear parts near the front and a single one on the tail (a tail-dragger), rather than the more common "tricycle" type of landing gear, unless I'm seeing wrong. This makes me add another reason: 5. Conventional landing gear is unstable on the runway. Planes with that type of landing gear setup want to swap ends. Try getting rid of the tail landing gear and putting a landing gear part underneath the cockpit. Move back the landing gear on the engines just a tiny bit. That should fix it. Edit: Try adding more vertical tail and using ALT + WASDQE in the editor to tilt the horizontal tail downwards a bit. Also try using the same controls to tilt the wingtips upwards a tiny bit, so that the wings look more like the way a Boeing's wings are angled. It helps make the plane more stable. Also, remember that avionics tries to counter any motions, including the control inputs you give it, so you might want to turn it off for some maneuvers.

Actually vvaris, I think I found a way to orient an attach node any number of degrees that you want: In the part.cfg, the attachnode line looks something like this: // --- node definitions --- node_stack_top = 0.0, 75.0, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -76.0, 0.0, 0.0, 1.0, 0.0 node_attach = 0.0, 0.0, -51.0, 0.0, 0.0, 1.0, 1 The first three values are x,y,z coordinates, very obvious. The next three values are the part-oriented x,y,z values for the direction of the attach node. If you want to try angling the part down, say, 30 degrees, try taking the sine and cosine of 30 degrees and drop it in there: // --- node definitions --- node_stack_top = 0.0, 75.0, 0.0, 0.5, 0.8660, 0.0 node_stack_bottom = 0.0, -76.0, 0.0, 0.5, 0.8660, 0.0 node_attach = 0.0, 0.0, -51.0, 0.0, 0.0, 1.0, 1 And the part will try to attach at 30 degrees off. I have to admit, I love the parts and would hate to see you waste time re-doing a model when this fix should work (I think). If you already thought of it and it didn't work, sorry for wasting your time.

Make sure that it is rescaleFactor with the lowercase r and the uppercase F or the game won't recognize it.

First off, welcome to the wonderful world of planes, which is harder than rockets. We all understand how bad it can be, so infuriation can be justified. That said, here is what I have learned: Don't put SAS modules on. Avionics is OK, but you don't need the SAS. From what I have heard, it was broken in 0.17. Smaller planes always tend to act like over-caffeinated squirrels because their control surfaces are much larger than they should be. Fewer control surfaces generally help here. Build a larger plane with longer wings. The larger the plane is, the less it handles like an insect and the more it handles like a flying barge. You may want to try trimming the plane for level flight by holding ALT + WASDQE to give it a minor amount of constant pitch-up or roll if necessary. Make sure to turn on the Center of Mass and Center of Lift indicators in the SPH (bottom left corner). The CoL must be behind (but not too far behind) the CoM for your plane to fly. If the CoL is in front, the plane will do un-ending backflips; if the CoM is too far forward, the plane won't take off. If the plane is going off course on the runway, there are four reasons that I can think of: 1. There is no vertical tail to keep it pointed in the right direction. 2. There are not enough struts holding the wings together, which allows them to bend into an asymmetric shape. 3. The main landing gear is too close together, allowing the plane to tilt. 4. The SAS is doing something screwy. If you post a picture of one of your custom planes, most people here will be very willing to give constructive criticism and help you out. Hope what I said helped.

The deploy-able flaps are to help get your massive planes off the ground at lower speeds, before they go off the end of the runway. All real-life planes have this since we'd prefer to take off below Mach 0.4. You'll need one of the cockpits with the control panel to make it work, and by default, "9" increases the deflection and "0" decreases it. There are 3 levels of flap deflection, and by default it starts at 2 (with zero being no deflection). Just remember that flaps create more lift where they are, so if they're placed too far behind the center of mass, the plane might not be able to pitch up.

Wow. Okay, long list of answers: @cardgame: Nose cones have done that since the drag fix was first implemented. Currently (because it's really simple) the parts add a fixed amount of drag based on the number of open stack nodes. Try building a plane with two fuel tanks on the wings. Now put nose cones on one, and none on the other. Start forward, and it'll start to yaw towards the one with nose cones (mass offset) until it gets up to speed, at which point it'll yaw the other way (more drag). Or try building a plane with no nose cones, and then add them and compare. If I remember correctly, the large nose cone is better for slower speeds, the combination of smaller nose cone with the adapter is better for supersonic stuff. @theflyingfish: Request granted retroactively through all versions. @Volt and Mariner: It doesn't automatically take effect because there are a large number of static quantities the need to be known about the wing before the lift can be properly calculated. There is a part.cfg template in the readme. You can look at the existing part.cfgs and try to extend that, it uses Prandtl's Lifting Line theory for most of the calculations, or you can read below at my answer to Xune, since he asked something similar. @requimar: There is a large button at the top of the main control panel that should minimize it all. It also should save positions. I may have broken something by accident... I'll look into that. You do not need the readout for anything other than the flaps to work (I should make that more robust). It does reduce the calculations though, since the wing parts can just grab the Mach number from the cockpit part. @colmo: The reason everything has changed so much is that your wings are now calculating how their combined presences affect lift. CoM and CoL have to be almost right next to each other, which is much more realistic; the 747 had a length of ~70.6m, and the difference between CoL and CoM positions was ~1m at all times, accounting for fuel usage. I'm planning on adding a few tutorials once I can figure out how to do them in game, just to handle things like this. @Xune: This is a long answer and gets into how it works, so bear with me. It actually isn't difficult to set any of this up at all, I just think an explanation is deserved for why it's set up this way: The plugin is currently set up entirely through PartModules. PartModules require the part to be active to constantly run code on them. The drag model, therefore, requires a part to be active for that part to calculate its drag. Engines are only active when they can draw fuel, and fuel tanks are only active when the get a fuel request. This means that an engine creates no drag if it is not activated or runs out of fuel. A fuel tank creates no drag until an engine or fuel tank asks it for fuel, and then creates no drag after it runs dry. (Very large DERP) Aerodynamic and structural parts (wings, empty fuselages, nosecones) can be force-activated, as can the cockpit. So those can run the code. The work around: Declare one part a "controller" (actually an instance of the class BasicDragModel) that runs the calculations and applies them to all the parts that can't do it themselves. So the cockpit (for example) can run the drag calculations for the fuel tanks, the engines, the decouplers, etc. If the "controller" part is destroyed, the responsibility is transferred to another part to continue the job, but you need a part with that value to make it work. I would have changed the fuel tanks themselves, but I kept breaking something, so no go there. So, that in mind, here's what to care about: With fuel tanks and engines it figures out the necessary values based on mass (for not fuel tanks) and dry mass (for fuel tanks) to get an idea of the surface area, and it assumes that they are all cylinders (not an unreasonable assumption). You don't need to do anything at all. For non-lifting aerodynamic parts, you need to add this to the end of the config file: (copied from Mk1 Cockpit part.cfg) MODULE { name = BasicDragModel DragType = cone S = 4 } Where DragType can be cylinder, cone, nosecone, tail pylon, or commandpod. Make sure your case is right. S is the surface are of the part. I used 4 for the Mk1 Cockpit and 16 for the Mk1-2 Pod for reference. If someone has more accurate numbers, I'll gladly implement them. This is complicated and you need (almost) every value, so let's go: (Copied from structural wing part.cfg) MODULE { name = WingAerodynamicModel S = 3.06 AoAmax = 30 MAC = 1.7 b_2 = 1.8 AR = 2.12 e = 0.7 MidChordSweep = 45 IsSmallCtrlSurf = 0 maxdeflect = 0 TaperRatio = 0 } S is the surface area of the wing part. Calculate it from b_2 * MAC. AoAmax is deprecated in this form. I just left it there because I'm lazy. MAC is the mean aerodynamic chord (I apparently screwed up and this is actually Standard Mean Chord. Oops). This is the average front-to-back distance of the wing. (chord is the distance from an airfoil's leading edge to trailing edge) b_2 is the semi-span. It is the distance from the root of the wing part to the tip of the wing part (remember: full wingspan requires two wing parts here, we're working with only 1) AR is aspect ratio. Calculate it from S^2 / b_2. e is oswald's efficiency. It increases drag. Theoretically varies from 0 - 1, making it zero will result in divide by zero. MidChordSweep is the angle the wing is swept, measured at 50% of the chord. Imagine a line that splits the wing in half, splitting the wingtip chord in half and the wing root chord in half. Measure the angle between that and perpendicular, in degrees. As an example, the delta wing part has a value of 22.5, the swept wing has a value of 10, the wing connector has a value of 0. IsSmallCtrlSurf takes 0, 1, 2 for control surfaces 0 indicates a normal wing part or something like the canards, where it sticks out from the fuselage or the end of a wing. 1 indicates something like the standard control surface which is stuck on the back of a wing. 2 is a bandaid fix for the small control surface part which otherwise would deflect backwards, but does produce the proper forces. maxdeflect is the default deflection amount for a part. 0 for non-control surfaces, anything else for control surfaces. TaperRatio is the ratio of tip chord to root chord. Swept wing has a value of 1, structural wing has value of 0, standard canard has value of 0.3. Pretty self explanatory. I measured a large number of the wing values with the sciency climbing antics of Jeb, Bill and Bob, so they are straight from the game. That in mind, it's easier to set up a non-lifting part than a lifting part, but it isn't that bad.

Version 0.4.1 is up. It extends the drag fix to rocket parts (dV requirements reduced by ~250-500 m/s depending on profile) and adds a first pass of nonlinear supersonic flow. I don't think it justified an increase to v0.5, but this seems to work well enough that I didn't want to delay a release because my imagination isn't up to it right now. For anyone who tries out rocketry with this, keep in mind that drag losses are much lower, so you can pitch over lower in the atmosphere and still reach orbit. Also keep in mind that if you go too fast in the lower atmosphere, you might not have enough thrust vectoring or control surfaces to overcome the tendency of your rocket to point into the wind (too many boosters will make this inevitable). Also, if your rocket starts to tumble too much, it will disintegrate. Just saying. As always, bug reports are welcome. @Mariner: I'm considering it, but not at this moment, especially since I'm not too much of a fan of 0.5m parts (I don't tend to use them too often and find they just clutter my parts folder).

No problem. I takes a bit of practice, you learn bad habits with the default lift model. As an update for anyone interested, I've started doing some more work on the supersonic calculations. Currently it does linearized supersonic theory, which technically isn't valid below Mach ~1.5. I've got a version of non-linear supersonic flow working, which should be more interesting, since it allows very bad things to happen at high angles of attack. I've also set up almost all of the rocket parts with the new drag model and it seems to work quite nicely. Delta-v requirements are down, but since drag was eating too much dV before, I think this is alright. Imagine starting the gravity turn at ~200m rather than 5km. So once those are done I'll probably release a new version. Hopefully I can get some more bugs as well. As always, if you have a bug report, please make it as detailed as possible so I can find the source of the problem quickly. The more detail I get, the faster bugs get fixed (and the faster new updates get released).