ferram4

@grom: That is likely a minor error in the CoL indicator; it should be pointing straight out, properly modeling the direction that lift goes in... I'll check that out and see if I'm modelling something wrong. @Subcidal: The special FAR modules are only really necessary for the MK1-2 and MK1 pods, since they need special aerodynamics specified due to their unique shapes. The other cockpits are handled perfectly fine as it is. The FAR GUI module is applied to all parts that have "ModuleCommand" defined for them, regardless of where they are placed.

@camlost: Airfoil thickness is simulated to an extent. The subsonic lift model requires some amount of thickness to function properly, particularly with regard to stalling properties. The supersonic lift model has it built into the design, simply because wings can be more effective in supersonic flows if they have some thickness. Camber isn't accounted for for two reasons: first, the way KSP handles mirrored parts is not to actually "mirror" them; it's to flip it upside-down. This means that if I were to add any modeling of camber effects planes would spontaneously roll, which while amusing the first time, would get boring very, very fast. The second is that camber doesn't create lift at supersonic speeds, only drag and pitching moments. So for the vast majority of KSP vehicles (which I assume are designed for supersonic flight) camber is detrimental to performance, not beneficial. Body lift is handled by an approximation based on Newton's Sine Squared Law, as used as an approximation for hypersonic aerodynamics. More refinements are planned, but there's a lot of data for me to go through and the lift of blunt bodies is a very complicated problem. It's actually a bit harder to deal with than wings due to the flow characteristics (large amounts of flow separation, large pressure changes, pressure drag dominating skin friction drag). Wings detect fuselage interference in the same way they detect wing interference, so the effect is there. @Dirt_Merchant: No hotfix, since I've changed how cargo bays are handled and I want to make sure that is working right before I release it. As for most of the control surfaces you ask for, the physics are there for them, though the code doesn't allow for spoilers for roll control (I'll admit I don't quite understand the design reasoning behind choosing spoilers over ailerons, unless it's easier to maintain or build). You can actually set up a control surface as a flap, attach it to the front of a wing and it will act as a leading-edge slat. I'll admit I don't particularly like the use of control surfaces for multiple roles, mostly because then you can get control inputs working a cross-purposes. @Doomydoom: The reason forward swept wings are more likely to rip off is because of the way the wing bends. If the wing is unswept, bending is independent of torsion; it doesn't affect the higher angle of attack at the wingtips that cause the wing to tear itself apart. If the wing is swept forward, it exacerbates the problem; when the wing bends the wingtips end up at higher angles of attack, which means more torsion and the wing is more likely to tear itself apart. With a swept back wing the wing bends in such a way that if counteracts the problem; bending reduces the angle of attack and fights off torsion. A properly swept-back wing can actually ward off all problems of static aeroelastic divergence, only having to worry about flutter. Of course, this is assuming the material is isotropic (acts the same in all directions). Anisotropic materials (read: composites) can be used to counter this. This is why swept forward wings had to wait until composites came along and for most purposes there's no reason to go with forward swept over backward swept wings. The design you've posted should actually be good; the only problem that I can see are limited to the typical supersonic aircraft problems: with very low aspect ratio wings and most of the mass in long, thin tube your vehicle will be prone to inertial coupling. Now, this doesn't mean that it will spontaneously explode, it just means that you'll have to be cognizant of the fact that yawing motion might cause it to pitch up like crazy. The other problem is that it wouldn't follow Richard Whitcomb's area rule which (in the real world) would determine how much transonic drag it would run into. However, FAR doesn't simulate that (and I don't want to) due to the fact that it would make things very, very difficult to do in KSP. Of course, you asked me to tear it apart, so I'm nitpicking now.

