ferram4

I use a modified version of Lifting-Line theory that accounts for low AR and wing sweep; it may not be absolutely perfect, but it's close enough for a game. The only thing it doesn't model is proper 3-D stalling of low AR wings, but I can approximate the effect enough that it is indistinguishable from the real thing.

You need to move your wing back a little bit; it sounds like your vehicle is unstable in pitch once it drains a fair bit of its liquid fuel. Either get rid of that forward canard and use some other method to handle pitch control or shift your main wing further back. This is especially likely since the CoL is right on the CoM; move the CoL a little behind the CoM and that should fix things.

@Climberfx: Yeah, the spoilers are intended for aircraft only, but I can look into making them angle properly for rockets as well. To be honest, I'd but the ASAS down near the bottom of the rocket to make it more rear-heavy when it runs out of fuel. @AndreyATGB: Most real life rockets make it to supersonic speeds (> 300 m/s) before their first staging event; I think the vast majority go well into supersonic speeds before staging. The fact is that it is far more realistic to be going 300 m/s at 10 km up than 150 m/s; yes, it makes things a little bit easier in the dV department, but it makes things a lot harder in the ascent trajectory department.

@mcbaestro: Because lift is directly proportional to density and velocity squared; as a plane's altitude decreases, air density increase and velocity increases (from gravity). This causes lift to increase until it overpowers gravity, lifting the plane higher; then the cycle works in reverse. As long as you have a vehicle being acted on by gravity and aerodynamic forces, phugoid motion will result. It will oscillate a few hundred meters one way or another, but unless you're flying right near the flameout point that shouldn't be a problem. It's the same physical system; it should behave the same. Also, all planes are slightly asymmetric; this is a KSP issue, and I can't fix it at all; it's been documented as a problem stemming from how joints function.

@mcbmaestro: More struts. The problem is that your plane is flexing in an asymmetric manner (and subtly enough that you can't see it) and that is causing the problem. If your plane actually were symmetric there wouldn't be any rolling tendency. There's also the possibility that your vertical stabilizer / rudder isn't exactly straight, which would cause this problem. Holding altitude in a plane is a little difficult to do, especially if you're gaining / losing speed in the process. If you do get a plane to a proper cruise, don't interfere with minor changes in altitude and velocity; that's completely normal. See phugoid motion for more info. As for the BSOD, I don't know what to tell you. It's probably a memory issue, which hopefully will get fixed in 0.20 with their loading system overhaul, but there's really nothing I can do. @Climberfx: That problem is due to the fact that Mac OS doesn't merge folders by default; instead it overwrites them completely. Go and look up how to merge folders on a Mac and then install the plugin using that method. It will work fine.

First, make sure the cockpit you're using has the FARControlSys module attached to it in the part.cfg; if it does and the GUI won't appear, try deleting the file in PluginData/ferramaerospaceresearch and see if the GUI appears.

@localSol: The bug is that without running an aerodynamic analysis (CoL indicator or some other analysis) the stall angle isn't calculated. That's it. I'm just trying to figure out a way to run it that doesn't lag the game while your in the VAB. @DresCroffgrin: That's because Deadly Re-entry is designed for the higher drag of the stock game; you're probably not going to be able to make this work unless you increase the max temperature or reduce the heating effects of Deadly Re-entry (although I don't know if that's possible to do).

@mcbmaestro: The source of the problem is the same in both cases; your plane is asymmetric and the difference in loading on either side causes a slight rolling moment. With stock aerodynamics lift is much, much lower than it should be, which allows MechJeb KILLROT (with it's current system gains) to fix the problem completely; with FAR aerodynamics the loading difference is much larger and and so MechJeb KILLROT would need larger gains in order to fix the problem. Honest question: FAR has a Wing Leveler autopilot built in, accessible through the flight GUI to do exactly what you want; why aren't you using it?

@Nibb31 & Laphtiya: Apparently the section of the FAQ dealing with this got wiped in the forum outage; you don't need to edit the cfgs of fairings or anything else (as long as it isn't a wing) in order to make it work properly. @Taverius: It seems to work fine; I haven't tried too much in the way of experimenting with that stuff, but it appears to perform as it should. Good job, have an aero-cookie.

@Camacha: If you're losing speed while heading downwards that means that your plane brought enough thrust with it to exceed terminal velocity at that altitude; congratulations on your excess. Odds are that whatever planes you've flown in real life haven't had the power to reach terminal velocity on engine thrust alone; that would explain the discrepancy. I think B9 is fairly balanced, though the S2Widebody Intake Adapter is unbalanced until the next release due to the excessive intake drag it makes, but that's balanced in the direction of "too hard" rather than "too easy." There's also the fact that since they are fairly large parts without new, heavier and more powerful jet engines to go with them which makes flight with the pack more difficult.

@Camacha: B9 is completely FAR-compliant; I should know, I'm using it myself. You shouldn't have to do anything to make it work properly. @Percival Meekins: All right, here's some answers: FAR already has some built-in control systems; they won't fly the plane for you but will certainly make your designs easier to fly. Just right-click on it; if it's recognized it should have a flag called "isShielded" visible in the right-click menu. That is used to label whether the part is covered by a cargo bay or a payload fairing, and it happens to be good for telling if the code is running properly. It also tries to identify "heatshield" parts to handle Deadly Reentry properly, as well as "truss" and "plate" parts. All other parts it handles about equally due to some difficulty in determining the shape and properties of some parts. If you're talking about Firespitter helicopter stuff then everything should run properly; your designs might just become unstable if you move to fast. Currently not available; you can get an idea of the overall drag from the Flight Data GUI, though. If they're only "behind" a nosecone or fairing the part can still produce drag. Cargo bay and payload fairings can negate this, if they are set up properly; I believe that most are set up properly. FAR could easily identify those situations if the size of the attachnodes used by parts made any kind of sense; in KSP the attachnode sizes don't always make sense and most modders don't even bother at all. So, no. Radial attachments are considered to be affected by drag unless they are inside a cargo bay or payload fairing. It applies proper drag to other parts, normally assuming that they are cylindrical in cross-section to make things easier. Also, any unused attachnodes (say, on the top of a stack of fuel tanks that doesn't have a nosecone on it) will create extra drag. There's "Help" and "?" buttons throughout the GUIs; clicking on them will give you lots of info about what's being talked about.

