ferram4

I've confirmed that it works with 0.22, and I've pushed out the version 0.9.6.3 revision, changelog in the readme. The nosecone "updates" don't actually affect FAR at all, since all it consists of is the nosecones making lower drag through the old stock system than they did before, which still gets overridden, so no problem.

FAR does open its coefficients in the config file... if you read the readme file you would see the documentation for that (why does no one read the readme?). I used to manually specify the coefficients in the configs, but that doesn't work for thrid-party mod parts. You can still manually apply coefficients if you like. However, you can get what you want quite easily: Make a plugin that grabs the atmospheric density functions for each planet and multiply each by ten. There, drag is increased, dV requirements are back where they were, and you don't have to go through each and every config file for each mod ever made to make sure it is compatible with FAR.

Yeah, looking more closely I think a handler might make more sense (at least for the TechLevel-enabled engines), especially since the alternative will have KIDS doing a lot more work than it needs to. The method I use to extend the Isp curve can be found if you just search for "extendToZero" and look for the math-intensive code. Now, looking at the old hybrid engines (and assuming that the B9 HydraEngineController functions the same way) this should handle it already... Correct me if I'm wrong, but do those modules function by adding a ModuleEngines PartModule each time the engine mode switches? Because if they do, then KIDS should handle it perfectly fine and it's only the newer engines that will be a problem.

Just tell me what values I need to look for and I can code it entirely on my end, sort of like how Procedural Wings works with FAR; if there problems I'll bring it up and we can do it your way.

@Supernovy: As NathanKell already said, the Arcturus Thrust Corrector already does that. I might add that as a feature if it's desired enough, but lacking any info about conflicts with Arcturus, I don't see a pressing need to add that. @AmpsterMan: Doesn't modify thrust values or engine mass, only the Isps of the engines. @NathanKell: Looking at the Modular Fuels System source code, I don't think this will work with it as is; I can look into providing support for it in a later version though.

Raw reduces Isp so that a rocket that makes 9 km/s with stock will make 4.5 km/s, allowing it to just barely reach orbit. If that was enough to account for the differences between KSP and real life, that would be it. However, there are hidden complications: There's a ratio that isn't often talked about in KSP, called the structure ratio which is the fraction of the booster (note: no payload here) that is not fuel; this is the tank's dry mass, engine mass, decouplers, fins, separatrons, etc; the higher the number is, the less dV you can get out of the rocket. For math reference, the rocket equation, written in terms of structure ratio and another ratio, the payload ratio, is: dV = Isp * g0 * ln((1 + p) / (e + p)) p = m_payload / (m_structure + m_fuel) -- payload ratio; ratio of payload mass to mass of entire booster e = m_structure / (m_structure + m_fuel) -- structure ratio; ratio of structure mass to mass of entire booster In real life, it's not too difficult to get structure ratio down to 0.1; the best I've found is the Saturn V first stage, which was just under 0.06. In KSP, the lowest structure ratio possible is 0.1111111... assuming that your rocket is all fuel tanks and the engine weighs nothing; for it to practical it has to at least have a TWR of 1 on Kerbin, and the lowest you can get that is ~0.14666666... which is a Mainsail pushing nothing but fuel tanks, no decouplers on top, no payload (read: totally useless as a booster), which puts a rather high lower limit on the structure ratio in KSP. So the Adjusted preset tries to finagle away the obvious differences in dV that will result from a booster that has a structure ratio of 0.1 and one that has a structure ratio of 0.146666.... with a payload ratio of 0.05. Of course, this is technically wrong, since it's trying to use a single linear factor to account for a nonlinear difference, but it's close enough for Kerbal engineering. TL;DR: KSP rockets are less fuel by percent mass than real life rockets, making them less efficient; Raw doesn't try to fix it, Adjusted tries to finagle the difference away.

I'll admit that this issue has always irritated me a bit--realism shouldn't necessarily mean "easier," but given that the stock atmospheric model results in Kerbin being surrounded by some kind of pudding-like gunk, it's somewhat inevitable. To try and somewhat counteract this, I went and developed the new Kerbal Isp Difficulty Scaler plugin to reduce Isps and try to help rebalance KSP with FAR installed. I normally shy away from such obvious self-promotion, but considering this is the very reason why I developed it in the first place, I figured you guys would like to know about it.

