ferram4

@p1t1o: It combines all the models for each part into one "super-model" to calculate the geometry and drag characteristics. If this weren't done, you could get strange effects if a part's model(s) includes multiple meshes, resulting in a part that would be relatively streamlined as a whole being considered to be a drag-heavy monster of a shape. @Torminator: IIRC, the exact bug is that parts placed with symmetry do not have identical joint strengths; one part will flex more and break more easily than the other. A good way to see this would be to make a simple plane with long wings that aren't reinforced with struts; one should flex a great deal more than the other.

@NathanKell: It calculates drag for each part, not for each model. The pictures don't show any issues as far as I can tell; that is the way the aerodynamic center is intended to be displayed for a rocket, with the vector pointing in the direction that the force will increase in with a tiny increase in angle of attack. @Torminator: Honestly, I have no idea where the aerodynamic center bug comes from; it seems incredibly inconsistent and no one has been able to produce a simple design that suffers from the issue without it turning into a massive and complicated ship. I've also never seen a design where the source of the error couldn't definitively be said to not be the cause of some minor asymmetry either (not on the level that you would be able to notice, but as a result of floating point errors interfering with the design). I also can't separate out FAR's aerodynamics from KSP's asymmetric joint strength bug. A fix for this probably isn't going to be in the works until whenever FAR 1.0 comes out, since that will include completely reworked aerodynamics (much better than what is there now) and in the course of rebuilding everything hopefully the bug won't reappear.

@NathanKell: Okay I'll look at those. It should take care of all of the MODEL {} blocks, unless "Part.FindModelComponents<Transform>()" doesn't actually return each and every model transform for all the models assigned to the part.

@NathanKell: Sure, that would be cool. Sorry about not realizing it was you with the rocket issue, it was very late when I made that post. @a.g.: I really like that idea; probably keep some version of the larger window (slimmed down, of course) to allow people to access and modify the gains for each system. And keep a button that opens the help window, of course. Would you mind PMing me the code changes so I can implement them? @Van Disaster: No, the Center of Pressure is a totally different thing that happens to be a lot less useful in stability and control than the Aerodynamic Center. The Center of Pressure is the location where all aerodynamic forces can be modeled as lift and drag forces (that vary with angle of attack) and no other forces or moments whatsoever. Any asymmetry in the vehicle's design that would cause a pitch-up or pitch-down moment to be produced (like a negative incidence angle on the tail to help pitch the plane up) will cause the location of the Center of Pressure to shift as a function of angle of attack, sometimes outside of the vehicle itself. The Aerodynamic Center does not move (at least not significantly) as a function of angle of attack (unless stalling occurs), making it much easier to use in aircraft design. The Center of Pressure is a somewhat archaic aerodynamic property; I've only seen it used in old data from the time of Otto Lilienthal, Samuel Langley and the Wright Brothers back before most of the basic work in aerodynamics had been done.

@egreSS: Most people have answered the questions pretty well, but I'll give you my opinions too: 1. One thing to look at is how the CoM shifts during the ascent; it is always possible that it is shifting back enough for the rocket to become unstable, particularly if the rocket has a first stage containing multiple fuel tank parts with any of them above the CoM, though I don't think that's the problem with these rockets. Another thing to look at is the amount of control authority you get from gimbal-equipped rocket engines; if you are too reliant on reaction wheel torque you will probably lose control. A final thing to check is what dynamic pressure you detach the lowest core booster; if the dynamic pressure is high when you do that you might lose control momentarily while waiting for the second stage engine to ignite and give you control. 2. If you have a TWR ~1.4 I've found the best option to be to go straight up until you're going 60 m/s and then angle the rocket about 1-2 degrees off the flight path in the direction you want to turn. After that, try to keep the rocket pointing surface-prograde, and don't drift outside of the prograde ring during the ascent unless you know the rocket can take it. 3. Putting lifting surfaces on the bottom of your first stage is generally a good idea, since it will drag the CoL further behind the CoM. 4. Yes they do. As for the differences between your rockets, it is always possible that the drag of the fairing for the smaller rocket is worse than for the larger rocket. Another possibility is that the parts (which are mod parts in both rockets) are not set up with the correct size attachnodes to handle drag properly; 0.625m uses size 0, 1.25m uses size 1, 2.5m uses size 2, and so on. I'm not sure what's causing the CoL bug, but I'll look into it. I suspect I might just have to scrap my current system and rebuild it. taniwha: The "CoL" indicator is actually the Aerodynamic Center in this, which accounts for where lift and drag is applied. I honestly hate the term "Center of Lift" since it implies that the drag of a vehicle either doesn't affect it's stability or can (somehow?) be considered separately to figure out stability; it's just an ill-conceived term and I've only heard of it after it was implemented in KSP. I'd prefer referring to it as the Aerodynamic Center, but I'd lose everyone if I did, so I'm stuck with CoL, along with the other Kerbalisms like "Asparagus staging" and "Onion staging." Just to be completely explicit, the Aerodynamic Center is defined as the point on the vehicle where all of the aerodynamic forces can be modeled as separate lift and drag forces (which vary with angle of attack) and a constant pitching moment (which doesn't vary with angle of attack, and so doesn't affect stability).