@Nobody_1707: I'm gonna take a stab in the dark and guess you're playing on a Mac, right? If that's the case, then the problem you've run into is that the standard "move" command on a Mac is not "move and merge" it's "clear the folder out and then replace its contents with what I've selected." Go and search for "Merge folders on Mac" and you should be able to find some useful help, maybe even a video; it's kind of like us PC folks not knowing that CTRL + SHIFT + ESC directly opens taskmanager.exe. It also isn't too extreme that a single SRB can put a Mk1 pod into orbit without staging; you'd be amazed how much delta-V you can get out of something if you have a small payload and you're tossing a ton of mass out the back. Go and try out using the rocket equation and find out the delta-V for that rocket and I'll bet it's somewhere around ~4 km/s. @Taverius: Hunh, I thought I'd changed that; it's entirely because the airscoop needs to have a different "forward" vector defined in order for the drag values to work out right and I hadn't added that bit to the code yet. I'll look into that. @localSol: Can you cause that again and post the output_log.txt? That will help me confirm whether this is an issue that I've fixed or if it's something different. @Camacha: Yes, but it is difficult and is more difficult than stock aerodynamics + Deadly Re-entry. You're welcome to rip your hair out though.

This is a very awesome mod; thanks for making it. I only have one suggestion: I think that the S2 widebody to narrowbody air intake adapter part should be split up into multiple parts to help bring its performance in-line with the other air intakes. The stock drag model multiplies the part's maximum_drag value by its mass; the stock intakes only include the mass of the intake, while the adapter-intake combo includes the mass of the central adapter section; this leads to the latter having a much larger amount of drag than the former. Thus, I think that the intakes should be separated from the central adapter so that the S2 widebody parts are more useful; currently it's functionally worse than every other stock intake (though much prettier than those) which makes using it somewhat difficult for me to justify.

@mcbmaestro: First, documentation can be found in the Help functions in-game; that will explain what the K values are; they're actually simply gains for the control systems, essentially telling the control system how strongly to react. If the plane is porpoising all over the place with the systems on, reduce the gains so that it doesn't overcompensate. If the control system isn't doing anything, increase the gain. The situation with your SSTO sounds like it has become unstable due to fuel drain; try designing it so that the CoM doesn't move as much when fuel drains. @Nobody_1707: There's no reason it shouldn't work with the Gemini capsule; it works rather well with all part packs. You might want to remove Deadly Reentry, but I know that White Owl was able to bring down spaceplanes with both FAR and Deadly Reentry installed, it's just quite difficult.

