ferram4

You have a ton of wings at the front of the rocket, which puts the center of lift of the entire vehicle well in front of the center of mass; if it didn't flip out like mad I'd be surprised. You'd need a lot more fins at the bottom than you currently have to keep that from flipping. Considering how far in front of the center of mass the glider is, you might not be able to get the center of lift behind the center of mass without a radical redesign of the vehicle. If you use FAR, placing a payload fairing around that glider will help reduce the stability problems you're having, since that will prevent the wings from producing any lift. I have to assume that your statements about the CoM, CoT and CoL only apply to the glider itself; if you're talking about the entire rocket, then something is very, very wrong somewhere.

@Volt: The best way to fix that is to manually add a FARBasicDragModel to the part.cfg. I'd probably go with something like this: MODULE { name = FARBasicDragModel S = 1 CdCurve { key = 1 0.05 0 0 key = 0 0.3 0 0 key = -1 0.05 0 0 } ClCurve { key = 1 0 0 0 key = 0.5 0.05 key = 0 0. 0 0 key = -0.5 -0.05 key = -1 0 0 0 } CmCurve { key = 1 0 0 0 key = -1 0 0 0 } CenterOfDrag = 0 -0.05 0 } The CdCurve and ClCurve are probably decent for a projectile, the CmCurve is zeroed and the CenterOfDrag is set slightly behind the part's center of mass. You can try adjusting that to make it function better, but this will allow you to fix it without waiting for one of my updates. Realistically, the projectile is doing exactly what it should, but it needs a rifled barrel. Coding an extension of the decoupler logic to add a twisting moment on launch would fix it completely, which is probably a smarter thing to try. @a.g.: Your suggestions were close, but not exactly right. I spent some time re-deriving the math and used that instead, but thank you for the help. It seems to work properly now.

Fine, that works then. But what prevents someone from strutting the fairing to hell to prevent it from failing and physics suddenly being enabled on the payload? Why would two payloads, with the same sizes, have different masses? And if we did this, if there are fuel tanks in there do we base the fairing mass on the full mass or empty mass? Either the fairing would allow you to launch that flimsy payload without the huge girder mess, at which my "inconsistency" complaint still stands, or it would break, at which point we're back to where we are now.

@birrhan: If you're able to get it in orbit despite spinning, I gather that you're talking about spinning along the long axis of the rocket; that wouldn't be caused by anything in FAR, but by some type of asymmetry in your design, probably due to a part that is at some type of an angle that it shouldn't be. If you're using any couplers or have a large number of parallel boosters, you should look into struting those parts better and see if the problem reoccurs. Also, your ascent profile is terrible. Start turning earlier and go faster and you'll be able to use a smaller rocket. @a.g.: I've just added some code to my build to see if I can fix that. @luckyhendrix: Your CoL is just above the CoM and slightly in front of it; it's supposed to be behind it. Basically, as soon as any stalling begins to happen (which looks like it will happen at very low angles with those high aspect ratio wings) your plane will start having stability problems. Try getting rid of the extensions on the front wing and see if that helps.

This is what I'm talking about as well, however, based on what I've seen presented here, this idea would allow that payload to take an infinite amount of load. How would it handle when a player creates a monstrosity with a TWR of 20? Will it crush under its own weight, (with nothing above it, only its own mass) or will it manage to survive regardless of how flimsy it happens to be? Further, with this idea, what benefit is there to keeping any part of the rocket outside of a fairing? Wouldn't it make the most sense for my rocket to consist of successive fairing layers, like a Matryoshka doll? Even if there is some manner of structural failure checking, the removal of wobbling inside the fairing will allow flimsy rockets to launch that would tear themselves apart if they weren't encased in a fairing. The problem is not perfect simulation vs. approximation; the problem is (what I perceive to be) inconsistent physical laws inside and outside the fairing. Inconsistency in a game is a recipe for player confusion and frustration ("Why would that even matter?" "It doesn't make sense that it would break if there wasn't a fairing there; everything else was the same!").

Well, then a PDF; that good for everyone? It may take some time to get the file together, but I'll distribute it with the next update (hopefully).