@Doomydoom: Thank you for giving everyone an example of the type of wings that would never be used for commercial jets, mainly because they would have massive issues with aeroelastic divergence and flutter (which I hope to implement at some point). Divergence is kind of simple: lift twists the leading edge of the wing upwards, the wing makes more lift, leading to it twisting more; eventually it twists enough to break. Flutter is the same type of thing, but add transient motion; this is a decent video of it: Basically, those forward wings should be ripped off. @Autochton: Try struting the wings down; symmetry-created joints do not have equal strengths, so your plane may become subtly asymmetric. Otherwise, I have found a minor wing interference bug that I've fixed. It shouldn't just affect B9 wings, but it might be causing some minor problems.

@Queue: The numbers are the maximum deflection of the surface in degrees; basically, putting 5 in there will cause it to deflect up to 5 degrees while 50 will cause it to deflect up to 50 degrees. Larger numbers will result in more lift and drag from the control surface, up until it stalls, at which point lift will drop off but drag will continue to increase. Depending on how your plane is designed, a control surface stalling can result in a slight reduction in control authority at best and a complete loss of control at worst. The numbers on the control systems controls the gain of the control system; the gain determines how quickly the system responds to disturbances. Basically, a gain of 0.1 for the Wing Leveler will result in the system responding faster than a gain of 0.05. However very large gains can cause the vehicle to oscillate; for an abnormally large Wing Leveler gain, the plane might continually roll left, right, and back again, never actually leveling out completely; if the gain is large enough if might even roll all the way over. Very large gains are the reason that ASAS can cause serious problems with FAR. @foamyesque: That's a very cool way of packing that payload. Everyone who can't figure out how to launch their rovers, space station sections, etc. learn from this guy.

@Weatherman159: I'd go with what daveboy2000 says on the fairings, but here are some other things you might want to think about: You might want to look into what a gravity turn actually entails; it doesn't mean "go straight up and then pitch over 45 degrees all at once" like most people here seem to think. Taking the gentler, smoother pitch schedule of a gravity turn will make controlling your rocket easier. Try to keep your rocket pointed within 5 degrees of the surface prograde marker (which is slightly more than the size of the circle on the marker). Large angles of attack can cause a loss of control in many designs. Reduce your TWR. You could probably replace every single one of those Mainsails with Skippers and it would still fly. Large TWRs tend to lead to overspeeding in the lower atmosphere, which can lead to aerodynamic forces overpowering control authority. Use more serial staging and less parallel staging; you don't need nearly as much dV with FAR installed, and longer rockets tend to be more aerodynamically stable. Further, as the mass drains out of the first stage's tanks, the CoM moves forward, making the rocket even more stable. Try to make your first stage last until you start getting into the upper atmosphere; early staging events can cause the launch vehicle's dynamics to change suddenly at an inopportune time. Add fins to the bottom if you need an extra little bit of control; their effectiveness will drop near Mach 1 due to transonic effects, but they can help on some troublesome designs. Don't use ASAS in the atmosphere; it can cause flexing oscillations that can cause a loss of control due to uneven aerodynamic effects. I'd say to start with rockets that aren't designed to deliver strange payloads and instead focus on smaller, more aerodynamic payloads. Think back to when you first started playing KSP and go through those motions again. This is a rocket that I use to send crew to a space station I have in Munar orbit; I'm sure it could easily be modified to deliver a payload to the Mun. You'll want to start pitching over when it's going about 25 m/s; just start to tilt it over the slightest bit and just keep it pointed forward. Gravity will turn it most of the way.

@foamyesque: While the aerodynamics of each stack are being determined independently (actually, the aerodynamics of each part are being determined independently) is part of the problem, at supersonic speeds (where most of the poor aerodynamics would be noticed) a half-decent approximation can be figured by handling the pressure difference acting over the front and back cross-sectional area of the vehicle and adding skin friction drag afterwards. Currently FAR doesn't actually handle how the cross-sectional area of vehicles change (it's difficult to determine for any given part and then there's the problem of the change between parts) which is where the majority of this problem comes from. Then I suppose a 3-D interference effect could be approximated on top of that if needed. @localSol: I wasn't specifically talking about the strength of p-wings, I was talking about the strength of most parts in KSP in general; they all are a little too strong but this is necessary based on how the joints between parts behave.