@aquilux: I quoted stuff from KerbalSpacePort into the Raycast Drag Thread with my responses. Go find me there and we can argue more. @dlrk: I've always kept my initial pitch within 5 degrees of vertical during launch. As for "proper pitch technique" I'd advise looking up real-life rocket launch information; that should help you out. And as far as terminal velocity goes, I don't worry about it. If you really want to keep your rocket stable during launch I've found that staying well below terminal velocity helps a lot. @SalmonellaDingDong: OK, its still the debris problem. I'll keep working on that. @Glaucus: Remove the plugin dlls and just copy over your current Parts folder with the stock Parts folder; that should remove all of the updated part.cfgs.

I'm already aware of that type of situation, where raycast drag can model the effect of separated, recirculating air diminishing the aerodynamic effectiveness of lifting surfaces. And yes, it is nice to have that effect, to be able to model deep stall, etc. One of the few good things about this aerodynamic model. I really don't think that would work. Not only would this method probably suck on a lot of resources, it doesn't really have any solid basis in aerodynamic theory. Yes, there is the Mach cone in supersonic flow, but that just tells you the region of flow affected by a disturbance in that flow; the only way to use that would be to continue with the current method and then at every impact run another series of raycasts within that cone to see how the effect continues. I'll be honest and say that I'm not exactly certain what you're thinking with this, would you mind elaborating on this idea and citing the aerodynamic theories you're basing it off of? Nope. Think about it: losing any individual part changes the configuration. That means that the number of configurations is huge, being dependent on the number of parts and the vessel hierarchy. It would take a huge amount of time to try and calculate all those effects and then storing them in memory would be a pain; sure, you could drop the data into an external text file to try and save memory but then you'll have a bunch of huge text files to go with each vessel. Oh, and this has been assuming that the vehicle is rigid; once you start accounting for flexing under loading things get worse. Also, waiting 2-4 minutes for each craft might seem like a short time, but how many planes have you built where you needed to make incremental tweaks? Waiting that long to calculate the effect of moving the wings forward a meter will annoy a lot of people, myself included. Nope, I'm drawing a line from a source point in front of the vessel to a point behind it, moving in the opposite direction of its velocity. If I were doing particle tracking it would be a lot worse performance-wise. Also, considering the function I'm using is called Physics.Raycast I think it's raycasting. How do I determine before hand which ray will hit which part of the vehicle? The raycasting is done per vessel, not per part. This is to try and keep things simpler. It does not function on loaded, but not active, vessels. When you launch a rocket and detach those SRBs you slapped on the side this model doesn't apply drag to that debris. Why? It would require even more raycasting with multiple raycast systems being active at once, one for each loaded vessel. That would require either more lag or a reduction in the raycasting resolution. While it is true that that happens in real life at say, an angle of attack of 20 degrees, it doesn't happen at an angle of attack of 2 degrees; that happens with this model if your plane's fuselage is too long. A vertical stabilizer can still be useful at an angle of attack of 10 degrees in real life while with this model in-game the plane will sideslip like crazy.

It does work with KW. I assume that you're doing the standard fly straight up 10km before pitching over to continue your ascent, right? You don't wanna do that. Instead, start pitching over when you reach ~60 m/s and just keep aiming prograde. You'll run a proper gravity turn trajectory (what you've described is not a gravity turn, look up the term if you want more info) and that will allow you to keep more control of your vehicle. If that doesn't help I'd advise adding fins to the bottom of the rocket and /or designing your rocket so you don't have a series-staging event until you're up at about 20 - 25km; that should help it be more stable. If you need more help, post a picture of the rocket and I should be able to help more.

@SalmonellaDingDong: Cause it again and post a copy of the output_log.txt; you can find it in the KSP_Data folder. That will help me track down the source of the error. @dlrk: Well, Kerbal Engineer uses the stock drag model to calculate terminal velocity; it doesn't know how to deal with FAR at all. Previous to the forum reset there was some discussion about whether setting up a system to allow FAR data to be accessible to Kerbal Engineer would be worthwhile, and the resulting conclusion was that it would result in too many dependencies and instabilities in the plugins, at least for now.

