ferram4

The first thing I'd try is flipping the craft on its side in the SPH to help see the yaw characteristics of the vehicle; the default orientation of the vehicle will only show if it is stable in pitch, while flipping it on its side will allow you to see if it is stable in yaw (same principles as before, CoL should be behind CoM). Another possibility is that the CoL indicator isn't correct. The CoL indicator isn't affected by the placement of non-wing parts, such as intakes, even though the true CoL is affected by the drag characteristics of those parts. Since the drag of a part is based on its mass * maximum_drag (where maximum drag is almost universally 0.2), the drag characteristics of most parts is complete cancelled out; if you have lots of high maximum_drag parts at the front and low maximum_drag parts at the back, that could be an issue. The final thing I can think of is that your cargo bay doors might be subtly deforming under the lifting forces applied to it; if it doesn't warp symmetrically (note: it will never warp symmetrically) it could cause phantom-like forces to be applied to your craft. I understand that you'd prefer not to strut the doors down so that they can open properly, but if strutting them in place fixes your problem then you know you'll need to redesign that part of the vehicle. Keep in mind that parts on the same craft do not calculate collision, so this might be more of an issue than you think. Otherwise, nice design; probably needs more vertical tail to look right though.

@TomatoSoup: Honestly, the only way that I would add that feature is if I were able to add it to the cheat menu, as I consider it to be similar to the "hack gravity" switch in there. FAR is primarily based around trying to make the game as realistic as possible, and allowing the player to simply flip the drag model on and off (or the type of drag model) that easily defeats the purpose. I'd say that the best way to go about aerobraking is to quicksave and just try something. Have the ship spin a bit as it goes into the atmosphere to help make it more stable and see what happens. Don't like the result? Call it a "simulation" run and quickload, try again.

@Senshi: Could you post a copy of the output_log.txt? It might be something going wrong during the initial setup of the drag model. What mod parts are on that craft?

@AtilaElari: What exactly are you trying to bring down? A command pod alone? That wouldn't be FAR breaking that. A complex lander? Not much you can do besides using more struts and taking a more shallow angle. I'm still concerned that if your rocket has parts being destroyed "due to overheating" as you mentioned in your earlier post that you haven't fully uninstalled Deadly Reentry and that that is the cause of most of your problems. @uselessengineer: Unfortunately, no. You do have the option of going through the debug log and adding up all of the areas printed out when FAR's modules are initialized. I did just make a change to the current build to support that, so when there are enough changes to justify another release of the old version of FAR, I'll put that out.

