ferram4

I'm not actually seeing anyone saying that different aerodynamics should result in the same forces on the vehicle, and thus, identical behavior. I do see people saying that regardless of what aerodynamics you have, if you produce the same loads on vehicles, that they will behave the same way, without regard for where those forces come from. You can blame NEAR for the loading that caused the failure, but you can't blame it for changing the structural integrity of the vehicle, because it doesn't. But you're right, stock aerodynamics do not allow for disintegration except at very, very high velocities and densities so that the effects of the lower drag for nose cones and the higher drag for parachutes can have a significant effect., overpowering the mass-based drag that makes sure that drag accelerations on (nearly) all parts are identical. Even the Stock Drag Fix will cause disintegrations like NEAR does.

There is a link to the in-dev wiki on GitHub in the OP. There are also help buttons in-game. Most of the stuff can be found out by looking through aerodynamic simulation textbooks.

@Starwaster: He means the stock "joints break under a certain amount of stress" not FAR's "Oh, you're hitting this amount of force? The part should be torn apart" feature. If stock drag applied drastically different accelerations to different parts, stock would have a damn easy time of tearing rockets / planes apart. And at that point, it's the stock joint physics that cause the failure.

Aye, and with FAR, aspect ratio and chord and sweep angle all do matter; they have for a very long time. So your complaint is...? It's not true for only well designed planes, just ones that aren't over-thrusted, over-weight and under-winged. Incidentally, the way that KSP's stock model teaches people is to build over-thrusted, over-weight and under-winged vehicles (at least compared to proper design), so I don't think that's a problem with realistic physics; I think it's a problem of being taught wrong from the start, and then slowly, over time, planes with TWRs > 1.5 at liftoff and wings the size of a fly are considered normal and intuitive, along with rockets that start with a TWR of 2 and make a 45 degree pitch maneuver at 10 km.

