ferram4

@elfindreams: I'll see if I can reproduce it. Probably some variation of the issues I've been tracking down. @Entropius: Wiki has information, as does the help function on the GUI, which is the big button with a "?" on it. You should click it. @Hodo: Nope. Compatibility broke due to support of the new AppLauncher system. @nickexists: Engine thrust is not affected in any way by the aerodynamic failure setting in FAR. Further, FAR does not change any engine behavior besides to slightly nerf the jet engines, though no where as much as they should be for realistic behavior. Other than that, all engines are left with the thrust and efficiency they have in stock KSP. If you would prefer more realistic jet engine behavior, you'll have to get AJE, since that is outside the scope of an aerodynamics mod.

Terminal velocity in NEAR is not terminal velocity in stock. You will not reach terminal velocity in NEAR or FAR without losing control of the rocket long before then, so any terminal-velocity-chasing shenanigans are fruitless. In fact, terminal velocity in NEAR will be higher than in FAR, since there will be no supersonic drag effects to force terminal V lower. Unless you can manage ~400m/s at the pad and have it increase with decreasing air density, you're not gonna hit terminal velocity and you shouldn't waste time bothering.

Fine, here's an easy example of an aerodynamic force without acceleration. F1 car driving on a racetrack; aerodynamic lifting force pushing it down. Movement of the car downwards is blocked by the ground, so there is no acceleration downwards. Still, there is an aerodynamic force there. Surely, you can imagine that force being enough to bend and break those aerodynamic features, right? What about aeroelasticity, where wings break despite relatively low g Forces on the vehicle because they have been twisted and bent by aerodynamic forces? Acceleration is not the end-all-be-all of things failing. Only stress is.

Alright, NEAR v1.0.3 is up, fixing the shielded-in-the-editor issues as well as some more null ref issues. @Dr. Jet: Well, yes. User feedback for what people wanted that was not FAR not only included removing some complicated aerodynamic features but the attitude that pretty much all the information was unnecessary, confusing, or useless. So it isn't available with NEAR. As for things falling apart with FAR, it's not hard-coded, but it's quite possible for things to come apart at 2g. It's quite possible for wings to come apart at 0.001 g, it's not like the mass of the fuselage reduces the forces on the wing. By that logic a string could hold up an oil tanker so long as the string wasn't accelerating.

@elfindreams: I think the latest hotfix might have fixed it. Try that out. @DaMichel: Confirmed, fixed, and pushed. @Sabazi: There will be a new NEAR version incoming soon. Keep in mind that the PartModule classes are identical in FAR and NEAR to reduce the likelihood of bugs creeping in due to mismatched names as well as providing support for mods that already have explicit support for FAR. @klikkolee: The ones I know off-hand are Flight Stability And Automatic Control, 2e, Robert C. Nelson, ISBN-13: 978-0-07-046273-1 and Aerodynamics, Aeronautics, and Flight Mechanics, 2e, Barnes W. McCormick, ISBN 0-471-57506-2. So FAR v0.14.0.2 is up to deal with some more nullref issues I came across and fix displaying shielding from cargo bays and payload fairings in the editor.

@Maramusine: That implies an improper install for previous versions of FAR. FAR has never been able to east away several km/s of dV during launch. @Dinokin: Then you can certainly provide explicit reproduction steps to cause the issue, correct? @lammatt: Nope, that's the way drag is in real life. Planes do need to be very careful to control their descent rate or they end up going too fast and being destroyed by aerodynamic forces / not being ale to land because they're going to fast. Unless you're gaining speed while descending at a rate of less than 5 m/s, there's no issue. @AndreATGB: Yeah, I'm gonna switch away from TAS, but that error looks like it's outside what I can control, since it's inside Unity. Unless you can provide reliable reproduction steps there's nothing I can do. @elfindreams: Based on the logs there is nothing clearly going wrong, although I see that you're using a very large number of mods and not all of them may be up-to-date for KSP 0.24. I'll need a lot more information to reproduce the issue, since you have not provided any reproduction steps whatsoever. Surely, all the ships that have this issue have something in common, right?

@Dr. Jet: It is an error only in the VAB / SPH. Flight tests indicate that fairings function properly.

Well, for a delta wing plane with no flaps that isn't completely insane for a stall speed. It's kinda high, but that seems about right, especially considering that the rocket engines are pretty heavy.

@Dinokin: If that is a craft file from before 0.24, you will need to follow the directions given at the bottom of the FAQ in the OP / in the past few pages to uncorrupt it. If you had read the past few pages, you would be aware that it is a known issue and that there is a known fix. @dewin: Noted. I'll fix that when I get a chance, but given that the number of support requests hasn't died down enough for me to determine what is and isn't a valid bug, I'm not making another release and making things even more confusing for people. @klikkolee: Search for "Stability Derivatives" and you'll find resources on it. Searching for "airplane stability and control" might also bring stuff up. A final thing to try is to see if you can find the USAF Stability and Control DATCOM, since that should also include information on that. Sorry I can't point you somewhere good, most of the data for that has come out of my textbooks.