@theflyingfish: You have no idea just how much I would love something like that. I believe there was a mod, KIS Connect (IIRC) that essentially removed the flexing between parts (so not exactly what we'd want, but close), but that was several KSP versions ago. I believe (read: my personal speculation) the issue with this is the way that parts are connected, using a combination of a linear spring and a torsional spring; this results in equal and opposite forces being applied to each part when they are under load, but the differing masses of the parts leads to unequal acceleration between each part, causing extreme flexing between parts of very different masses. The problem is trying to find a different way of handling joints that is computationally cheap, removes the flexing problem, and conserves of momentum. @AtilaElari: I gather you're taking a spaceplane in with virtually zero angle of attack (lowest drag situation), correct? Try repeating it with your spaceplane holding 30-40 degrees angle of attack throughout the entire thing like the real space shuttle did; if it can't achieve that, it needs a redesign. From your second post, it sounds like you didn't actually delete Deadly Reentry properly. @5parrowhawk: You need those canards to be further forward. My suggestion would be to put a liquid-fuel-only fuel tank in between the cockpit and the rest of the ship and use the extra length to put the canards further forward. Adding small control surfaces to the back of your wings (right by the jet engines) and setting those to add pitch authority should help a bit; angling them to produce a slight pitch-up tendency at no pitch input is also probably a good idea. There's also the possibility that the canards are interfering with each other / the wings and producing less lift than you expect in their current position, so you may not need two sets of canards if you make the plane longer.

@ozligia: The difference is the simple difference between the slope and y-intercept of a line. You're concerned with the pitching moment (yellow line) of the aircraft, which is (for the most part) a simple linear equation. y = Cmα*x + Cm0 y = pitching moment x = angle of attack Cmα = pitching moment slope Cm0 = zero angle of attack offset Now, the location of the CoL relative to the CoM is related to the slope of the line, Cmα: (CoL location - CoM location) ∠Cmα This controls the stability of the plane, and it needs to be negative for the plane to be stable; this corresponds to the plane trying to stay at some given angle of attack, which is controlled by the next section, the y-intercept, Cm0. That value is a little more complicated, but negative lift behind the CoM increases Cm0, positive lift in front of the CoM increases Cm0, positive wing camber (which you have in your design) decreases Cm0, pitch-up inputs increase Cm0. You can read it off of where the yellow line crosses the vertical axis, which for your design is negative; this means that your plane is going to try to pitch downwards if it is at zero angle of attack. Ideally, Cm0 is positive, which causes the plane to naturally hold a small positive angle of attack without any control inputs; if Cm0 is 0, then the plane is essentially just a lawn dart until a pitch-up input is added to keep in on course. The long story short is that your plane wants to start pitching downwards due to the camber on the only lifting surface; the plane's pitch instability causes it to be even less stable. Adding a small tail at the back with a negative angle of attack should take care of all your problems.

@Imagine: Can you post a copy of your output_log.txt? Also, what other mods are you using? The way the drag coefficient blows up looks like a bug, but I don't know (off the top of my head) what could be causing it. If you have any spoilers on your spaceplane, try removing them and see what happens.

The flight GUI should load whenever you enter the flight scene using a controllable vessel, though currently remotetech control parts can cause some issues with that. The editor GUI will load whenever you pick your first part for a new craft.

The extra zeroes specify the slope of the curve at that point; the first specifies the slope coming from the left, the other specifies it coming from the right. This can be used to specify the curve more exactly with fewer inputs. The velocity curve also does not impact fuel consumption at all, only thrust. The fuel consumption is calculated using the rated thrust of the engine (max thrust at full throttle, min thrust at throttle off, linear interpolation in between), not the final thrust once it has been affected by the velocity curve. For the TurboFan code that you posted, at 2000 m/s it produces half of its rated thrust, while its fuel consumption assumes that it is producing its full rated thrust; basically, its true Isp gets cut in half while the indicated Isp stays where it is.

Alright, here are the many problems: You don't have a separate horizontal tail / forward canard for pitch control and stability; this means that any pitching motion on your plane will take a long time to damp out, as well as making its stall characteristics worse. It would probably also benefit from having the wings swept a bit to reduce drag at low angles of attack and at high Mach numbers. If fuel is draining from the central tank to the outboard tanks then it will also become less stable as the CoM moves backwards; I don't think you actually need that much fuel for the jets alone either. It would probably benefit from a slightly larger vertical tail as well. I'd also get rid of the engine nacelles entirely, since they are incredibly inefficient weight-wise, intake-wise and drag-wise; they're just bad to have in general and they are likely making your plane less stable.

Possible problems: CoM movement rearward causes loss of pitch stability. Lack of dynamic pressure due to excessive climb rate causes engine flameout, initiating flat spin. Lack of dynamic pressure due to excessive climb rate causes loss of lift; pilot compensates with increased angle of attack, causing stall. Plane is only marginally stable at low supersonic speeds; acceleration to hypersonic velocities causes loss of stability. Stalling decreases stability of aircraft. These might help, but pictures will help narrow down the problems. Edit: It also has MechJeb, Kerbal Engineer, and probably a bunch of other mods that I don't have installed; this is why I tend to ask for pictures, not the craft itself. Diagnosis will have to wait for a bit.

I'm gonna go and do some general guessing trying to come up with the dV to get to orbit from Eve's surface, though don't trust my numbers too much. Based off of the numbers on the wiki, for a circular orbit at 100km (just above the upper reaches of Eve's atmosphere) you need to be going 3196 m/s. Then we need to think about gravity losses; getting off of Kerbin and getting up to 70km incurs a 1000 m/s gravity loss; Eve's surface gravity is 1.6g and we have to go higher, so let's guess ~1800 m/s lost to gravity. Now we deal with drag losses. On Kerbin, this is somewhere between 50 - 500 m/s, depending on the vehicle design. On Eve, we'd have to go faster to get to orbit, spend more time in the atmosphere, and the atmosphere is 5 times thicker. So let's guess 5 times the drag losses, so 250 - 2500 m/s. So all of this guesstimating leaves us with ~5250 - 7500 m/s to orbit. That's a pretty big range, all things considered, but it's not that bad, especially since the last 2000 m/s can be handled with a nuclear engine and drop tanks. So I'd first try dropping a small probe there with a launch system with 7500 m/s atmospheric and an Eve TWR of 1.5 and see if it can get to orbit. Based on that, you have the data for your manned mission. Keep in mind that you will have to try and design a vehicle that will be able to remain stable during reentry but will be stable during the return flight as well; I would advise adding some type of aerodynamic extensions to the bottom and top of the rocket to try and invert its stability characteristics for the initial landing and jettison them just prior to touchdown.