Kerbal Isp Difficulty Scaler Tired of being able to reach orbit with tiny rockets? Annoyed that pressures greater than 1 atm don't decrease your engine's Isp? Want Isp to control your engine's max thrust, not fuel flow? Like FAR and realistic aerodynamics, but wish that it didn't unintentionally decrease the size rocket you need to get to orbit? With Kerbal Isp Difficulty Scaler, you can change that by decreasing / increasing the Isps of all engines in your game, increasing / decreasing the size of the rockets you need to get anywhere. EXCITING FEATURES! * Define IspPresets, which allow you to make the following changes: Vac Isp Multiplier - How much the vacuum Isp of the engine is scaled; >1 makes engines more efficient than stock, <1 makes them less efficient than stock Atm Isp Multiplier - Same as above, but at 1 atm (Kerbin Sea Level) Extend Curve to Zero Isp - Choose whether to have Isp bottom out at 1 atm or continue decreasing until it hits 0 (does nothing if Isp increases with atmospheric pressure) Thrust Corrector - Choose whether to have thrust vary with Isp while fuel flow remains constant (as it should) or keep the stock constant thrust with variable fuel flow Thrust Corrector Options - Can have engines rated for vacuum (creates rated thrust in vacuum and less on the pad) or rated for atmosphere (creates rated thrust on pad and more in vacuum) based on Isp and/or thrust Isp Cutoff - Isps above this will be considered "vac-rated" while Isps below this will be considered "atm-rated"†Thrust Cutoff - Rated thrusts below this will be considered "vac-rated" while thrusts above this will be considered "atm-rated"†* Select a different Preset for each saved game! * Compatibility with Kerbal Engineer and MechJeb; it still takes 4.5 km/s dV to get to Kerbin orbit in the stock game, and it still takes 3.5 km/s dV to get to Kerbin orbit with FAR installed! * Automatically works with all simple part-only mods! * Default Presets, including conversions that require real-life mass ratios and conversions to handle FAR's lower drag! †If both Isp and thrust cutoffs are set the engine must have an Isp below the Isp Cutoff AND a thrust above the Thrust Cutoff to be "atm-rated"; this means only low-efficiency, high-thrust engines will be "atm-rated" (based on your definitions of "low" efficiency and "high" thrust) Known Issues: Isps do not update in the VAB / SPH Parts List; this does not affect Kerbal Engineer or MechJeb calculations and those plugins will produce correct dV / Isp numbers Note: To avoid possibly exacerbating any of the win64 KSP build's instability inherent issues, this mod will disable itself if run on a win64 build of KSP. Download v1.4.2 from Kerbal Stuff!Download v1.4.2 from GitHub! Link to older versions Licensed under GNU GPL v3 FAQ I'm using the win64 KSP build and KIDS doesn't seem to be functioning. What gives? Due to the instability of the win64 KSP build, KIDS will disable itself on that build. This is to ensure that any issues caused by the win64 build can be definitively traced back to it. KIDS is not supported on the win64 build, and you are encouraged to use either the win32 build or to switch over to linux, as both of those builds are much more stable.