Nope, it's version 1.0.2. I'm bad at getting metadata correct.

There doesn't appear to be any data in there pointing to NEAR. I would advise you to make sure that all your mods are absolutely confirmed fully compatible with 0.24 and remove any that have a hint that they might be incompatible. Then wait for them to update.

Are you using NEAR v1.0.2? That version was pushed to fix that error.

More drag overall would be bad, since that would make things more unstable as well; since a lot of rocket designs end up being "stable" only because thrust vectoring is sufficient to keep the rocket on course, those would suddenly become unstable. It would also make the atmospheric cutoff a lot more jarring as well. Finally, drag is just about right for reentering capsules with the current settings, and increasing drag too much would simply make returning to Kerbin damn boring. If you wanna find out, go into the NEAR directory in GameData, open up NEARAeroData.config, find the areaFactor value and set it to something above 1 and see what you think. Reentry becomes boring as hell (for which the only solution is to remove drag dependence on shape, and now we're back where we started) and rockets become less stable. Not fun at all. I've always found the dV requirement argument to be lacking, especially in the face of the new stability requirements on rockets. That's always struck me as the argument of people who already build ideal aerodynamic vehicles who don't realize how difficult it can be for new players. It's funny, it's led to people arguing that FAR is both "cheaty" and "absurdly hard" at the same time, which leads me to the conclusion that FAR (and probably NEAR as well) are balanced, but different from the stock game. Then the judgments on difficulty make sense in the context of players with differing skills in one area or another. The stock engines aren't really overpowered for a real atmosphere, they're about correct. The jet engines are broken though, but that's because they're really magical air-breathing rocket engines and changing those around too much really falls outside the scope of an aerodynamics mod.

@Kingsix: You'll need to post a copy of your output_log.txt from KSP_Data and a full list of reproduction steps. So far, your bug report does not have enough information to determine what, if any, behavior is due to NEAR. @rynak: No, I know exactly who I'm targeting, and I'd argue it's no more hardcore realism than the rest of the game. This is a game where gravity is the primary thing that causes you to fail. Gravity doesn't magically become weaker when the player needs it to be to survive a bad situation. This is a game where off-center thrust will cause things to go spinning out of control. The CoT doesn't magically relocate itself if a player screws things up. This is a game where things can flex all over the place and cause vehicles to lose control and possibly break as a result. Parts don't magically act like they are somewhere they're not to save the player. Why should aerodynamics be different? Or should the game be made easier in all these other fields as well? Should gravity at Kerbin's surface become weaker if you're falling uncontrollably towards it and you lack the thrust to arrest the fall? Should sideways-thrusting engines simply not matter in stability if they're making things too bad? The game already smashes bad designs and piloting in the face, but the good thing is that it's consistent. You never have to rely on the physics bending to save you. But let's say I were to add something to force planes to aim forward. Okay, define forward. Easy for a simple plane. Easy for a rocket. What about for a crazy contraption? Once you've built the expectation that if a player intends a vehicle to be stable in what they think is forward, you have to apply it everywhere. What happens if a player suddenly changes the reference part for controlling, so that their plane is now "facing backwards?" Does the plane suddenly become unstable? Do you simply ignore that and cause one direction to be privileged above the others in terms of stability? If you don't, can't that be exploited to cause really weird things? KSP is not like other flight simulators in that the player has too much control over what is happening and any attempt to subtly save players from themselves will either cause blatant violations of common sense (followed by raging), provide easy means to do things that cannot be done in real life (Scott Manley's Tony Probe coming out of the old RCS code that made it impossible to build something that wasn't easy to control with RCS), or simply cause players to decide that the game makes no sense because, well, it's acting contrary to how they see reality. So, how do you solve those problems?

@rynak: Well, the first thing to remember is that most flight simulators are already working with stable aircraft; KSP has no guarantee of that, and unless a plane is designed exactly right there's no way a control system can keep its instabilities under control. Then vehicles need to be designed to make recovery even possible; there are very specific things that need to be done to aircraft to make them want to come out of stall and allow them to come out of spins, and if a player doesn't add those (forward lift surface stalls first, tail has lots of control authority) you'll never be able to remove the issue. Even if we had SAS that was capable of saving players from their mistakes it would only work if the mistakes were pure piloting and within a certain tolerance. The only way to maintain it within a certain tolerance would be to have always-on SAS, which would annoy good players and allow poor pilots to blame something external for their failings (even though it's off by default in FAR, that ended up being the reasoning used by some people and is one of my reasons for removing the control systems from NEAR). The ultimate problem is that it's not just an issue of piloting. It's an issue of vehicle design. No amount of SAS can save a bad design short of reaching into the physics and changing them to save the player, which seems very... wrong. How is the player supposed to learn if the world isn't consistent and its laws will bend to save them? And that's before the condescending aspect of it, since it basically comes down to the developer saying, "We don't think you're smart enough to learn how to handle this."