There are two effects being simulated here; one is the shift in aerodynamic center* (center of lift) that Van Disaster mentioned and the other is the change in the effect that an airfoil's camber has on its lift. Let me try to explain with these wonderful MS Paint diagrams I whipped up. The first is pretty simple to visualize; take a cross-section of the wing and look at it from the side, it would look something like this: Where the green dot is where the location of the wing's AC at subsonic speeds while the red dot is the location of the wing's AC at supersonic speeds, assuming the airflow comes from the left. This effect happens to some extent with all aerodynamic shapes, causing objects to become slightly more statically stable at supersonic speeds. The second effect can be explained this way; for a wing, lift is determined as a contribution of camber effects and angle of attack effects; camber is just how "curved" the wing is compared to the airflow, while the angle of attack is the angle between the airfoil reference line and the incoming air; more camber and more angle of attack cause greater lift if stalling doesn't occur. The image below draws the reference lines and profiles for an airfoil with and without flaps deflected: What the image shows is that an increase in control surface deflection increases the camber and the effective angle of attack of the wing, both which increase lift. However, camber only produces lift at subsonic speeds; it is entirely dependent on the airflow at the trailing edge of the wing being able to affect the airflow at the leading edge of the wing. Once in supersonic flow the only way changes in lift can be achieved is through increases in the angle of attack of the wing; camber will only increase drag. This would be the result of any roll controls feeling sluggish at high speeds, since they're less effective at Mach > 1 than at Mach < 1. This is also why supersonic planes fare better with all-moving tailplanes / canards than tails with separate elevators. The thing to take away from this is that your plane is becoming more statically stable in both pitch and yaw and that your wings and control surfaces stop being effective at lifting when you switch from subsonic to supersonic flight. You will have to either make your plane less statically stable to handle this and/or you will have to use more control surfaces to give you greater control authority. If you want to learn more, just try searching for "supersonic flow" or "transonic flow" on Google and you should find a bunch of relevant stuff. *I dislike the term "Center of Lift" because it seems to imply that the only aerodynamic force that needs to be accounted for in determining stability is lift; it also seems to imply that there is a separate "Center of Drag" that would be located somewhere else on the craft, confusing otherwise intelligent people by giving them something else to worry about / try to calculate when there is no need to do so. Aerodynamic center lacks those implications / problems.

There already is a button that ramps down to 1x timewarp. Go to the top left where the timewarp icons are and click on the one furthest to the left and watch as you suddenly slow down to real-time from accelerated time. All timewarp options can be selected by clicking on the proper acceleration arrow. It's one of those features that most people aren't aware of. I don't know how a "stop time" button would work out; if it functioned in-atmosphere it would remove some of the urgency of trying to figure out how to get Kerbals to survive an out-of-control craft, while out-of-atmosphere functionality doesn't seem justified since there is (usually) plenty of time to plan while in orbit.

@Van Disaster: Putting the spoiler in front of the entire wing won't cause the entire thing to stall, unfortunately. @oggylt: The readme file in the zip has a fairly extensive changelog. If you want more detailed change info, you'd probably be better off just reading up on aerodynamic theory and that will tell you most of what has been implemented.

@KerbMav: Then the rolling problem is not due to the CoL being offset, but instead due to unequal connection strengths for parts attached with symmetry; basically, one wing will flex more than the other for unknown reasons. Use more struts to fix it. FAR also handles all atmospheres equally, grabbing the atmospheric density for calculating dynamic pressure and atmospheric temperature for calculating Mach number (Jool has a special adjustment since its temperature scale drops below absolute zero, which causes Mach number to go NaN if allowed through). FAR does not change the characteristics of any planet's atmosphere; it only changes the aerodynamic characteristics of parts. @ola: In the current version of FAR canards do not affect the aerodynamics of the main wing in a fully realistic manner. You don't have to worry about any of the concerns you've listed.

@KerbMav: Try getting rid of all of a specific wing type (like, say, the delta wing part, or the standard control surface) and see if that changes things. Also check the vertical tails to make sure they're exactly straight, since that has been a source of that bug. @amo28: The fuel burned has pushed the CoM behind the CoL; both of your spaceplanes have become unstable due to CoM movement caused by the large amount of fuel being burned. You will need to redesign them in order to make them stable. @Blatter: Not supported, sadly. I don't believe it is possible for me to change that.