First, pictures please, since those can help explain several issues. If your control surfaces aren't responding properly to control inputs make sure that the control surfaces are set properly and that the craft is saved, and then attempt to fly it. See if the control surfaces deflect instantly in flight or if they take time to fully deflect; this will indicate whether the appropriate part module has been applied to the part. If it hasn't then there is likely a problem with ModuleManager; post a copy of your output_log so I can see if any errors got thrown in it (only posting a snippet doesn't necessarily help me, since that snippet might not include all the relevant data).

The first thing I'd check is that you have struts between the wings and the body; wings do not necessarily bend the same amount and that could cause your rolling tendency. The second thing I'd check is right-clicking on each of the wing parts once the flight scene has loaded to make sure that the cargo bays are not accidentally "shielding" them from the airflow; this has been a problem in the past, and though I believe I've solved it, the bug may still exist. Besides that, I'd suggest placing your engines underneath the wings rather than above them (you have to fight the pitch-down moment from the engines on top of the wings currently, which will require more pitch control surface deflection, creating more drag). I'd also tilt the vertical stabilizers less, since they're not being as effective as they could be (in the configuration they're in they also make the plane less stable in roll; if they were angled outward they would make it more stable in roll). A guide is planned, but first a question to FAR users: is a .docx file good? I'd like to include graphs and illustrations with a guide and that filetype is my go-to for that kind of situation.

A single point of attachment isn't realistic, but sufficiently strong struts add multiple points of attachment for any payload. Besides that, the main difficulty isn't that there is only one attachment point, but that those points are too flexible, which is a different problem entirely. While all of that is true, the Lunar Module still had to be able to handle the forces and impulses applied to it; it might not have had to hold up the command and service modules, but it did have to handle 4gs and had to withstand the sudden jerk from the S-IC engines cutting out. Psycix's proposal wouldn't even require it to withstand that. Or, to make the issue more obvious (and properly absurd), if you were to take a Lunar Module and fit one of these magic anti-physics fairings around it, and then placed that on top of instant-detonation explosives (or perhaps a ton of high-ejection force decouplers) that could create an instant 100g force, the Lunar Module would survive. Removing the fairings would prevent the Lunar Module from surviving. Even if there were millions of attachment points between the "launcher" and the payload the payload should still be crushed; Psycix's idea prevents that from occurring, which makes me very wary of it.

@SyX: If the center of another fuel tank object isn't above the CoM, then the CoM should gradually move upwards and my first suggestion doesn't actually get at the problem. You should post pictures so that we have something more to go off of than guesses.

@SyX: I'm thinking about making some kind of illustrated guide for the concepts, mostly because graphs and examples help people more than words. I want to make sure that FAR is very accurate before I do that, since inaccurate images would be far worse than they are now. A picture of your rocket would help, but here are my ideas: Your rocket is becoming unstable as fuel drains; this is more of a problem for squat rockets or ones in which the first stage extends to above the CoM. The solution is to make the rocket taller / use a heavier payload to shift the CoM further forward / add more fins. Your rocket has a very high TWR and is getting up to very high speeds low in the atmosphere. The solution is to use a smaller engine, larger payload or throttle control to keep your velocity lower; as Mach number increases above 1, vehicles steadily become less stable. You are staging while going at high speed low in the atmosphere and your upper stage / core rocket without boosters is not as stable as the complete configuration was. The solution is to push more of the rocket into the first stage or to independently design the upper stage / core to be aerodynamically stable. Posting pictures of the rocket would be helpful, since then we can give you more specific advice, unless there's a bug in the code, in which case I find out about it and can try to get a fix into the next release.

I've been looking at adding multithreading in some form, but I've been somewhat reluctant, mostly because I haven't messed with parallel processing before. Odds are some form will come eventuallyTM but I want to make sure that I have a very robust single threaded version of FAR first, this way any new bugs can be relied on to be caused entirely by the multithreading implementation.

@loknar: I'd probably have to try and find out as much as I can from the devs about what aerodynamics have changed so I can see if it's possible for me to add any improvements to that system. Odds are that I'd switch from being focused on trying to balance the competing aspects of realism, gameplay and computational load and switch towards as much realism as possible. It wouldn't necessarily be for most of the current FAR users at that point, but for the people who say that they need even more realism, they'd get what they want.

@jrandom: Canards at the extreme front and back would be enough if you keep the CoL very, very close to the CoM. Keep in mind that if you want your vehicle to have good supersonic stability and control you should design it to be only slightly stable at subsonic speeds. I would suggest reducing the max deflection of your forward canard as well; at large angles of attack at low supersonic Mach numbers the wings might not make as much lift as you would hope, but will create large amounts of drag due to the shocks detaching from the leading edge of the wing and sitting as a bow shock in front of it. Reducing the max deflection will allow you to make full use of your rearward pitch control surfaces without detrimental effects on the forward ones. @LMA: What it sounds like happened was that MechJeb decided to start the "gravity turn"* with its characteristic "grace" and the sudden change in the rocket's angle of attack caused it to become slightly aerodynamically unstable. You'll probably want a lower TWR, an earlier start to the "gravity turn" and a less dramatic switch from vertical flight to "gravity turn." *Quote marks used to take note of the fact that MechJeb does not fly an actual gravity turn trajectory; that would be pointing the rocket towards surface-prograde the entire launch and is chosen due to it being the optimal launch trajectory with respect to dV when there is not atmosphere and the optimal trajectory with respect to reducing lateral aerodynamic forces in an atmosphere. @NathanKell: I've tended towards starting at about 60 m/s, but it really depends on how severe the initial pitch over maneuver is as well as the launch TWR. TWRs higher than ~2 you have to start pitching over right at launch and any higher and you might as well just start the rocket angled 5 degrees or so on the pad.

That is partly because supersonic flow is weird and partly because I don't have too much data for that flight regime. Assuming that there aren't any viscous effects in the flow, the airflow should be able to stick to the wing up to ~50 degrees angle of attack at Mach 5.5. I haven't attempted to add any "supersonic viscous stall" function since I haven't been able to dig up any papers on variation of stall angle and stall severity at supersonic speeds. I'd prefer not to add something that has no basis in reality just because I look at what's already modeled and say, "that seems wrong," especially since this is supersonic flow, where fluids behave a lot differently than at the subsonic speeds we're used to.

@wased89: If the drag is being influenced by mass, then FAR isn't installed properly. With FAR installed, drag will be completely independent of the actual mass of the vehicle and will only be dependent on the vehicle geometry. @GrizzlyJones: I don't believe that it would be possible to set up the control surface assignment code with the stock aerodynamics. I'd have to either try to extend the ControlSurface class to replace the stock control input algorithm with mine or I would have to rebuild the class completely and try to recode whatever wonky algorithm they're using for lift. Honestly, neither of those options are very appealing to me, particularly because I wouldn't make any use of the code myself. @NathanKell: I guess I can add that to the next release... I'll see what I can do. @Weatherman159: People complained when liquid engines got nerfed during the initial introduction of part modules; they originally got something like 500 Isp regardless of atmospheric pressure. Now no one complains about the ~350 Isp engines. People will complain when reentry heat is added, because they won't be able to be as careless with aerobraking and reentry as they are now. They will complain when life support requirements are added. They will complain when maximum g-forces for Kerbals and (possibly) parts are added. They will complain about the inevitable change in the fuel required for the NTR, when they won't be able to run it off of the same fuel mixture as a mainsail. They will complain when intakes are recoded so that intake spamming can't be done anymore. Just as they will complain about these changes, they will complain about the addition of proper aerodynamics. All of these complaints will stem from one place: the introduction of constraints. KSP is a sandbox, and as players, we don't like feeling like we're being told what to do in our sandbox and the introduction of a new constraint feels like that. Of course, no one complains about the already existing constraints; we're barely aware they exist. We easily forget that the game already places constraints on what we can do through the behavior of gravity, the existence of atmospheres, where parts are spawned and how the physics simulation runs. Within a week after those new features are added the complaints will stop as the focus turns to designing a way around the problem, just as we do now. People will adapt and learning to design aerodynamic rockets will be part of the things that a player must learn, just as they must learn how to design staging properly, how to reinforce their rockets with struts, how to keep their vehicle powered in space and orbital maneuvers. And then, in the next update or so, people will look back fondly on the time when they didn't need to worry about whether their rocket would do backflips during launch, just as we look back at the time when Kerbin's atmosphere was a constant density shell that ended at ~35km and when landing on the Mun meant landing on an engine bell or on fins.

@AppleJacks69: Does right-clicking on a part bring up a bunch of new flags, like "isShielded", "cl", "cd", "cm", etc? For wings, is there also a "Stall" flag in the right-click menu? Does a GUI show up in the editor and flight scenes? If not, you haven't installed it correctly. Make sure that the FerramAerospaceResearch folder is in the GameData folder and that ModuleManager.dll is located in the GameData root. Installing the dlls in the old Plugins folder will cause problems. Other than that, make sure you're actually putting nose cones on your rockets and taking steps to streamline your vehicles. If you're still trying to launch bricks, don't be surprised when they fly like bricks. @rosenkranz: In KSP you only need ~2.2 km/s to stay in orbit at ~85km. That means that the remaining ~2.3 km/s needed for a stock launch is divided among gravity and drag loses, spread about evenly; this makes for ~1 km/s lost to gravity and drag each. With the drag reduced to realistic levels for aerodynamic vehicles, that 1 km/s drops away. Now, none of these numbers have any dependency on the actual parts used (well, except for the drag loses); with FAR it will always take less dV to get to orbit than in stock, so long as stock has its crazy-large drag. The only way to increase the dV to orbit is one of these three solutions: Increase the size of Kerbin and scale up its gravity; this solution has been rejected by the devs numerous times due to the memory requirements for that large a planetary surface. Increase the scale height of Kerbin's atmosphere and set the cut-off limit higher to increase gravity and drag losses; the problem is that atmospheres in KSP are already much taller relative to their planet's orbital radius than in real life. The much higher orbits needed to get out of the atmosphere will also make the planets look smaller, a frequent enough complaint already. Increase the drag that FAR applies; this would sacrifice a fair bit of realism for the sole purpose of increasing the difficulty. In general, not something I want to do, especially since the difficulty of launching something highly complex with FAR installed is already an exercise in "how do I fit this into a fairing / on top of a rocket?" What I think you're actually asking for is a nerf to the Isp of the engines we have to try and push the payload ratios lower, despite the lower dV requirements. The problem is that I'm not really in the mood to attempt a serious engine re-balancing attempt, particularly when every update causes the drag of vehicles to change and I'd have to balance with that in mind as well. If someone else wants to try running that type of a part.cfg mod with ModuleManager support, I'd be happy to send FAR users over to try it, but I really don't want to take on that extra responsibility myself.

Try looking at what your CPU is doing while you play KSP using the Resource Manager. KSP's only making use of one core for the physics (which is where the the bottleneck is) and so you want to make sure that your processor is running that core at the maximum frequency it can handle; if it isn't running the maximum frequency the whole time it's probably overheating a bit and you'd be well served by getting in there with a can of compressed air and cleaning out any dust that's built up in there. The next thing to do is to make absolutely sure that KSP is using your dedicated GPU; since you have the integrated GPU on that CPU KSP might be trying to use that instead. Try right-clicking on the program and look under "Run with graphics processor" and see which one is labelled as "default." If it isn't the GeForce, then you should be able to switch it permanently in the Nvidia 3d Settings, though you'll have to add KSP to the list of programs since it won't appear in there by default. If both of those are the case, then you can set everything to max and try comparing the framerates between max graphics and min graphics using fraps or some similar utility. I suspect that they will be very similar, the only difference being the fps drop when looking at the ground due to the terrain rendering (which is still very unoptimized, particularly the ocean). If that's the case you should try going into the settings.cfg file and find the terrain sections labelled "ocean" for each planet and set the subdivisions to much lower numbers than they are currently. They won't render properly at all with that, but the framerate will increase to something far more manageable. Besides that, make sure that Windows Aero is turned off and try setting KSP to have "high" priority using the "processes" tab of the Task Manager, which will help prevent any other programs you're running from getting in the way of KSP. The main thing to keep in mind is that the vast majority of games have a much higher load put on the GPU than the CPU; KSP is the other way around. Hope all of this helps.

Basically, the FARControlSys cl, cd, and cm are the values that would appear in the FlightData GUI. The FARBasicDragModel cl, cd and cm are used to apply forces to the part.

That is simply due to the FARControlSys class (the module that creates the FAR flight GUI) and the FARBasicDragModel class (the module that applies drag) inheriting from the same base class (FAR BaseAerodynamics) that has a bunch of necessary and useful aerodynamic values (such as cl, cd, cm).

@nhnifong: Currently no, but I can set up a mediafire folder for that purpose. @cartographer: That is a known issue that I am looking into. @wased89: That is also a known issue, though I'm not sure what the cause is.

@jaked122: It's a little of both. Information about where parts are in relation to one another and what forces will act on them at various orientations is calculated every time the craft's part list changes; this means that every time you clip the tower with a wing or drop a rocket stage that information will be updated. Information about how the part is oriented to the flow and Mach number effects are handled in real-time. @p1t1o: I think that should work... I don't see why it wouldn't. I would say that if you need more vertical tail you're be better off using two tails on the top of the plane, as many fighters do rather than the convoluted method you're trying, since it might cause some very strange yaw-roll coupling and might affect the pitch stability of the vehicle in strange ways.

I consider the majority of the wobbling to be unintended, although I don't think it actually counts as a "bug" per se, more as a too-low spring constant between the joints. However, this doesn't address the strength problem at all; a sufficient jerk is enough to break a payload apart and that can be produced during launch, during MECO, due to poor piloting, etc. It doesn't matter if the joints are all perfectly rigid; a payload should not be able to take an infinite amount of force without breaking, but this current proposal allows that to happen, so long as the fairings are attached.

There is a possible problem with this that hasn't been addressed yet, which is how the payload would be affected by acceleration and jerk during the early launch stages. With the current system, the payload has to be designed to survive the forces, moments and impulses created by the launch vehicle; it must be solid enough to not flex uncontrollably, it must not break under the stresses imposed. The proposed implementation would effectively remove this constraint and a payload could be designed to be ultra-light and flimsy, unable to take more than 1G of acceleration but still be launched into orbit intact because the physics of the payload under higher launch accelerations would not be simulated. I don't know if a modification to this to reintroduce this constraint would be worthwhile, since it would require some physics calculations to be done on the payload anyway and at that point the main benefit of this proposed system is gone. All the points made about substituting the payload with a point mass with a set moment of inertia are perfectly accurate, if we're dealing with rigid bodies. However, rockets and payloads are not rigid bodies in this game, they are a bunch of rigid bodies held together by springs and dampers that create a strange kind of deformable body, not a rigid body. Without modelling that we're back to the problem noted above, namely, that a payload can be designed without caring about how it would be affected by the launch conditions. A highly-flexible payload can pull a rocket of course because its deformation offsets the CoM of the rocket from the thrust vector, and thus removes another constraint on payload design. TL;DR: The current proposal effectively removes the constraints on the strength and flexibility of payloads, allowing ridiculously weak payloads to be put into orbit. Any changes to account for this will require running physics simulations on the payload, removing the primary benefit of the proposal.

@Dirt_merchant: As much of the file as you can provide. I need some idea of what happened when the errors started and what caused them to end. @p1t1o: First, you're flying a little too high too slowly; there isn't enough atmosphere for you to properly control the vehicle up there and you're going about 500 m/s slower than you should at that altitude. Try flying lower and not going above ~22km or so until you're going faster than that. Part of the issue is that though your intake spamming might allow you to get away with running the engines that high up without enough atmospheric density your wings won't do anything to control the plane. If that's not the issue, I'd look at how large your vertical tail is and how far behind the CoM it is; if the nose is wagging side-to-side that sounds like you don't have enough yaw damping and a larger tail further behind the CoM will deal with that. And no, FAR is not being overly aggressive in how it degrades an aircraft's performance in stall; a poorly designed / poorly flown aircraft will crash as a result of stall.