Yeah, sure. Just look at the code for the stock pods; when you installed FAR those should have been overwritten with the proper data.

Currently it only has the windows appear on command pods that have the FARControlSys module defined in their part.cfg. Check to make sure that the command module you're using has that defined in the part.cfg; then it should work.

@Van Disaster: They would still work, but some of the interactions might not be properly accounted for. You might not get as much lift as you wanted, for example. @SalmonellaDingDong: Well, I think it makes things more fun, as do many other users of this mod. The increase in realism means that you can use lessons from real life aerodynamics to build your vehicles; if you build a plane that looks like a Boeing 747, it'll probably fly like a 747. There's also the fact that for a properly streamlined vehicle you can actually reach some pretty fast speeds in the lower atmosphere (like you should be able to do). As for whether it makes things too hard there are (IMO) three attitudes on this: 1. The need to consider aerodynamics when building rockets makes it too hard; these people have rockets tumble and spin out during launch because of poor design. 2. The reduced drag due to proper aerodynamics makes it too easy to reach orbit; these people complain that they aren't losing as much delta-V to drag as they're used. 3. The need to consider aerodynamics combined with the reduced drag for streamlined vehicles adds new design constraints to launching a certain payload into orbit; whether it is harder or easier depends on the mission.

@cardgame: That could simply be the result of overspeeding; post a video soon, it should be helpful. My response to the other problem is fairly snarky: So when you decide to break physics you end up with behavior that breaks physics? The fact is that when you start engaging in serious part clipping the FAR code (which makes the assumption that you aren't clipping parts) can get fairly messed up. Also, the control surfaces shouldn't be activating by themselves; it's possible that you left one of the autopilots on and that it did something unexpected during take-off. @Camacha: That looks good, though hopefully the latest release of FAR should remove the need to do that. @Van Disaster: Normally flap deployment causes the plane to have to be re-trimmed. This is why flaps get deployed well before the final approach to landing, so that the pilot has time to balance it. This is a normal problem in airplane design and is one of the things that needs to be accounted for in the design. @Noc: If you mean adding lift modules like the wings have, then no, that won't work well. Instead you would be better off modifying the Cl curve for the standard drag model; most of those numbers are taken from real-world data. You might want to look at the command pods, since it includes the non-wing modules explicitly stated for those. @xau: Known issue; will be fixed in the next release.

Try getting rid of the docking port on the plane, since you shouldn't need it. Make sure that the main landing gear is directly underneath the CoM so that it can rotate on the runway. Make sure that the control surfaces are as far forward / backward as possible. It's possible that adding the remotetech stuff to the plane is overloading the landing gear a bit. Try using struts to keep them straight up; when the gear starts wobbling bad things can happen.

Try extending the central line of tanks in the fuselage back a little bit and put a larger vertical tail back their; that should help with any yawing tendencies. Then I'd go and get rid of most of those control surfaces; the code they use creates thrust when they are deflected, which could make flying more difficult. You actually don't need too many control surfaces to maneuver a plane, you just need to make sure that the CoL is very close (but just behind) the CoM. This should also help with the Avionics freak-out, since fewer control surfaces should help reduce the effect of SAS overcompensation. Finally, I'd try flying the plane without SAS activated; if you can't fly it without SAS, you need to make it more stable. Use the trim function (ALT + WASDQE) to balance the plane instead and try flying it manually, since it will be easier to land the plane manually than hoping that the autopilot works.

@Dragon01: Having a different system in place for airplanes would be incredibly wrong; physics shouldn't change based on what category your vehicle is in. @CAPFlyer: I'll see what I can do; I suspect most of the problems can simply be fixed by giving the FAR code a good once-over to fix everything. @Taverius: That only happens at very, very high angles of attack and normally isn't a problem. The main reasons why fighters have twin stabilizers nowadays are: 1. The rudder needs to be able to counteract the yaw moment created by having the maximum amount of unequal thrust between the engines, that is, one engine at maximum takeoff thrust while the other is shutdown. Often weight savings can come from using two smaller rudders for the job. 2. Angling the stabilizers outwards (as it is on almost all modern fighters, see F-18, F-22, F-35) can reduce the radar cross-section of the plane. The main problem is that this model is fundamentally inaccurate for anything other than approximating the case of Mach number and velocity going to infinity.