But that kind of compromise doesn't make any kind of logical sense, especially since it would make trying to figure out if something will work much more difficult. You wouldn't be able to simply ignore aerodynamics, like in stock KSP, nor could you base stuff on real life; it'll be some halfway that will leave everyone more confused in dealing with a feature that is certainly not an easy thing to deal with. To me, arguing for drag depending on mass (in any way) is akin to arguing that the orientation of rocket engines shouldn't matter, that they should just work, regardless of where they're pointing. Neither one is realistic, neither one really makes sense, and both are only fun in the way that ignoring reality is fun, but then it becomes boring because the challenge is gone.

@jmanidb: I think you expect an easier aerodynamics model that still disconnects drag from mass to protect you from the effects of disconnecting drag from mass. The simple fact is that those instabilities are inherent in removing that connection; all of the mods that remove the drag dependence on part mass add instabilities of some kind, and there is no way around that. @panarchist: Yes, those should function properly. @MainSailor & Renegrade: I've confirmed the issue. Seems to be related to a few changes in how PartModules are saved to work with the new contracts system, and it might take awhile to resolve the issue. Edit: Was easier than I thought, forgot to bring some code from FAR over to fix that. Version 1.0.2 is up to fix that issue.

Crashes are not things that I can fix, they are the result of something breaking in the base game. I would advise you to remove all your mods and attempt to reproduce the issue without any of them and submit a bug report to Squad. In addition, the error.log alone is useless, since it doesn't tell me what broke in the game. I need the output_log.txt.

Considering that the main issue with aerodynamics simulations ends up being performance, that gets priority over conforming to a silly, reality-contradicting system. All of the aerodynamic data in FAR and NEAR is easily accessible by any plugin that wants to look at it, and so it's perfectly possible for plugins to interface with either to make things work. Given that both are a fair bit different than the stock drag model, I wouldn't expect anything coded up to function witht he stock drag model to even work properly. Anything that runs on that system will also assume drag is independent of orientation, making it inaccurate. Hell, I'd argue it's better to be obviously inaccurate (which can then be disregarded) than inaccurate but plausible, which leads to people taking it on faith. In any case, given that user feedback pointed to the utilities provided with FAR being unwanted, I can't see how anyone would really demand to have NEAR function with information / autopilot plugins, as those features should be similarly unwanted.

No it will not. MJ does not know how to account for drag that changes with orientation. If it did, you'd be able to do that in FAR as well.

@Volt + MainSailor: This is a result of having used crafts that were built using the previous versions of FAR, caused by a change in how KSP saves PartModule data. There is a how-to fix here. If you could provide complete output_log.txts for that, it would be helpful in tracking down the exact place where it starts to break. @panarchist: Well, it would help to say what FIDO is, since a search for it came up blank for mods. @Mihara: No, because using the Stock Drag Fixes' method would require more calculations (in particular, ones to deal with the total mass) than necessary to apply physics, making it far more expensive to run. I dislike doing pointless things like that.

@Onche: If you had searched the thread, you would have seen that this suggestion had come up many times before, and that my response has always been that attempting to implement it resulted in no noticeable change in aerodynamics but a noticeable drop in performance. So no, it is not worth it. @Marasmusine: That was possible in previous versions as well, courtesy of launching a rocket with 2.3 km/s of dV. Considering that FAR reduces drag from pudding levels to realistic ones, and the gravity losses getting to approximately 70 km is ~1 km/s, I'm not sure what you expected. If you're upset by this, I would suggest installing Deadly Reentry to balance it out. @Roaken: Changelog is in the zip and the OP. Supersonic drag was also modified slightly, as it was way too high; perhaps your vehicles are over-engined. It is also possible that your craft files have been corrupted and you need to follow the directions I gave to Advacar to fix them. @Konnor: In the real world, no. In KSP, where all airbreathing engines have ridiculous thrusts unless you use AJE, yes.

It's expected behavior if you have enough thrust relative to drag. The trick is to keep it under control at those speeds.

@GregroxMun: Funny, I always thought the possibility of horrendous failure caused by poor piloting was more fun than the alternative. It actually makes launches exciting and eventful as opposed to a routine like it is with the stock model. I'm also not sure what you mean by "authentic," because it's certainly not authentic aerodynamics by any stretch of the imagination; it's just too far away from reality to be believable. @rynak: Wing parts still need the configs to function properly, but the overhead for wings in NEAR is greatly reduced. The overhead for other parts (which was always low to begin with) has reduced slightly with NEAR, but not quite as much as for the wings. SDF actually has to do quite a bit of work, since it needs to iterate through all the resources on a part to get the total mass of the part to properly scale the coefficients around; this is also done by the stock game itself, but since that value doesn't seem to be stored anywhere, it needs to be calculated again for SDF to use it. There's more overhead there then you think. It's not much, but it is quite a bit more than "free." @Themorris: Surprisingly, even without FAR's structural failure code you can produce forces that are enough to rip things apart, which means that you really overdid it. NEAR does not have any of FAR's code to force aerodynamic failures, since that's the first thing I stripped out of it. It's not a bug, it's stock behavior.

ModStats does not affect the performance of any mod that it is packaged with. For your other question, it would be better to ask it in the ModStats thread, as I don't know the details.