But (I'm guessing) you do find flight simulators intuitive. So what is the difference between flight simulators and KSP + FAR? Besides the lego-plane/rocket design part.

One of the biggest complaints about FAR was that it had a GUI. So NEAR does not have a GUI because that was one of the things requested by users when I was looking for feedback on a simpler aerodynamic model.

Yep, and that looks just about right. Considering the F-15 has two engines capable of 67.9 kN dry, 105.7 kN wet each, and they almost never take off with full AB (why would you? It burns fuel like mad), that should result in (for the heaviest numbers there, 27.2 t mass) that the plane should reach rotation speed (66.8 m/s) in 13.38 s dry, 8.59 s wet after starting its run (having covered 446.9 m and 286.9 m, respectively), before lifting off at 92.3 m/s approximately 18.49 s dry, 11.87 s wet (covering 853.3 m and 547.8 m, respectively). And this is with a plane that has, fully loaded at take off, a TWR of 0.792, and it's taking off this quickly. If your TWR is higher, this will inevitably be worse. Notice how low the takeoff velocities are, and notice how low the TWR is. Most KSP planes take off at higher speeds with higher TWRs, and this leads to planes being much more failure prone due to piloting and design that provides much less leeway than real-life designs have.

@m4v: Ah. So basically, you did exceed the TWR and velocities then. Good to know. Btw, why don't you post the velocity chart that goes with that image? I'm sure it would be quite enlightening about proper takeoff velocities.

Did you rotate and take off below 100 m/s (223 mph, 360 km/h, 194 knots)? Did you keep your AoA low (< 10 degrees)? Did you consider the TWR of your plane, and keep it around 1 for a high-performance jet, and 0.3 for a heavier vehicle? If no, to any of those, you have suffered exactly what would have happened as a result of poor piloting / plane design. Edit: Compare your designs to the example craft included with FAR. Anything closer to the Hypersonic Demon than any of the others has too much thrust. Proper design of a high-performance fighter looks like the Thunderbird, and for an SSTO, the Velocitas. You need to consider that jets are just as subject to "add engines until TWR -> stupid" as SRBs are.

Guess what? FAR includes that. No one uses it though, which is kinda sad. If they did they would understand how fast they were going.

If a jet engine wasn't able to push you beyond 100 m/s at sea level, how would jet fighters be able to reach Mach 1.2 (408 m/s) at sea level? Besides that, if you didn't have the excess thrust to pass 100 m/s, how would your vehicle be able to produce the work necessary for it to gain altitude? After all, something needs to be able to produce the energy to fight losses to drag / gravity, and if drag is already eating all of that energy on the runway, there's no way for it to get into the air. DRE is set up to model realistic aerodynamic heating and FAR is set up to model realistic aerodynamic forces; how are you getting "incompatibility" out of that?

The only person arguing for a planet with a not insane density said this, which you conveniently ignored the last part of: No, the version of the game for teaching people about real space shouldn't have the realistic solar system as even an option. Everyone else hasn't even argued for such a thing. Once you account for that, realistic aerodynamics don't result in realistic reentries because the orbital velocities are lower. Then again, realistic aerodynamics here just means, "streamlining actually accomplishes something rather than being detrimental." You are too focused on the scale issue, like pretty much every other person arguing against realism. It's frankly disheartening, since it means that rather than arguing about how realist we want things we end up on tangents about 70 minute reentries (for only one specific type of vehicle, even) that will never be in the stock game because (get this) no one wants them in the stock game!

This is not a problem of unintuitive aerodynamics, but a problem of scale. Did you take off at anything above 100 m/s? Yes? Then you were going faster than every single real life plane ever on a takeoff roll. Go and watch planes take off at an airport and the fastest you will find is ~80 m/s, with many taking off at slower speeds. This is actually a problem of scenery; there's never any proper-sized trees or anything near the runway to provide a sense of scale. No one has any appreciation for the fact that 340 m/s is the speed of sound at sea level, and that getting up to even half of that and pulling back on an overloaded craft is enough to destroy it. People already understand that putting something on the outside of a fast-moving sportscar can lead to that something being destroyed by aerodynamic forces if it isn't designed for them. Now if there was a way to show people in-game that they were moving about twice as fast as those cars are on the ground for a lower-than-normal-KSP-crazy-speed takeoff, they would understand the forces involved. Saying that it doesn't feel intuitive just means that you don't have a feeling of how fast you're really going in-game, and that's a failure of the game that should really be fixed.

There's already some conduction code in there, although it needs a lot more work. Convection and radiation seem to work pretty well, but conduction seems off to me.

Peace tater; we have been complaining about how some of the not-fond-of-realism crowd have been fond of using strawman arguments to dismiss all realistic arguments; we shouldn't do the same to them.

Aye, that's why I don't like that definition, and instead have mine. Mine is solid, clear and presents an obvious solution to fixing it (make jets have thrust vary with ambient air density as they should); the common one is highly subjective and is thus pointless. We're not in disagreement there. You make it sound like you'd be incapable of building a plane that could fly at the edge of the atmosphere. Sure, you could build one with properly-behaving jets, but it would require designing to a lowest mass, lowest drag optimum rather than a "more intakes, more intakes, more intakes, more intakes" solution. And from my experience, trying to optimize something like that is certainly more fun than figuring out exactly where you can stick another bunch of intakes for a single jet engine. Oh, btw, did you know that once you account for the different scale heights between Earth and Kerbin that you're talking about flying at 60 km? Now granted, this is a good 1.5x the current jet-propulsion altitude record, but it's certainly possible to sustain flight there, though it'd be difficult and require fairly massive engines for the plane to produce enough thrust. So even for what you want to do, it's still doable with those changes. Just different.

How so? Most of the suggestions are based around how realism aspects would make standard intuition more useful in the game, which should make it more accessible to new players. A lot of the current unrealistic stuff just makes the game more confusing (do you remember when you learned nose cones were useless? Does that seem logical? Did it make you more confused about how the game worked?), not accessible.

You're gonna have to shift to a multiple-part setup to get that to work. FAR and NEAR simply aren't designed to try and make sense of wings-and-body-and-cargo-bay as one part, and trying to do so would lead to some very weird aerodynamic effects. Just warning you, you'll need to break it up into multiple parts or (like pretty much every other shuttle mod conceived without considering FAR / NEAR integration from the start), tell people that they're out of luck.

It's quite clear and simple: is the ratio of the thrust that this engine produces at altitude compared to that at sea level greater than it should produce in real life? If so, it's airhogging. You'll note that this ends up meaning that any flight above SL is airhogging to one degree or another under this definition, but the lack of variation of thrust with altitude is the root cause of airhogging. IMO, it is only fun in the way that turning on infinite fuel and slapping a mainsail under something is fun. There is no challenge, no design considerations, nothing to make using plain rocket engines favorable in comparison to jets. It's the "fun" of defeating all the previous challenges all at once by changing the rules so that they aren't challenges anymore, and once that novelty wears off... it's not fun anymore. And besides that, there is the issue that the GUI lies to the player about the engine's efficiency. You can argue that the engines should be as broken as they are, but at least show everyone how broken they are and stop the GUI from lying about it.

Airhogging is exploiting the current intakeAir / jet-engines-that-aren't-really-jets model to produce thrust at altitude that is far beyond what should be possible there. A jet engine can only produce the same thrust at sea level and at an altitude where the pressure is nearly 1/10 that of sea level if, and only if one of these two conditions is met: 1) The engine only runs at 1/10 throttle at SL. 2) The engine magically grows to 10 times the diameter (somehow) as altitude increases. Obviously, for truly space-skimming designs, this would result in engines either running at ridiculously low effective throttles on the runway or growing ginormously as the plane gains altitude. Needless to say, jet engines do not work that way. There are quite a few situations where jet engines are currently overpowered in this game, to the point of why would you use anything else for boosting your first stage of a rocket: 1) Thrust does not decrease with ambient air density in a logical way. 2) TWR is much higher than it should be, given that jet engines should have TWRs lower than rocket engines, not higher, as it is currently in KSP. 3) Engines are ~16 times as efficient as their Isp reports, since the true definition for Isp only considers total mass flow out of the vehicle (which excludes intake air, since equal amounts enter and leave, cancelling out), but KSP counts that intake air mass flow in the calculation when it shouldn't. 4) One jet engine is not capable of running at both Mach 0 and Mach 7 like the stock turbojet is. It's a joke. The state of jet engines currently is that not only are they completely and utterly broken, but they don't even act like jet engines. It's sad that SSTOs are so much easier to build than simple rockets, because all you need to do is stick on a single tank of LF and you have enough dV to put a decent payload nearly into orbit with a turbojet. I don't think it's too much to ask that turbojets not be "achieve orbit on nearly no fuel" engines.

