ferram4

@Camacha: That makes sense, since there is more math needed to handle transonic and supersonic flight. There's only so much that can be done though, unless I want to drop the accuracy quite a bit for supersonic flight, but I can look into trying. @Dommydoom: Noticed it in the Pwings thread; I'll see what I can do to bring the drag performance of the sailplanes down to where they should be at high speeds, but the lift performance they have is about right, even at those speeds. Realistically, they should just fly apart first, but that's extra code to run to do that.

Put your CoL slightly behind the CoM in order to make sure your plane is stable. The further behind the CoM the CoL is, the more stable your plane will be; conversely, the further in front of the CoM the CoL is, the more unstable the plane will be; putting the CoL on the CoM will make the plane neutrally stable. The more stable your plane is the more control surfaces you need to change its direction, which is why the general rule is to put the CoL just behind the CoM: the plane is stable, but only a few control surfaces are needed to control it. You also want to make sure to put the landing gear directly underneath the CoM; if you don't do that you can have a lot of trouble rotating the plane on the runway to create lift and take off.

Ah, I messed up and didn't bring over the change to the engines for this version; will be in the nest one. Gliders actual have much less drag than supersonic craft below Mach 1, so if the increase in drag from mach effects isn't great enough then the glider-based designs will have an advantage. Realistically, delta wings always make less lift than straight wings, it's just that they have better drag characteristics and are less likely to be ripped off at transonic and supersonic speeds. I'll go and look into fixing that.

@Doomydoom: The FAR problems can basically be explained by "if you have enough thrust you can make anything fly as fast as you want." Really, the problem there isn't that you're managing to get the plane to go that fast, it's that it isn't flying apart as it goes transonic. That can probably be handled with some extra code...

For the stock wing and control surface parts instead of their main module being equal to "Part" they use "Winglet" or "ControlSurface"; is there an easy way to force them over to "Part" instead to prevent the Winglet and ControlSurface code from running at all? Or is what I'm asking for not supported yet? edit: Wait, I think I found what I'm looking for... it's @module = Part. This is what I get for only taking a quick look at the unofficial ModuleManaged FAR.

@Photonically: I think the problem with the CAS window in the VAB is that the class running it is reinitialized every time you load a vehicle or start a new one; it's a class that it loaded every time there's a scene change and I think that loading a vehicle or starting a new one causes that to happen. @asmi: It already does that; the only part that doesn't do that with is the button to open and close it, which I keep meaning to fix.

@Huelander: Okay, the cargo bay bug is due to the fact that FAR currently assumes that the cargo bay starts off closed; I'll have to add some code to detect the starting cargo bay state. The problem is likely that your vehicle isn't perfectly symmetrical. Odds are one of your wings is flexing more than its counterpart and it is causing asymmetric loads; try adding struts to fix this. Odds are that with a plane that big you'll have flexibility-based problems.

@tanihwa: Pwing stuff is currently in Taverius' and DYJ's court right now; hopefully what I've suggested to them works and we can get a working version up soon. @a.g.: I've noticed that weird air intake stuttering bug. I think it's caused by the stock resource system since I've only changed the thrust and Isp of the jet engines to make them make more sense; I haven't change any resource usage code at all. @toadicus: That might be caused by a combination of FAR doing some calculations that it doesn't need to do (for the UI) and the game trying to deal with the planet terrain being loaded and displayed; I've only noticed it at very low altitudes, so I'll look into trying to reduce unnecessary overhead. Just try to be cognizant of the timewarp issue at low altitudes and you'll be fine. @ialdabaoth: I'll confirm that your module FAR version is compatible and then I'll integrate it into FAR proper.

@Huelander: I assume you're using the CoL to check fairings, but the FAR Editor GUI to check cargo bays, correct? If so, then I have confirmed and fixed the bug you're talking about. If not, then that means there is another bug for me to hunt down and fix, so please get back to me ASAP. @Ruedii: On the previous page ialdabaoth mentioned his fix for the currently broken feature; I will look into seeing if it can be implemented in the next / a later version of FAR.

@ialdabaoth: I didn't know about the ModuleManager; I was figuring I was going to have to wait until 0.20.1. Switching the control surface section of the GUI over to what you suggest could be interesting, except I don't know how it would work with regards to the size of the window and how it would work with the stock UI paradigm. I can look into it though.

@anaximander: Try to design your rocket to be something like an oversized, powered dart: lots of weight at the front, lots of fins at the back. Other suggestions include: Keep your TWR lower than 2; this will help keep aerodynamic forces manageable. Start your gravity turn early and gradually, somewhere around 200m - 2km depending on the acceleration each of your stages is capable of; going straight up until 10km and suddenly yanking it over 30 degrees will end badly. Keep your orientation within 5 degrees of your surface prograde vector; too much deviation can cause a loss of control. Build your rocket upwards, not outwards; longer rockets will be more stable than wider rockets as well as suffering less from aerodynamic drag. @SalmonellaDingDong: Make sure that you cleaned out the Plugins folder in the KSP root directory; everything has moved to the GameData folder. You might be accidentally overwriting the new plugin file if you tried to bring FAR v0.9.3.1 over to KSP 0.20.