@BubbaWilkins: Just remembered that one; I think I can work something out, although it will probably require propellers be powered by the Firespitter plugin.

Add a larger vertical tail and rudder to that to try and make it more resistant to asymmetric stalls. Then make that canard have a higher aspect ratio so that it stalls before the main wing. I've fixed the B9 intake bug and I think I've fixed the VAB and SPH lag; now I just have to look into the MOI errors with procedural wings and then the revision will be released.

@AncientGammoner: I would consider a "good" method of adding difficulty to be dropping Isps; while the dV necessary to get anywhere might be small that amount of mass necessary to do it will end up being either where they are now or requiring launch vehicles more like what we have in real life. The dV really doesn't matter; it's the mass necessary to achieve it that matters in the long run. I actually think that idea has come up a few times and I'd be very happy to see someone take on the "lower Isps to keep payload ratios low with FAR"-type of project, but it's not something I want to do myself. Too many part packs that would need to be taken into consideration. I dislike the "make the atmosphere out of soup" method of adding difficulty since it adds very little to any aspect of gameplay; for launches it just adds a slow, 10km vertical ascent and for planes it adds a nearly vertical ascent to the same altitude. It requires that jet engines to have too much thrust to make flight at sea level possible, which makes reaching top speed at maximum altitude in a plane almost laughably easy; it also makes jets a viable almost-SSTO-stage for rockets when they should be no more than extra boosters in that role, if they should be able to do anything there at all. It also makes exploring the surface of a planet tedious; you're limited to very low speeds by the large drag forces or you have to burn tons of fuel to move at relatively slow speeds. Finally, there's almost no challenge landing on a planet with a half-decent atmosphere once you get past reentry; just let the atmosphere slow you down to ~100 m/s and then land from there; no danger of slamming into the ground with a vertical lander or trying to touch down to fast with a plane, since the atmosphere will slow you down more than enough. My problem with the drag losses isn't that they're there, it's that they're way too high compared to all the other loses. There's almost no fun launching a rocket since so much time is spent waiting for it to be high enough to actually do something. As for the rocket, I see what the problem is there: FAR uses the size of the attachnodes to estimate some drag parameters and the top of the MkII Lander Can is a size 1 when it should be a size 2 based on the part diameter. There are a lot of stock parts that just don't use the proper attachnode size. There's really nothing I can do there since I think using ModuleManager to try and fix that will just cause craft files to break. @egreSS: That is an issue I've noticed myself (but probably not to the same extent that you're noticing it). Hopefully a fix will be in the next revision.

@AncientGammoner: I would argue that the huge drag losses to orbit (which are often equal to gravity losses) are an incredibly poor method of adding difficulty; it's not something to be overcome with skill, it's just a problem to be handled by throwing more rocket at it. Further, anyone coming into KSP with some knowledge of actual flight mechanics (say, someone like me) will end up being incredibly frustrated when they've gone an entire 5km up before starting their gravity turn and the rocket still falls into the ocean due to the large atmospheric drag forces; real rockets start their gravity turn at ~100m and that kind of disconnect between reality and game (for no apparent reason, mind you) is strange at best. I also don't see the reasoning to get rid of all realism for aerodynamics; we have fairly realistic gravity, we have fairly realistic part strengths, both of which are weighted towards being easier; why should proper aerodynamics be thrown out the window in favor of an atmosphere of pudding so that the difficulty can be bumped back up? I also have to assume that your rocket designs are already pretty aerodynamic if you actually consider launching with FAR to be "easy" considering the difficulties most people seem to have with constructing aerodynamically stable rockets. Alternatively, you're good at building rockets that don't have to undergo staging events in the lower atmosphere and so you avoid any stability-based failures there. I will look into the differences between drag with and without a 2.5m nosecone on the top, since that doesn't quite sound right; would you mind posting a picture of the rocket you used, just so that I can remove any other variables from the situation? @Torminator: Yeah, you're pretty much right. I think I'm not quite modelling the aeroydnamics of delta wings properly, so they might be more prone to being unstable in stall than they should be.

@Torminator: So while taniwha and Van Disaster should have covered most of it, keep in mind what happens to your Cm (yellow line) as stall occurs. From what it states, your pitch moment becomes more positive as stalling begins; this indicates that your aircraft begins to stall from the rear. Also, the fact that Cm slopes upward very during the stall-transition region basically means that your plane is pitch unstable in that region where the amount of stall is changing; in a fully-stalled or fully-unstalled state the plane is stable though. What this means is that once your plane stalls it will be highly resistant to coming out of that stall. A good way to try and fight this is to build your plane with the forward lifting surface having a larger aspect ratio than the aft lifting surface; alternatively, build in positive AoA to the forward surface or negative AoA to the aft surface to try and force the front surfaces to stall first; this will make the plane stable in stall. As a heads-up to the B9 air intake bug: I think I've got it solved, just some more testing on the way. It does seem like the drag from the large SABRE intakes is accurate though; they're just too blunt to be all that aerodynamically effective.

@DuckZero: Post a copy of your output_log.txt and then try reinstalling FAR. If that doesn't work, right-click on the control surfaces and see if the "isShielded" flag comes up; if it does then FAR's PartModules are being applied correctly. Try saving the craft as something before launching, see if that helps. I honestly don't know what else to try since I've never seen this bug myself. taniwha: Umm... I guess? Effects of Mach number wouldn't matter (yay incompressible fluids!), so that would actually simplify fluid dynamics for subs greatly. Then there would just be fluid density and some modelling of cavitation (mostly for the sudden drag increase when that happens). I'll admit that I've never done any hydrodynamic modelling, only aerodynamic modelling, so I'd have to put a lot of research into it first.

@Van Disaster: I don't think that would be possible; it seems like the ResourceIntakeModule class stores the "closed" drag value with too high a protection level for me to do anything with it. My only solution would be to create a new ResourceIntakeModule for each intake and then copy over every value that I can change, but that sounds complicated and prone to breaking. @DuckZero: Are you actually assigning them properly? They start with all axes activated by default. If that's not the case, then please post a picture of the craft that has the problem, because no one else has had this issue.

@DresCoffgrin: If it's only on certain planes make sure that your vertical tail is on perfectly straight. On some designs the editor can actually leave the tail angled to one side or the other which can cause rolling and yawing tendencies. Other than that, it might just be the plane becoming unstable at higher speeds; try adding a larger vertical tail to see if that helps. @icecubecookie: I can look into that, but it's probably the update to the taper code causing the error. If I recall correctly, the coordinate system for those B9 intake parts is different than the coordinate system for all the other stock and mod parts in existence, which is probably where the error is coming from. @Pyromaniacal: Unless you're trying to launch 200 tonnes in one launch there's really no need to get KW rocketry or Novapunch; you can get by with stock and procedural fairings. There also aren't hotkeys for the control systems since I intended them to be used more for flying with the keyboard than a joystick; I can look into adding that, but I'll have to make sure they can be modified. @Van Disaster: The reason drag gets worse when the intakes are closed is because of the way that intake drag seems to function. There doesn't appear to be a way for me to zero the "base" drag of the part without having to add entries to the ferramaerospaceresearch.cfg file, which is never going to be all-inclusive.

@PetWolverine: I'll have to look into the way the moments and products of inertia are handled. It may be a problem on my end, otherwise it's probably a procedural wings bug. @Subcidal: The delta-V necessary to launch from a body with an atmosphere is very, very dependent on the vehicle's aerodynamics. I've seen drag losses below 100 m/s and drag losses up to 500 m/s, depending on the aerodynamics of the rocket. @Pyromanical: Control surfaces need to be assigned to specific axes if you want them to function in a useful manner, otherwise they'll respond to control inputs the way they do in stock KSP, but with the proper aerodynamics. Depending on how your rockets are designed, they may launch more to orbit than they did in stock KSP. While asparagus staging (as well as all parallel staging) is not as aerodynamically efficient as series staging with FAR, it is still more aerodynamically efficient than it was in stock KSP. Just remember that if your rocket is incredibly wide compared to its height it might end up being unstable, which would end very bad for anyone or anything on board it. @Sparker: Try going into the part.cfg for that part and change the title from "Spacejunk Bay" to "Spacejunk Cargo Bay". That should allow FAR to identify it properly.

Here's a nice breakdown of the LV-1 Ant, 48-7s, LV-1R radial ant, and the 24-77:[TABLE=class: grid, width: 500] [TR] [TD]name[/TD] [TD]LV-1 Ant[/TD] [TD]48-7s[/TD] [TD]LV-1R[/TD] [TD]24-77[/TD] [/TR] [TR] [TD]Radial / Inline[/TD] [TD]Inline[/TD] [TD]Inline[/TD] [TD]Radial[/TD] [TD]Radial[/TD] [/TR] [TR] [TD]Gimbal Range (degrees)[/TD] [TD]0[/TD] [TD]1[/TD] [TD]0[/TD] [TD]1[/TD] [/TR] [TR] [TD]Mass (tonne)[/TD] [TD]0.03[/TD] [TD]0.1[/TD] [TD]0.03[/TD] [TD]0.09[/TD] [/TR] [TR] [TD]Thrust (kN)[/TD] [TD]1.5[/TD] [TD]20[/TD] [TD]1.5[/TD] [TD]20[/TD] [/TR] [TR] [TD]TWR (Kerbin sea level)[/TD] [TD]5.097[/TD] [TD]20.39[/TD] [TD]5.097[/TD] [TD]22.65[/TD] [/TR] [TR] [TD]Vac Isp (s)[/TD] [TD]290[/TD] [TD]350[/TD] [TD]290[/TD] [TD]300[/TD] [/TR] [TR] [TD]1 atm Isp (s)[/TD] [TD]200[/TD] [TD]300[/TD] [TD]200[/TD] [TD]250[/TD] [/TR] [/TABLE] Currently it appears that the main benefit of the ant engines are much lower masses, which allows the payload to be much lighter (keep in mind that for a small satellite 0.07 tonnes can be a fair amount). I also think that the low thrust does have uses, considering that it can make landing very light landers easier due to the increased control over TWR with the throttle. It might be left the way it is now and will be balanced by being more expensive or by using a different fuel mixture once the resource update happens.

Oh, I see what's happening here. FAR is accounting for the tapering of the prop engines including the props, which makes them appear very un-aerodynamic. I'll look into a fix. Until then, a link to a mediafire folder containing the most recent versions is currently on the front page.

@PetWolverine: That difference is likely due to the fact that the CoM of the procedural wings is probably shifted backwards while the CoM of the B9 wings is not. Also, you should make sure to add struts between your wings if you want to properly test a vehicle, since the change in wing geometry can be enough to greatly affect the performance of the aircraft. @Sparker: It is possible, however you need to understand that the space shuttle and buran were designed to reenter at ~35-40 degrees angle of attack, which means that they made a lot more drag than lift. It's likely that your spaceplane made much more lift than drag and so was able to lift out of the atmosphere. If you want to try a proper reentry, try pitching the spaceplane up so that the prograde marker is at the very bottom of the navball; if you have any fuel or monopropellant left, move it around to balance the plane; use RCS to control angle of attack and fuel transfer to keep the plane stable, but not so stable that you can't maintain the high angle. Once you've slowed down a lot, pitch it down to a lower AoA and head for the runway. @Torminator: It could be done, in theory, but it's possible that the way that the part is oriented it won't work properly. You could try copying over the changes to the smallCtrlSurf part (find it in ferramaerospaceresearch.cfg in the FerramAerospaceResearch folder) to see if that changes things. If your planes make good lawn darts then they are probably too stable; try moving the CoL forward and see if that helps.

@Van Disaster: Yeah... that would be about 5 pages on its own. There's stuff to cover about how the aerodynamic center of wings starts at the quarter chord, then shifts forward near Mach 0.9 before shifting back to ~0.4 chord for supersonic flight. There's the way drag of unused attachnodes facing the airflow have their drag increase from 1 to 1.86 as Mach number heads to infinity and how attachnodes facing away from the airflow start at a low value, peak near Mach 1 and then fall away towards 0 as Mach number increases. Honestly, that'll be about a 3rd of the guide, covering what FAR changes (in qualitative terms so I don't have to update the guide every update). @MAKC: Nope. Fixed now.