@Rib: I'm looking into adding an estimated range readout to the Flight Data GUI, but it will end up severely underestimating the range of the plane because Kerbin's orbital velocities are so low that the effective reduction in gravity due to flying so fast will have a significant impact on range. @Wanderfound: Yeah, there's no reason FAR should prevent that from loading. I suspect another issue on the user's end. As for that odd interaction, that makes no sense: if both engines are producing the same amount of thrust in airbreathing mode than they will be applying the same amount of thrust. The only way this could be interacting is if there is some odd stock bug that you've run into. Also, your link is shortened and so it goes nowhere.

Most of those floating point errors are simply due to the fact that the shape of an elliptical orbit can be greatly affected by tiny changes in velocity at periapsis. Well, once Krakensbane kicks in, there are only two sources of changes to velocity if the engine is shut off: any errors due to failure of conservation of momentum due to rotation, and errors in the simulation itself. With Krakensbane active, the latter are a constant size, which means that higher velocities will reduce floating point errors due to that. Errors due to rotation are also relatively constant, since higher orbital velocities don't magically make rockets spin faster in space. So then that would result in lower floating point errors as well. Note that all those statements are relative to the absolute magnitude of the exact velocity magnitudes. The ship-breaks-apart bug was not the original bug to be fixed by Krakensbane. It was floating point errors due to loss of precision in velocity, which would cause phantom forces on the vehicle, whihc always cause you to lose control long before the rocket could be destroyed. Anyway, all of that said, in time warp the only significant numerical errors are in crossing SOIs, simply because the numerics required to solve true anomaly of the orbit (angular position relative to periapsis) as a function of time are relatively simple-ish and can be clamped every half-period. Interestingly, since a larger universe would increases the size of SOIs (especially if the distances were increased to much more realistic sizes, since they're a little too close for proper scale), the SOIs would have a larger area of lower gravity gradient, reducing errors due to jumping a little too deep into the SOI, since gravity doesn't change as significantly. Hmm... I wasn't for scaling up the planets more than absolutely necessary to deal with aerodynamic effects, but considering those effects (unless I'm horribly wrong), it would be better to make it even larger... This requires some more thinking.

Except it doesn't. Floating point errors are well taken care of by the floating origin system and Krakensbane, and players of RSS do not run into more floating point errors. Hell, the higher velocities overall would result in Krakensbane being kicked in at much "lower" (relative to orbital velocity) speeds, which would reduce floating point errors overall. I should point out that Mun orbit is at velocities below the Krakensbane limit, and so the Kraken still causes issues in Munar orbit; increasing the size of the Mun as well as Kerbin would increase orbital velocity, possible bringing it above the 750 m/s needed for Krakensbane and the removal of some of those floating point errors.

The problem with airhogging, in any form, is not that you can add an infinite number of intakes without any problems. The problem is that jet engines do not vary in thrust with ambient air density. In the real world, a jet engine's compressor can only process so much volumetric flow; this causes airflow through the engine to be capped at some multiple of the ambient air density, and since thrust is proportional to mass flow through the engine, that causes thrust to reduce as the engine goes higher up. The problem is not solved effectively by setting new rules on intake air usage. It would better be solved by developing a new jet engine module that could only process a certain amount of volumetric flow, and intakes set up to provide a certain amount of volumetric flow. If the intakes don't provide the volumetric flow requested by the engines, thrust decreases. If the intakes provide more than the engines can process, add more drag. Problem solved simply, efficiently, logically, and realistically.

@Dre4dW0rm: You're reaching nearly 2.5 times the average take off velocity for jets without getting airborne. At that point, your problem is not thrust, it's lack of lift. You're either going to want to look at adding more wing area / reducing mass if you're capable of rotating properly, and look into placing the landing gear further forward if you're incapable of rotating for take off. @BadManiac: If your rocket immediately lost control after slightly touching the controls, that means that it was barely stable and that you had too much control authority. That said, I'll admit that I don't quite believe you; a rocket that unstable would have flipped long before attempting the gravity turn unless it was completely dependent on SAS to maintain control. @arkie87: I think you are underestimating the interconnectedness of aerodynamic phenomena. Removing stuff from FAR in a way that didn't make things horribly unstable for NEAR was a challenge in itself, and even then, NEAR still has a lot of places where you can end up with unstable and nasty things that FAR doesn't have because removing proper aerodynamic effects causes weird things to happen. If I left all those options in I'd be inundated with people complaining that their rockets / planes were unstable when they disabled something that would have aided in making them stable. It would be great if all my users were aeronautical engineers and I could do that. As it stands though, they aren't, so I can't. It's not like people ever touch the options anyway, people always say they're dropping FAR because of the aerodynamic failures despite the fact that I added an option to get rid of them. @MunarJetman: It takes ~1000 m/s of dV to get up to an altitude of 100 km based on gravity alone. You launched a rocket with 2.3 km/s of dV. Drag is not a force that is equal to gravity by any stretch of the imagination, so that result kinda makes sense. Same thing happens if you launch a rocket with that much dV on Earth too.