@asmi: I can look at Bobcat's Buran, but I don't know if I'll actually create the configs for it... the fact is that since I don't use it there isn't much incentive on my end to do the work for it. Honestly, if you want to make them up you can find the relevant distances and angles yourself; the documentation for each value should be in the FAR readme. @lyndonguitar: If your asking "will MechJeb properly account for how aerodynamics will affect my landing position?" the answer is no. MechJeb isn't able to interface with FAR for that and even if it was it would be quite possible to land in the wrong place as a result of the drag and lift changing due to the angle of attack of the lander during the descent. @foamyesque: Those are all mainsails, correct? I think you've proven that any problem, even poor aerodynamics, can be overcome with enough thrust. I'll bet you could cut the dV needed down by ~500 m/s or so if you used a more aerodynamic vehicle. Now, realistically, that should probably fly apart, but I can't control the stiffness of the joints between parts independently of their attach strength; if they could this probably wouldn't happen. I suppose I can look into increasing the drag of the command modules when they aren't in a reentry configuration.

@rhoark: That's all behaving as it should; the only time that an airbrake in the location you described would be unaffected would be if the wing in front of it were stalled. @a.g.: Welp, time to revert all my changes then. @DaRocketCat: See the modified first post of this thread. You install it just like you would any other mod, copy it into the KSP root directory and merge it with the existing GameData and Ships folders. @bulletrhli: If you manage to cause that again, could you try to remove all other mods and unnecessary parts from the craft until you get the smallest vehicle that can cause that bug? Having access to a craft file and detailed instructions on how to reproduce the bug would go a long way towards finding and fixing the issue. As a heads up to everyone, here's what I've gotten done for the next release (no ETA though): Cargo bays ~90% functional using Firespitter's animation module. A few bugs to work out though. The huge amounts of drag from some of the new B9 intake parts has been fixed. Transonic and supersonic wing drag getting tweaked. Some optimizations in the wing code; should reduce lag a bit. And a known issue that I've found: don't use a cargo bay as the root part of a ship. The entire ship will be unaffected by aerodynamics. This will be fixed in the next version.

@Tripod27: That sounds like something isn't starting up properly; what is the very first FAR-based NullReference to appear? That should help narrow down the problem. I'd say that this is probably a result of either an improper install or some type of interference with another mod. What mods are you using? @Spanier: FAR can't detect the proper result of the payload being shielded by your makeshift fairing; if it attempted to do so your computer would lag to a halt and would probably prevent parts from being affected by aerodynamics when they should have been. The problem comes down to the fact that while you and I can see that all of those structural panels should behave like a payload fairing in this particular instance trying to create an algorithm for the computer to run to determine this (that doesn't cause performance to drop terribly) is difficult, if not impossible to do. @a.g.: I think I am using the wrong numbers... I'll look into fixing that for the next version. @localSol: While it does suffer a decrease in lift due to it being a biplane it benefits greatly due to the effect of closing the planform; essentially it has better lift and drag performance than an equivalent open wing design. You're also using quite a lot of lifting surfaces for a very light design, so taking off at that speed makes quite a bit of sense. The only reason it actually makes it to Mach 3.6 is because the wings don't fly apart in the transonic regime (like they probably should) and that you're powering it with an engine that is as strong as rockets. Considering the strength of KSP jet engines and the amazing failure strengths of parts, none of this is really all that wrong.