Alright, version 0.9.4 is out, bringing 0.20 compatibility and bugfixes!

Sorry about the delay guys, I've been carefully going through everything to make sure that I don't break anything with the new folder structure and make sure that FAR uses the new partless-plugin entry method that got added. The new version should be up either late tonight or tomorrow, depending on how many bugs I find that require fixing.

That means that you're using a cargo bay that has its animation defined opposite the way that the code expects. Further, if the wings outside the plane are being shielded when the bay is open that means that something is very wrong with the cargo bay code. Which cargo bay is this, and could you provide a link to the mod so I can check out the problems?

@tanihwa: Aware of that; I believe a.g. found the solution to that and sent me a fixed version which I will look into integrating with FAR. @Gauss H2K: I hope to get some tutorials up eventually, but it isn't high on the list; try looking at the example vehicles and learning from them. @MR4Y: Aware of that oversight. I should get to it soon. @lobsterbark: They should cause the wing to stall in that situation.

@Laphtiya: Okay, that is a very awesome looking shuttle. I think you're right about the first problem; I've had that happen myself when playing around with STS and Buran-style shuttles. An alternative is that your stage-SRBs-and-cut engines routine isn't running fast enough; if that is the case I'd suggest setting SRB separation and toggling all engines to an action group and activate that just before the SRBs burn out. Then all you have to do is activate it again to restart the engines and continue into space. The second problem isn't that your shuttle is unstable; it's actually far too stable! Try putting a pair of control canards just behind the cockpit and see if that helps. Keep in mind that you've got those heavy tanks full of rocket fuel near the back when it's full; where does the CoM end up when they're empty? Also: more paragraphs please. @Itsdavyjones: Since MJ assumes that the stock drag model is in effect, and since FAR sets the effect of the stock drag model to zero (except for parachutes, for now at least) MJ can't predict FAR aerobraking. As a result of the huge amount of variation in drag and lift as a function of the vehicle's orientation with respect to the airflow, velocity and Mach number aerobraking predictions can be very difficult to handle. You can always use KSP's built-in aerobraking calculator called quicksave, try something, and quickload if it doesn't work. @CoriW: That should work, I don't see why it wouldn't. If it doesn't seem to work properly, say something and I'll try and track down the problem. @DYJ: I'm so excited.

@zarakon: It's quite possible that the aerodynamic changes have made it a less effective vehicle. Make sure that it is angled upwards as much as possible before it reaches the end of the runway and allow it to rotate the rest of the way beyond the edge. If you need to make any changes, I'd suggest building some extra trim into the pitch control surfaces.