@loknar: Make sure that ModuleManager is in the right directory and that you don't have any extra copies of the dll floating around in your GameData folder and its subfolders. Make all your hidden folders visible and make sure that nothing is floating around in there that shouldn't be their (I have no idea why that would happen, but it's a possibility). @paju1986: I'll add that in if another revision is necessary, but I make no guarantees about that happening soon. @KerbMav: It's a bug; it should have no affect on the behavior of your vehicle.

@m4ti140: Noted. That problem will actually be a bit harder to fix in the current FAR code, since trying to add the "lift" effect from that blunt side of the capsule ends up being more difficult to do than you might think without causing the capsule to become unstable. @loknar: That makes no sense; FAR hasn't touched the part.cfgs directly since before version 0.9.5, which was from before KSP 0.21.0. It never even touched the PodCockpit folder, since that is an internal space and FAR doesn't mess with that at all. You'll probably just have to repair your KSP install or reinstall it wholesale to fix it. Make sure that you're using the latest version of KSP and FAR, and that you're not placing KSP somewhere where it will have permissions problems. Other than that, I can't help you; the last time FAR caused this error was when it still manually changed part.cfg files and it hasn't done that in several versions.

Alright, the 0.9.6.2 revision is out, fixing the isShielded bug and the problems with my attempted fixes to Firespitter compatibility. Everything should function properly now; sorry about the bugs guys. Give a big thanks to a.g., who is apparently better at bugfixing my code than I am.

@asmi: That is essentially what I'm planning for the code rewrite; the problem is that if the object has a concave cross-section things get kind of messy. The only reason that the current versions of FAR use part-based calculations is that it's much, much simpler to code than that type of method. Basically I'm going to end up trying to group parts in "wing" sections and "body" sections, which will then be analyzed to get aerodynamic properties. Currently I'm trying to get the geometric properties of the "body" groups, the most important of which is cross-sectional area as a function of axial distance along the body; with that function the drag and lift properties can be fairly easily determined for all Mach numbers, but getting that distribution is difficult.

Okay, the 0.9.6.1 revision is out, fixing some incompatibilities with B9 aerospace and Firespitter, improving the Flight GUI (slightly) with a.g.'s quick buttons, fixing another cargo bay / fairing issue and some moment of inertia issues. CoL issue continues to exist, unfortunately.

@NathanKell: I haven't looked at the craft you posted yet, I've been focusing a bit more on planning for future FAR versions; apparently calculating the cross-sectional area / area enclosed by a group of meshes at any point is a little more difficult than I thought it would be. I've never seen procedural fairings fail that badly; try seeing if using launch clamps on the rocket fixes it, since FAR updates the components in fairings and cargo bays when the ship adds or loses parts. @luckyhendrix: You need a larger vertical tail; that thing is too tiny for your purposes here. What's actually happening is that your plane is sideslipping a little bit; this causes one wing to have a greater amount of sweep than the other. A wing with less sweep will make more lift and less drag at the same angle of attack, so the sideslip causes a rolling moment (which is what you're noticing) and a yawing moment that causes the problem. This isn't a lack of roll stability, it's a consequence of a lack of yaw stability. @Torminator: That looks very similar to the problem that plagues the B9 intakes in the current implementation of FAR. Try it again when the revision comes out.

@camlost: The current implementation already accounts for camber (that being what you build into the wings) and airfoil thickness is already assumed to be there; all the wings would stall at very low AoA and make very little lift if they were considered to be flat plates. The new implementation should account for it, but a little bit better. The lifting body stuff that I've added will be easier to add in the new implementation, since it's easier to account for the entire body rather than try to divide the effects among many parts. Leading edge flaps are already handled properly; they should help increase the stall AoA while causing a slight reduction in lift at all AoA, resulting in a higher maximum lift coefficient. @theflyingfish: Look at Taverius' old TV Aerospace pack; I think you'll have to update it to work with the current part implementation, but it will give you what you want. It should be possible to make the CoL and CoM appear in flight, though I'll admit I have no idea how to make that happen. I can look at the RCS build aid plugin that Torminator is using and see if that gives me any info about making that stuff appear in flight, but no promises about it coming soon.

The code rewrite is for a couple of reasons. The first is that I think there are a great number of inefficient parts of the current FAR code that could be removed if it was rebuilt from the ground up. The second is the I have a better understanding of how C# works and how the code works with KSP, so rebuilding the code with that in mind will allow for greater efficiency. The third is that I want to switch from a part-based aerodynamic model to one that groups parts into bodies and wings and determines the aerodynamics of the aggregate instead, which should allow me to implement more features (like proper induced velocities, some multithreading and more real-life accurate simulations) while keeping the CPU workload down. Basically, the idea is that if you have a 200-part plane, with a central fuselage, a wing, horizontal and vertical tail, FAR will only have to do the heavy math on 6 aerodynamic objects (fuselage, each half of the wing, each half of the horizontal tail, and the vertical tail) and then that will be put into temporary look-up tables used by the correct parts so that FAR doesn't cause as much physics-based lag. I also think that the analysis for the look-up tables can be done in a separate thread so that it doesn't cause any lag at all. The guide is probably going to come with the new version, since I'll have a good opportunity to write it as I code so that everything is clear as day. A revision is on the way for some bugs and should be out soonTM.