@Snjo: I'll add that pivot field to the FARControlSurface module and see if I can clean up the code a bit. I dunno how much the Unity project will help though, since I have no experience in working on new parts, only on plugin code. If I do manage to find a solution to something, I'll tell you. @requimrar: The windows being able to get dragged offscreen (to the point where they couldn't be dragged back) was a bug; I'll modify the clamping function so that they can be dragged almost completely off, but not to the point where they can't be dragged back.

Are you testing with the most recent version of FAR? I know that somewhere a few versions back I included some code so that the FAR modules would automatically turn off the stock winglet / controlsurface modules, and if removing the FARControllableSurface module caused everything to be "fixed" that implies that the stock controlsurface module isn't being switched off and that the clash between those is the source of the error. Otherwise the coordinate system looks fine and like everything should work. The modules you have been given are correct, though you've doubled up on modules; if you have control surfaces on the part, use the FARControlSurface module; if you don't, use the FARWingAerodynamicModel. Don't use both, that simply doubles the lift and drag of the wings.

All the code does is grab that transform's vector in world space, convert it to local space, then multiply it by a number to set the desired angle. Are you doing anything that is different from the way the stock control surfaces are set up?

What happens if you move the launch clamps so that they're all arranged along that line of pipes on the orange tanks and clip them through each-other so that you can have the same type of two-tiered clamp system you have going on here? The reason I ask is that the way they're currently attached the upper clamps will tend to pull the rocket counter-clockwise while the lower ones will tend to pull it clockwise; over the length of the rocket that might cause enough movement on physics start to torque an SRB off. How are those giant orange stacks attached to each-other / the central stack(s)? Perhaps that causes enough movement to knock a booster off. Try bracing them to see if it works; you're right that you don't need to brace them for a small rocket, but with a small rocket the SRB is connected to a much smaller mass that will move less on the pad while with that monstrosity each SRB is connected to a lot more mass held together by a lot more springs. Something that might be worth trying with your original post is to retry it, but see if the same part breaks each time; there's a bug where parts added with symmetry don't have the same connection strengths (particularly noticeable with airplanes and wings), so perhaps that is the source of the problem.

@Gamer217: It could be that you have a larger number of high-drag parts on the lower part of the ship. It also looks like your wing-based control surfaces pitch the vehicle down a bit by default; angling them the other way should fix that. You're also using an older version of FAR, which could mean that you're running into bugs that might have been fixed already (though I can't think of any off the top of my head). @Snjo: FAR rotates each control surface around the control surface "right" vector. Make sure that that vector on the "obj_ctrlSrf" object is aligned with the intended hinge and it should work fine.

Post a copy of the output_log.txt right after you cause the bug to occur. I've never experienced this bug on my end though, so I need more specific reproduction steps than "launch and return to space center."

@Tiron: That's because FAR has no reason to think that those parts wouldn't be affected by drag It's possible that those parts have too large area / too large drag coefficient for any of their orientations though. @jbowon: You mean camber? The only way that you can get any camber on wings is if you build it into the wings themselves, otherwise they function as if they are made of thin, symmetrical wing sections. Why? Because there is no benefit to camber at supersonic speeds (it doesn't produce lift but does increase the drag of the wing), and most vehicles in KSP are designed to fly at supersonic speeds. Why not add the option to select whether a wing is automatically cambered or not? This would result in similar-looking wings having very different aerodynamic properties (if one was set to be cambered and the other not), which is really bad from a game design perspective--it makes the game world seem inconsistent when two similar things act completely differently.

@Camacha: I meant that the adapter would still produce quite a bit of drag due to the sudden drop in pressure behind it; the fuel tank alone also suffers from this. I mean that the drag shouldn't decrease a huge amount with that part attached. Sorry, I guess I need to be clearer.

@a.g: Ok, ok. I'll fix that for the next version. @Sparker: The drag for intakes is the new FAR drag + the stock dynamic drag for open intakes. I'll look into the adapter, since making that much drag is qrong, but it should still make quite a bit of drag; it is a very sudden change in diameter, which does produce quite a bit of drag. @How2FoldSoup: Velocity doesn't have much to do with stalling; it's the angle of attack that matters. If you're going 5 m/s but the wings are at 0 degree angle of attack, they won't be stalled, but if you're going at 70 m/s, but the wings are at 45 degrees angle of attack they will. You want to figure out a way to zero your horizontal velocity without increasing the angle of attack too much; try messing with the angle of the vertical thrusters to see if that helps.

I think your confusion is that Supernovy is talking about the arbitrary "maximum_drag" factor that goes into the drag equation, and that you are thinking in terms of "drag force" which does increase with the number of parts. Here's the drag equation: drag force = 0.5 * air_density * surface_velocity2 * maximum_drag * mass * FlightGlobals.DragMultiplier This is worked out for each part, where maximum_drag, mass and surface_velocity are part-specific, air_density is based on altitude, and the DragMultiplier is a constant factor that can be ignored for our purposes. Assuming all fuel tanks have the same mass for this: For your example of 2 fuel tanks vs. 4 fuel tanks, both craft will have a maximum_drag of 0.2; the average maximum_drag of each vessel is 0.2. However, the craft with 4 tanks will have twice as much drag as the one with 2 tanks, because it has twice as much mass. For a craft with two fuel tanks, one with maximum_drag = 0.2, the other 0.1, the average maximum_drag of your craft will be 0.15 (mass averaged), and the total drag force will be 75% of the original 2 fuel tank craft. I think you understand it fine, and the explanation in the tutorial is correct; however, make sure to differentiate between total drag force and the maximum_drag value.

@Tiron: Ah, okay, I see what's happening now. That should be easy to fix.

@Taverius: That's a slightly complicated system, mostly because of how I would need to control pitch and roll to make major adjustments for it. I can look into it. @Frederf: It does save its position and it should spawn minimized if you left it minimized. It only takes one click to minimize it if it's open; the main button above the main window minimizes it all and can be taken care of while the scene is still loading.

Very good, but I want to make one little correction: The section on "distance the CoL is behind the CoM" is correct up until "Too Far" which doesn't equal flip-happy; if the CoL is too far behind the CoM that should be "Lawn Dart / LOL how does pitch up?" "Flip happy" should correspond to "Anywhere in front of" which would help make the information a little more consistent for new airplane designers.

@Taverius: Ah, so my mistakes with net thrust are entirely due to looking at turbofans with decent bypass ratios. I'll see if I can model the stock turbojet as some kind of turbojet-ramjet-SCRAMjet hybrid, and I guess the basic jet is close enough as it is. Thanks for the data and the links. The raycast experiment basically just showed how inefficient raycasting was and how badly wings were modeled with that system. For this system, whenever a chunk of parts separates from the vessel I can simply have the original parent assembly remove those parts from its list, recalculate a geometry of the assembly only in the region that changed (the rest of the geometry staying the same) and create a new assembly for each new chunk of parts. I might have to require it to update the aerodynamic properties very quickly, but I suspect that I can make that run quite fast (at least as fast as it does now in FAR, and most people don't notice it).