@Tw1: The structural panel aerodynamics are already modified. I'm not going to try to mess with the water dynamics though, so boats will have the same problems they've always had. @Tripod27: Okay, then it's the second thing I mentioned: you're only running FAR aerodynamics on non-wing parts. And all of those NullReferenceExceptions? The debug log getting spammed with that is probably causing the slowdown. I need a copy of the output_log uploaded so I can dig through all of those exceptions (and the finer details you don't see printed in-game) and find the source of the error. Without that I can't do anything about your problem because I don't know what the root cause is.

@Tripod27: If you're not getting anything in the VAB or SPH, that means that FAR isn't being loaded at all; alternatively, it means that you're using the stock "aerodynamics" on the wings but FAR aerodynamics on everything else. Could you go and reinstall all of FAR, run the game and then post a copy of your output log? Without that I can't find the problem you're having, since I don't have that on my end and there are no other reports like that. @Huelander: The problem is due to the orientation of the part; FAR is working on the assumption that they're oriented across the airflow in a higher-drag configuration than they should be. I think I've fixed that problem on my end, so the next FAR release should fix it. FAR's air intake values are correct though; it keeps track of the actual resources added rather than just what the GUI value says. @grom: You take your object up high and drop it. Joking aside, trying to figure out terminal velocity is incredibly difficult due to the fact that it varies with geometry, orientation to the airflow, the mass of the vehicle. That said, unless your TWR is greater than 3 and you're going to go vertical for a minute you don't need to even worry about it. If you're going fast enough that terminal velocity matters you're going to be worrying more about controlling your rocket than flying it. Long story short: it doesn't matter; it's about ~400 m/s for a full rocket at sea level. It drops off from there fast.

Gauss H2K: First, make sure that you figure out what is a stable orientation for aerocapture; if your vehicle is aerodynamically unstable during that maneuver you really won't be able to predict what will happen. Once you figure that out you'll have an idea of whether you can have a very high drag configuration high in the atmosphere or whether you'll have to go with a lower drag configuration and dive deeper for your capture. Unfortunately, you'll have to take a trail-and-error approach to this. Consider each attempt that fails a "simulation" and then just quickload to try again. @Firov: I'm aware of the incompatibilities. The shielding-even-when-open problem looks like it is caused by B9 is using the animation modules used by the Firespitter pack, which I haven't coded it to work with. The parts-being-shielded-when-they-shouldn't problem is probably the result of FAR thinking the cargo bay is larger than it is because FAR is trying to find the extremities of the cargo bay expecting that the doors are closed; when they're open it thinks the bay is much larger than it actually is. @Model1Bravo: Basically the source folder contains all of the C# code that gets compiled into the FAR dlls. Don't worry about it, you don't need it to use FAR, but I have to make the source code available to post the mod here, so I figured that distributing it in the .zip made the most sense. Why don't you try opening the zip file and just copying the necessary files out rather than dumping them to the KSP directory and hoping that it works out?

@s20dan: I believe that camlost is correct and that they use Blade Element Theory for their propellers and wings; I also think that they do some very simple simulation of the general flow-field around the plane to handle the aerodynamics of the fuselage and to implement the downwash calculated through the Blade Element Theory implementation. The main difficulty is the geometry configuration problem: how do I identify what is what on this vehicle? In X-Plane I believe the creator of any particular vehicle asset determines the proper simulation grid and how many blade elements need to be used, which simplifies the problem greatly; that cannot be done in KSP without making aerodynamics subject to the player's whims (knowledgeable players will be able to manipulate and glitch the physics to their advantage) or relying on some minor form of geometry identification to control the player's choices, at which point most of the hard part is done already and asking the player to handle the problem would be annoying. @Camacha: I've thought about it, but I don't know how well it would be received. I know that they've stated they want to try to dance on the line between "game" and "simulation" and I know that I'd probably push KSP much closer to "simulation" than anything else. I suppose at a later time I can try contacting them, but I assume that they have enough technical know-how to implement an adequate aerodynamics model without me. I'd be happy to help, I just don't think I'm really needed to solve that problem.

@Doomydoom: That is more the effect of having very large lifting surfaces with very little in the way of mass (at least from how it appears to me). Add to that the fact that the part connections are over-engineered because they have to be set to control deflections rather than the ultimate forces themselves and I can see that level of over-engineering happening. I think most modern fighters can come close to those g-forces but are limited because the pilots can't maintain proper situational awareness and control if the plane is executing a 9g+ maneuver. As for trying to detect if there's a surface that the shock can attach to... It's difficult to find the absolute front-most point of a vehicle (it's close to the origin of the front-most part, but a little further due to the model); then I'd have to attempt raycasting the cone created by that point to find any places where the shock would impact the vehicle (this would be very expensive computationally, btw). Then I'd have to try and determine whether a part being impacted by the ray meant that it wasn't riding a shock (e.g. a vertical stabilizer that reaches outside the Mach cone, but doesn't ride the shock) or if a part that wasn't impacted meant that is wasn't riding a shock (e.g. a vertical stabilizer that remains completely inside the cone, but doesn't ride the shock). Attempting to use the normal vector of the impact point only does so much good and doesn't tell me anything about the vehicle geometry in between the ray origin and the impact point, so even using that to help differentiate is difficult. The main problem is less about the physics themselves and more about trying to detect the actual aerodynamic configuration of the vehicle. The current part-by-part solution doesn't need me to figure out the configuration of the whole vehicle; I only need to worry about the properties of one wing part, or one nosecone, or one fuel tank when I'm attempting to code the aerodynamics. Yes, it makes the assumption that the flowfield is linear (i.e. that I can combine the individual effects of each part and the linear combination will be accurate), which is very, very wrong, but it is the simplest and most robust solution to the problem of indeterminate vehicle geometry. I'd honestly love to do a more advanced aerodynamic simulation that handled the aircraft as a whole rather than part-by-part like I'm doing now. The first problem is that I would need a robust algorithm to determine all the pertinent details of a vehicle's geometry (which could range from identifying wings, fuselages, etc. to try and handle individually or trying to create a mesh that could be used to do proper CFD using the Reynolds-averaged Navier-Stokes equations with some kind of simple turbulence model). The second problem is trying to implement the simulation in an efficient and robust manner, by which I mean it doesn't lag your computer to hell and it doesn't vomit when you try to fly an Abrams tank because it doesn't know what to make of that. The third problem is trying to apply the forces and moments calculated for the vehicle as a whole to the proper parts so that you can get structural failures from aerodynamic loading without causing unrealistic behavior. So there's a mini-rant on the subject; believe me, I've spent a lot of time thinking about this topic and a reliable solution to the geometry configuration problem still eludes me, especially because it has to be able to update in real-time to handle vehicle deformations. @foamyesque: I'd actually create a stack of them on top of the Hitchhiker, give each one a pair of radial chutes (this is Eve, correct?) and release them in sequence before pulling the chutes for the Hitchhiker itself. I'd also switch out two of those batteries for a pair of toroidal fuel tanks and then add a pair of radial engines just in case you need them; I've found that they can be used for asymmetric thrust can be very good for saving rovers that have flipped due to reckless driving as well as safely landing at your destination. And if you're intending to return them home then the fuel tanks + engines will allow you to re-stack everything to pack it up and go home.

@Doomydoom: Yes, but they also knew the exact specifications of what the vehicle would be; I don't. I'd love to do an aerodynamic analysis of the entire vehicle rather than part-by-part, but that can be a lot more complicated and can end up being less accurate. Also, how do I detect when a vehicle is a waverider and when it isn't? @Taverius: All my attempts to implement it have resulted in things either not working properly or no noticeable difference. @seagull42: It should be working properly, unless the drag of the probe wasn't much to begin with. I can take a quick look into it. @Nobody_1707: Your problem is that you're starting your gravity turn too soon and at too low a throttle. More throttle, start the turn when you're going 60 m/s, start the turn gently, don't use SAS, since it looks stable enough. You should be going much faster than you are in all of these shots (except the last one, which is closer to the right speed, but still low, direction aside). The gravity turn that it appears you're taking would work if you were running at a TWR > 2 the whole way up, but it would be scary and hard to control. Only other thing I'd do is to combine the first core and second core stages into one stage so you can get further up before staging makes the rocket shorter, and thus, less stable.

Well... maybe, but I'd have to scrap all the current wing code and switch over to a more robust, but far, far, FAR more computationally intensive CFD simulation. If you really want to know the main problem: you're asking me to simulate physics that's currently being researched in real-time on your computer; how do you think that's gonna work?

@Doomydoom: The first problem is that FAR doesn't actually have the physics implemented to properly simulate a waverider, so it won't behave exactly the way you think it should. The second problem is that it looks like you'll have a very large positive zero-lift pitching moment; basically, the angled up wings near the front of the vehicle are producing enough lift to overpower anything else you do. Solutions include an up-angled wing part near the tail, more control authority, modifying the angle of the engine exhaust so you have more control, angling the front down a little bit and shifting the CoM forward. @seagull42: Here's a not-quite exhaustive list of what things do; many of the help windows available through the GUI should answer these as well and have more information if you want it: Static Analysis: Cl: Lift coefficient; the lift of a vehicle after removing the effects of wing surface area and dynamic pressure; larger means more lift. Cd: Drag coefficient; the drag of a vehicle non-dimensionalized in the same way as lift coefficient; larger means more drag. L/D: Lift to drag ratio; measures how efficient the plane lifts; larger corresponds to a more efficient vehicle. Cm: Moment coefficient; the pitching moment (torque) of the vehicle non-dimensionalized in the same way as lift coefficient and drag coefficient; positive indicates pitch-up; must have a negative slope wrt angle of attack for the vehicle to be stable; elevators increase and decrease this to control the lift of the vehicle. Stability Derivatives: These are used to describe the motion of the vehicle in response to a disturbance at any flight condition; basically, if you have a plane flying along, and then a gust hits it, these numbers will describe how it responds. The numbers themselves matter less than the sign of the numbers, which is indicated by a tooltip that appears when you mouse-over the number. You'll probably find more useful information here: http://en.wikipedia.org/wiki/Flight_dynamics_%28fixed-wing_aircraft%29 Simulation: This takes the stability derivatives calculated in the previous tab and lets you use them to simulate the vehicle's response to a disturbance; basically, you can see what it does if it is angled 2 degrees to the left in flight. It'll let you see most of the motions described in the help section for this tab, such as: Longitudinal Short-Period: Fast oscillations of angle of attack and pitch angle; basically what happens when you tap and release the elevator quickly. Longitudinal Phugoid: Slow oscillations of forward velocity and pitch angle; the plane constantly exchanges altitude for velocity and vice-versa. Lateral Roll Damping: Highly-damped non-oscillatory rolling motion; it just describes how the plane responds to aileron movement. Lateral Dutch Roll: Lightly-damped oscillations in yaw and roll; see what happens if you take a plane into the air and tap and release the rudder. Lateral Spiral: Lightly-damped or slightly unstable yaw and roll combination; the plane slowly goes off-course and starts to turn into a downward spiral; note: this is not a tailspin. You can find more information using the Wikipedia page on Flight Dynamics; it's fairly well written and covers most of the basics. If you want more info, feel free to ask more specific questions; they're easier to answer and the answer can convey more information. @toadicus: Excellent! I'll make sure that works and then implement it officially. The main reason the cfg gets written to is to save the position of the GUI windows, which I suppose doesn't have to be done so much. @Nobody_1707: Without the picture yet, I can take a stab in the dark and say you need more control authority; so more gimballing engines and fins.

Post pictures; I updated body lift a bit as well as some of the wing-interaction stuff, so it's possible that some designs aren't exactly right. It's difficult to find a nice, simple graph showing the general trend of lift created by a cylinder at an angle of attack, so currently body lift is the same at all Mach Numbers. Also, the CoL currently doesn't account for the destabilizing pitching moments of fuselage parts at an angle of attack, which might change things a bit.

I think that the framerate is more a problem of the huge number of parts and struts than anything else. An alternative is that it has to do with a few situations where I'm using raycasting but that's done by the wings, not the regular parts. One of the possible reasons for the ailerons not function properly is if they stall partially during the maneuver; if that happens you might end up with your lift dropping when you wouldn't expect it to. Alternatively it could be large scale flexing in the vehicle (there are a lot of joints in that thing that can flex). And no, FAR won't figure out if stuff in the middle is shielded; trying to identify shielded parts can be really difficult to pull off in a situation like that.

@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.