Okay, version 0.5.3.1 is out, fixing the payload fairing bug, some strange drag errors and setting things up so that DYJ can try to implement FAR compatibility for his procedural wings plugin. (I'm so excited ) @Bluegobln: If you don't actually post pictures of your vehicles, we can't help you out; if you're doing something wrong, we can't give targeted advice, such as "Make your second stage smaller and your first stage bigger; that will let you get higher in the atmosphere before you have a staging event, which means that the aerodynamics of the rocket-minus-first-stage vehicle won't matter as much." On the other hand, if I have screwed up royally somewhere, pictures are the best indication that something is wrong. As an example, Van Disaster's picture that you can't make sense of (and for that matter, I can't make sense of ) indicates that I'm doing something wrong with respect to handling odd mod parts, like Tosh's wheels and truck cab; I will have to try and account for that in a future update, but payload fairings still would have helped. That said, I'd say to ignore "Don't go more than 300 m/s under 10km!" That's more accurate for the stock drag system than FAR's drag model. And keeping the TWR low isn't for "worry-free" ascents, it's for controllable ascents. I've seen rockets with TWR of 3-5 shake themselves apart during launch because of the combination of thrust + deformation + aerodynamic forces. Try this: go to sleep, don't touch KSP until your bad day is over; extra stress from something that should be fun is terrible. When you get back into it, grab the FAR Base in the latest update and launch it; when it starts going ~50 m/s, start the gravity turn. Go full throttle the whole way. Keep it aimed within the prograde marker until you're above 35 km. Try building rockets similar to that example craft and flying them in a similar manner. If you have a problem with a rocket, go into the VAB, turn on the CoM and CoL indicators, post a picture and explain at what altitude, stage and speed things fall apart: transonic effects can make fins less effective, dense air can make aerodynamic forces stronger than control authority and staging can cause an otherwise stable vehicle to become an unstable nightmare. If it tumbles near ~330 m/s, that's transonic effects; you'll need either more control authority or to go slower. If it tumbles high up in the atmosphere, your ascent path is too low / your rocket is unstable after staging; you'll need to either take a taller ascent path or redesign the upper stages. If it tumbles soon after launch, that probably means that your payload is far, far too bulky and unaerodynamic to launch in it's current state; you'll have to redesign it. If you do decide that FAR isn't for you, uninstall it, but feel free to come back and try it again after a few more updates; the aerodynamics can change quite dramatically as I add more effects / adjust current effects to be realistic / simplify things for gameplay purposes. If and when you decide to come back, I and all the other people who use FAR will be more than happy to try to help you out.

@bluegoblin: Allow me to be very mean and ask an obvious question: you install an aerodynamics mod and don't expect to have to make your launch vehicles aerodynamic? Ribbing aside, un-aerodynamic payloads on top of your rocket will make the vehicle unstable; your current design sounds like you're trying to fly a dart into orbit backwards. If you don't want to make your payload aerodynamic you'll need to throw a lot of fins at the base of your rocket to keep in pointing in the right direction. While adding more vectoring rockets might help with the control aspect of your vehicle, they won't help with the stability aspect; the two, while related, are different issues: you can have a controllable rocket or plane that is unstable (constant course corrections to maintain control) or a rocket or plane that is stable, but uncontrollable (think a plane with the CoL way behind the CoM; no amount of control surfaces will get its nose up before it crashes into the ground). I'd suggest trying Taverius's ideas if you haven't already, but I'd also add: Keep your TWR below ~1.5 at launch; this will help keep your speed down in the lower atmosphere, making it easier to maintain control and making it easier to keep delicate payloads / launch vehicles together. If you wouldn't mind posting a picture of your rocket and a quick summary of how you launch to orbit I (or another FAR enthusiast) should be able to critique your design / ascent profile. @NonWonderDog: My inner aerodynamicist is twitching. O_o

@a.g.: Yep, I got it; haven't added it to my version yet.

If you want some more in-depth stuff, I'd say to take a look at this: http://www.desktop.aero/appliedaero/preface/welcome.html It contains math, but will tell you a lot more than wikipedia will. As an update for everyone, the payload fairing bug has been fixed, as well as the attach node bug DauntingFlyer found. The next version should be out as soon as I track down the CoL display bug.

Don't bother changing anything in the nosecone cfgs; you shouldn't need to mess with anything to make it work properly.

@DeathSabre: Okay, thanks for the info; if it is caused by wings overlapping or a silly interaction with struts / fuel lines, that should narrow things down. I think the main problem in the editor is just a visual bug; as for flying, try adding more struts to keep your wings in place and see if that helps. KSP has this weird issue where joints can flex unevenly under equal loads if the joints are oriented in different ways. @taniwha: Any region where Cm * AoA < 0 indicates a stable AoA region for the plane; the situation you're describing basically indicates that the plane is stable until it starts to stall, at which point it becomes unstable. If you're certain that the plane won't be capable of stalling itself, then it shouldn't be a problem. If you want to make sure that it is stable during a stall make sure that your forward wing / canard has a higher aspect ratio than the rearward wing / tail; that will cause the forward surfaces to stall at a lower angle of attack than the rearward ones, making the plane stable. FYI, aspect ratio is equal to the wingspan / wing chord (distance from leading edge to trailing edge). @DauntingFlyer: It's possible I screwed something up during the drag update; I'll check it out. The plugin will properly account for nosecones, the only part.cfgs distributed are for stock parts that need special overrides; nosecones don't require that.

@NonWonderDog: Ah, then something is breaking in the payload fairing code; I'll look into that. The reason that skin friction drag appears to be so much larger than pressure drag is because detecting which part of the payload fairing is the nose cap can be a little bit of a pain to do, so things can go wrong there. @Nobody_1707: Both are probably due to poor rocket design. Control loss is due to the rocket being unstable, which can be fixed by putting fins at the bottom. Exploding due to overheating is probably due to overspeeding, try reducing your TWR and see if that helps. If neither of those work, then blame Deadly Reentry. @Ultraturbopanda: Post a link to the plane so I can check it out. I myself haven't seen this problem occur, so having an example would be very nice to start with. There aren't any known hard conflicts between FAR and other plugins.

Try that again, but bring up the debug log and see if any NullReferenceExceptions are appearing; it's possible that something is simply breaking before a drag force is applied to the fairing. Also, the main problem with your rocket going so fast in the lower atmosphere isn't due to drag forces being too low; it's due to the fact that KSP parts are too strong. That rocket should be torn apart by aerodynamic forces, but it takes much abuse than it should because otherwise it would be too flexible, and there's really nothing I can do to fix that. There's also the fact that KW Rocketry doesn't have the proper AttachNode sizes on its parts, making the drag forces lower than they should be, which would be helping to reduce the drag on the engine for this rocket.