FAR doesn't change anything in the orbit code, which is where this bug would have occurred. The only things I can think of that would cause this would be gravity hack or something like hyperedit. FAR doesn't touch the orbit projection code at all, so you're probably talking to the wrong guy. Check out the other mods that you've been running and see if any of those caused it.

Ok, so version 0.9.6 is out, which fixes some bugs in the drag code, provides some extra support for procedural fairings and some other minor changes. The planned guide will have to wait for a bit, since I've realized just how much of a task that will be and I want to do it right. Essentially, it'll have to be "Aerodynamics for Dummies" in addition to documenting FAR's changes for it to be truly useful.

With a design like that (which seems to have too much wing to start with) part of the problem might just be that the you've got a lot of wing far from the CoM; that will make rolling difficult to start with. Then there are probably some issues with the CoL being too far behind the CoM, which would make pitching more difficult. Then there's the fact that wings with that much dihedral will cause the plane to roll back and forth a bunch any time you try to turn it; you'd be better off having the wings mostly level and adding a larger vertical tail.

The single biggest argument is that it results in different physical laws inside and outside the fairing; the possibility of launching otherwise unlaunchable payloads is a possible consequence of this. Unless the fairing is set up so that its strength is directly proportional to that of the payload, so that a force that would cause the payload to break breaks the fairing, causing physics to start acting on the payload, the world is inconsistent. Then, though it's more mundane, is the issue of how the physics engine reacts to a single payload "part" being replaced with the assembly of parts that the payload is made up of; this is an opportunity for incredibly nasty physics glitches to occur, which could range from the rocket merely twitching as the payload physics start to it being spun around like mad or exploding if things glitch enough. Finally, yes, it is a single player game, but that doesn't mean that we should argue that exploits should be left in the final product because "you can just not use it." What if I'd like to have a version of anti-lag fairings that doesn't allow payloads like that to be launched? What if I want fairings at all? I wouldn't expect any of the devs to code two different fairing types, one that packs the payload so that physics is run on it and another that doesn't but blocks aerodynamics code from running on it. If this was a mod, the "single player" argument would have a point, but it's not; it's proposed as code for the stock game, so the fact that it could be exploited, perhaps unintentionally (since the most common way to find out your payload isn't strong enough is that it breaks on the way up) makes this a problem I'll have to face to. It'll be like trying to design planes with the infiniglide bug; your ability to design things properly runs into the issue of just being able to twitch the control surfaces to go faster. In stock KSP we can't get around that bug; why wouldn't freezing the payload's physics have a similar effect of a positive benefit that should definitely not be there?

If that comes with similar crush / tensile failure forces for all parts, then I'm fine with it (which I would actually like a lot). If it's a special workaround for the fairing base only, then it begs the question of why the fairing base needs special failure criteria, above and beyond any of the other parts carrying loads. Doesn't this essentially require the player to be aware of an issue in the games code an make decisions to try and avoid it? When the "parts separating off of ships coming out of timewarp" bug occurred, the problem could be gotten around by slowly coming down from timewarp, but that didn't justify leaving the issue unsolved. Why is it the player's job to avoid issues caused by code implementation? First, the bug I mentioned above had the entire rocket's physics unfreezing coming out of timewarp and things still went wrong. Second, dealing with the entire rocket's physics unfreezing is probably easier than dealing with trying to connect a new group of physics objects to a group of currently active physics objects. I don't think that rendering is actually any significant part of the lag in-game, unless you misspoke there. I know the requirement of a tree structure isn't realistic, but I'd rather the unrealistic requirements be consistent rather than change based on whether the parts are in a fairing or not. Then perhaps Psycix could explicitly state what his statement in the first post ("The fairing 'protects' the part from structural failure as a result of wobbling or g-forces") referred to: being able to launch payloads (that otherwise couldn't be launched) without needing to consider the structure necessary to keep them from falling part or wobbling and phantom forces caused by simulation errors due to huge lag. If it is the latter one, then you are correct. This feature effectively implements the inertial dampers from Star Trek as a consequence of how it functions. Wondering whether inertial dampers are a part of the plan is one of the first things I think about, since my first thought about features is "how can this be exploited?" "how can I twist this to my advantage?" "how can I break this so it works in my favor?" If anything, I'm thinking about how I would use this to cheat and get things to orbit far more easily than could otherwise be done.

My "we would be back where we are now" quote referred to the fact that suddenly, with the fairing broken, the physics of the payload has to be simulated again; whatever fps benefits that would be gained from freezing it would instantly be negated the second physics started again. I appear to be failing to be coherent, and I apologize for any confusion there. It should have read something closer to, "Either the fairing would allow you to launch that flimsy payload without the huge girder mess, at which point my "inconsistency" complain still stands, or the fairing would break, at which point we're back to where we are now with respect to the physics-based framerate issues." I suppose I should note that I'm making the assumption that the fairing strength isn't based on the payload "strength" in any way, since two similar payload fairings failing at different loads entire based on how overbuilt the payload is would be incredibly strange. Fine, so then the mess of girders and struts around the payload will need to be required for the payload fairing to freeze physics properly, correct? Or some type of similar structural reinforcement, right? Every argument here has focused around reducing lag by reducing the number of parts simulated and the number of struts needed. It always comes down to the number of struts needed; why else would Psycix have brought up this picture of what he doesn't want to have to do if the goal isn't to remove the need to structurally reinforce the payload to the necessary degree to launch it? Further, I would quote this from the OP: This implies that an intended benefit of this is that a structural weak payload can be launched when it otherwise couldn't; that part of the plan was to reduce breakability, you know, what you called a strawman? Further, I would argue that even if the reduced breakability did not appear to be an intended goal, it would be a consequence of implementation. Further, I would argue that if a feature can be exploited, it will be exploited by the userbase, and as far as I can see, there is no reason why any of these fairings could not be strutted until they had effectively infinite strength, creating a magical cocoon of protection from forces that could cause the payload to break. I see no reason to separate intended and unintended consequences since, in the final analysis, intent doesn't change how the code runs. My argument isn't based on just what is proposed, but on what the consequences of that implementation would be. This strikes me as the type of system that can be very easily exploited and that would be exploited very quickly since the potential gains in protection from structural failure are incredible. I also have concerns that the suggestions made to try and fix the proposal are a little too band-aid-like and will start to inspire fridge logic in players and might break immersion and cause frustration.

Yep! The way struts are currently coded, while you can't start them from the fairing and then attach to whatever else, you certainly can do it the other way around. You'll still have the lag situation going on, just with people strutting the payload fairing to hell rather than the payload itself. You could argue that it's entirely their own fault in that case, that they could launch a smaller payload with a smaller fairing on a more gentle launch vehicle and use docking to put it together in orbit, but the same argument can be used for the current strut-monsters people insist on launching. Payload fairings (at least in real life) are just aerodynamic shells that can only support the aerodynamic loads on them; their mass shouldn't vary with anything other than size, since they only need to support themselves and aerodynamic forces. The payload fairing base could vary in mass since that would be responsible for supporting the payload. I guess this is reasonable, especially since if you didn't do that you'd have to recalculate the mass and MOIs of the payload every physics frame as the mass distribution changes. I understand that it would enhance the performance of the game, but optimizations come at a cost: we could greatly improve the game's performance by combining every rocket stage into a single rigid body, but it would be at the cost of removing the current part failure mechanics (which would probably require a lot of code to re-implement in that situation), which is probably one of the best game mechanics KSP has. I still have reservations about how strutting the fairing to hell could be used to make invulnerability capsules. Then there are the glitches this would cause. Do you remember the bug where rockets would lose parts when coming out of timewarp due to how physics restarted? You're essentially proposing a situation where a bug similar to that is very like to occur. Here's the most common failure I see happening for a standard rocket using this: the rocket has a payload that is somewhat flexible; not very flexible, not flimsy, but it does deform a little under thrust. The flight scene loads, and its physics are frozen while it is in an un-deformed state. The rocket launches, and once out of the majority of the atmosphere, the player detaches the fairing; however the thrusters are still running. Physics restarts on the payload, and now one of two things happens: 1) the payload glitches on physics start and the rocket suffers spontaneous disintegration; 2) the payload suddenly deforms under this new load and it springs around a bit; the rocket becomes difficult to control until this settles down, possibly losing control in the process. The larger and more flexible the payload, the more problematic option 2 will be; it may even turn into a problem if the throttle is off for large enough payloads. I really worry about how the inconsistency in handling the payload's physics would work out in-game.