@Tiron: It might be some oddity in the model that causes FAR to have problems with the inlet's area calculation. I would suspect that the strange air intake problems are due to the angle of the model transform being used for the "intake forward" direction. Try angling the DSIs off by the amount that the plane yawed off axis and see if that "fixes" the problem. If it does, try reproducing the problem without FAR installed (I see know reason why FAR should affect the air intake behavior, but who knows, I could have messed up somewhere) and tell bac9 about the problem. @Taverius: Ah, yes, finding my screw ups; I've missed you doing that. The ModuleManager config has been fixed on my end. My reasoning for having the thrust maxed at 0 airspeed was that in that situation the engines would be running at Maximum Static Thrust, and that after take off they should naturally back off to Normal Rated / Maximum Continuous / Maximum Climb Thrust for the rest of the flight. I also know that engines do lose some thrust once they start gaining speed, but I guess that once you get into supersonic flight the numbers can change a lot (I haven't found any numbers for this stuff, really). If you happen to know of a better curve to use, point me towards it and I'll make the change. I suppose the best way to explain "assembly-based" is to start off with FAR's current "part-centric" modelling. FAR currently attempts to figure out the aerodynamics of each part individually, with some simple changes for wings that are near each other, parts that are connected to each other, and known cargo bays / payload fairings. What this ends up meaning is that the drag of a part isn't affected by where it is in a stack, what's ahead of it / behind it. It also means that wings aren't modeled as one aggregate piece, but as a bunch of arbitrarily-shaped lifting chunks. Calculating induced velocities is almost impossible (so FAR doesn't bother currently) and each part needs to to run its own aerodynamic calculations. This is not only computationally wasteful, but the physics are (technically) wrong, even though they follow general trends and come close to being correct in most cases. In other cases (such as people using structural panels to build stock fairings) FAR simply fails completely. The "assembly-based" approach is to group the parts into collection of fuselage / nacelle shapes and wings; each of these fuselage and wing assemblies can then be analyzed to figure out the proper aerodynamics (and with probably no more than ~10 assemblies per craft, this means fewer calculations to run) and they can then apply the proper forces to each part. For a fuselage, if you surround an ugly assembly of parts with structural panels to make a fairing, it will act as a fairing under this scheme. If you build a hollow cargo bay, as long as it is closed it should naturally shield the cargo inside from the incoming airflow. Depending on how things go, I should be able to add support for induced velocities, some area ruling and some amount of multithreading, further reducing the computational load. So better performance and better aerodynamics, ideally. Of course, right now I'm sitting here trying to work out an algorithm to get the cross-sectional area of a group of meshes on a particular plane that intersects some of those meshes.

@Taverius: Nope, FAR doesn't auto-calculate e, and the current part-centric version probably never will. The more assembly-based version I'm working on will have to though, but that's a bit in the future.

@TomatoSoup: I believe that MechJeb constantly updates the aerobraking prediction, so FAR would have to apply the proper drag values to the fuselage parts and then remove it at the very last second as the atmosphere starts, though that would result in the aerobraking prediction going to hell the second you got into the atmosphere. And even then, the aerobraking prediction would only hold if you had no lift on the vehicle. It would just be easier for me to code my own calculator for it. @Delta: You're making sure that the fuel line runs from the wingtip fuel tank directly to a fuel tank stack that does feed the engine, correct? You might get away with a fuel line connecting the fuel tank to the wing and then the wing to the main fuel tank stack, but I think your issue is that you're expecting fuel to drain in the reverse of the way it is coded in KSP. @Senshi: It's B9 doing something weird... For some reason the area values for the inlets is not only wrong but different for each inlet, which makes this a particularly bad bug. I will look into that. @Pyromaniacal: The plate was much heavier than the nosecone was, shifting the CoM backwards more than it shifted the CoL. It also looks like there's an RTG in there that is connected to the plate, which would shift the CoM further back as well.