ferram4

TL;DR: KSP.log is not as useful as the output_log.txt (or Player.log) files, but is more prominent to the user. This causes users to inadvertently upload the less useful KSP.log file in place of the more detailed output_log.txt (or Player.log) files, delaying diagnosing issues for Squad and mod developers, and delaying providing users with solutions. KSP.log should either not be created by KSP, or it should be made as detailed as the output_log.txt (or Player.log) files to streamline support for the stock game and for modders. For those who don't know, KSP currently writes to two different log files when it is playing. One is a detailed log file (henceforth output_log.txt) that (I believe) is created by Unity, and it differs for each OS; KSP_Data/output_log.txt for Windows, Player.log for Mac, and I believe something similar for Linux. The other is the less detailed KSP.log, which is universal across all OS's. The output_log.txt includes the valuable stack trace, which (in layman's terms) is a list of all the functions that were called when the error occurred; this allows the developers to quickly look at the stack trace and see where the error occurs, which gives a starting point for debugging. The KSP.log does not have a stack trace, and is therefore useless as a log for diagnosing severe issues. This is even acknowledged implicitly in the support guidelines, since they ask for the output_log.txt instead of KSP.log. So we have two logs, one useful, the other useless. But the average user doesn't know that KSP.log is useless, and that output_log.txt is useful. So if a user makes a bug report (for the stock game or for a mod), there is a chance that they submit a useless log. It's even more likely that they submit the useless KSP.log since that exists in the KSP root, while the more useful logs are hidden away in subfolders. So why does this matter? Well, if a user submits KSP.log instead of output_log.txt, one of two things happen: User doesn't follow up, bug cannot be diagnosed, bug report becomes useless, bug doesn't get fixed. User does follow up, becomes annoyed that what they've done so far is useless, everyone gets annoyed, especially if the initial report didn't include a log in the first place. As things currently stand, this makes getting support a lot more difficult than it should be for users (since they're inadvertently providing useless files) and makes diagnosing issues more difficult for Squad and modders alike, since they're getting useless logs. KSP.log's existence does not serve to help with support of the stock game or mods and only serves to confuse users already suffering from issues. Therefore, KSP.log should either be removed or should be made into a copy of output_log.txt that is simply dropped into the KSP root for easy access.

That's not the output_log.txt. That's KSP.log. Go into KSP_Data, find the output_log.txt, and that will have a stack trace to the problem.

@illectro: Video added to the OP, because it's fun. @DaMichel: Noted, confirmed and fixed. @R0cketC0der: [More nitpicking]Technically, a sphere will produce lift due to vortex shedding over the back surface, and this is relatively unaffected by surface finish. The lift just won't be in any easily predictable direction, hence why knuckleballs are a pain to hit[/nitpicking] So, version 0.13.3 is out, including a Scott Manley-requested feature, the ability to change things in-game via a GUI. It's in the space center, pretty much every setting available can be fixed. Also, includes fix to DaMichel's issue. Also includes a fix to atm composition, which the changeover to ConfigNodes for 0.13.2 broke. And tweaks to the default control surface aero-failure strengths.

@Tiron: Yeah, that would be the spiral mode. Most of the time pilots subconsciously fix that, so a lot of planes in real life have slightly unstable spiral modes. It's easier to control a slightly unstable non-oscillating motion than an unstable oscillating motion (or even a stable one). @Sauron: Move the wings back. Like everyone else is saying. @jstnj: The game crashed. As in, actually crashed to desktop. What did you do just before that happened, and what does the error.log that should have been created from the crash say? If it has something, something, AccessViolation in there, then you ran out of memory. If that's the case, there's nothing much I can do, since if adding a few parts to the ship is enough to crash the game you're running right on the edge of having too many mods.

@ObsessedWithKSP: Nope, that's in the editor, it won't affect things here. Completely different issue (and I minor one at that, it doesn't affect behavior). @Klingon Admiral: I just attempted to reproduce your issue by launching a rocket with KW fairings and detaching them above the atmosphere. On atmospheric reentry they continued to accelerate towards the ground, flipping around from aerodynamic forces before burning up. I'll need reproduction steps before I'm able to determine the cause, if it's even on my end. Make sure all of your mods are running the most recent versions too. @DaMichel: That effect might just be the result of how FAR looks for nearby wings. It probably shouldn't be that dramatic, but I don't know if there's much I can do.

@Klingon Admiral: I'll need a list of all the mods you're using as well as a copy of the output_log.txt. That sounds a lot like something breaking horribly, but I need more information. @Tiron: Good to hear. The only thing is that the lessened dihedral stability will also tend to destabilize the "spiral" mode, which is a type of motion where the plane starts to roll to one side or another and then continues doing so, eventually going into a spiral trajectory towards the ground (note: not a spin, that requires stalling). It's mostly unnoticeable in real life aircraft, since the pilot tends to subconsciously correct the motion away, but in KSP it can be a little bit nastier. @Amaroq: Because for some reason donate buttons bother me. Can't explain it, they just do. @smunisto: Anhedral is only good in very slight amounts for reducing the dihedral effect on planes that have too strong a dihedral effect to begin with. That would mean planes with high wings, planes with very highly swept wings (especially ones at high angles of attack). It's a subtle change, not a "throw tons of it at the plane, the more you add the better it gets" kind of thing, since it also tends to make the plane unstable in roll, particularly at low angles of attack. Subtlety is key in designing planes; your redesigned version isn't going to like what you've done to it. You might be best served by just adding a little bit of anhedral to the canard or horizontal tail (if even that) and leaving the rest as they were.

I don't know if the earlier versions of ModuleManager will handle the new config syntax properly. Regardless, all of the mods will be switching over to Module Manager 2.0.x soon, so if it is a config error from another mod that mod will have to become up-to-date.

@Kalista: Go grab FAR v0.13.2.1 or Module Manager 2.0.5. Known issue with Module Manager 2.0.3.

It's probably more the lack of a strong vertical tail. You probably want to copy the wedge tail more than the anhedral for this case. You'd probably be fine with no dihedral or anhedral on this, the sweep should be enough to make it work.

Check the settings menu for the AerodynamicFX slider and drop it down.

@FenrirWolf: It's a craft file. KSP isn't going to freak out because you have a craft file that points to parts that you don't have. @Tiron: Well, wing sweep contributes to the dihedral effect (due to more swept wings having lower lift slopes than less swept wings). At really high angles of attack, wing sweep is the dominant component of the dihedral effect. Too much dihedral effect can cause the plane to roll violently in response to slight sideslip, and if it rolls enough that angle of attack and sideslip start being exchanged, the dihedral effect overpowers any roll damping the plane might have as well as not giving the vertical tail a chance to get rid of yaw inputs. A slight amount of anhedral can make the dihedral effect less pronounced, resulting in better lateral stability at high angles of attack. Of course, it's less stable at low angles of attack as a consequence, but some sub-optimal performance at low angles of attack is acceptable when you're primarily concerned about keeping the thing from losing control during reentry and when climbing out of the atmosphere. @jstnj: Dunno. I get lower FPS when the graphical aerodynamic effects show up, and then it speeds up when they're gone. If you're not getting an FPS drop in the upper atmosphere, it's not my fault, because you're still running expensive supersonic calculations up there.

Alright, since Module Manager 2.0.5 is out to fix a serious bug, I've released FAR version 0.13.2.1, which includes the fixed Module Manager (note: old Module Manager must be deleted or issues will occur), as well as fixing a few minor issues. Also, it includes a new SSTO using B9 parts, the Eclipse III: It includes some features that are useful in designing spaceplanes, such as slight anhedral on the wings to reduce wing rock during at high angles of attack and a wedge tail to produce more yaw stability at high Mach numbers.

@ObsessedWithKSP: Will be in the next release, which should be out soon. @DaMichel: I've noticed that myself. I'll need to figure out what causes that, though it's probably just that it's grabbing the wrong velocity somehow. @smunisto: High speed air has lots of energy. When you slow it down, that energy has to go somewhere, usually into heat. At high enough Mach numbers (>3) heating is significant enough that the intake air needs to be cooled down or else the combustion chamber risks being overheated by high-temperature, high-pressure gas. Interstellar models this and changes one of the engine bodies into a precooler.

@smunisto: That's either an old DR that you're using (ModuleEnginesFX overheating bug) or you're using something like Interstellar that requires pre-cooling high velocity air. @Klingon Admiral: Oh. That's an old bug from FAR v0.13. It was fixed in v0.13.1. This is why you should always update your mods. @Zeroignite: That sounds like a pretty optimal ascent to me.

Well, if the engine wasn't contained in a cargo bay, there are still forces acting on it. And FAR's aerodynamic failures don't account for things that interface with the stock drag system, like parachutes or B9's overpowered airbrakes.

@Tiron: I only say to use the DCA because most people don't want to be told to not throw the controls around like a fool. To be honest, I haven't sued it since I set it up, it's just easier not to. The Mark1-2 pod's properties haven't changed between FAR 0.13.1 and FAR 0.13.2, those changes only affect wings and planes. That said, I don't know what Klingon managed to do with his thing. @Mystique: Low mass object, large surface area. In reality, the fairing should be torn apart, but it's a single part, so that doesn't happen, so instead it comes down as one light, fluffy chunk. For a piece coming down at those speeds, perfectly realistic in the context of the object being indestructible.

@dlrk: No, it will not work with Module Manager 1.5.7; it requires the new features from 2.0.3. @Mystique: Very light object, decent surface area, FAR not designed to handle very low speed aerodynamics = things are weird there.

@DaMichel: IAS doesn't account for compressibility effects, and becomes incredibly inaccurate over Mach 0.6. That's supposed to happen, that's why no supersonic planes use IAS, they use Mach or EAS. @Tiron & Kaa253: Confirmed bug, mentioned a few pages ago. In addition, it's not g-Force that determines whether parts are destroyed, it's the aerodynamic force on them. Otherwise, you'd be able to have a wing break off under 10 kN because it was connected to a really light vehicle, so those 10 kN translated to 20 g's, but the same wing, attached to another vehicle can make 200 kN and stay attached because the vehicle is really, really heavy, so those 200 kN translate to 2 g's. You need to reduce your wing loading or your total mass if you want to do higher-g maneuvers at decent speeds. @Sof & Klingon Admiral: Well, to start, the 3-man pod has always had a higher ballistic coefficient than the 1-man pod, but I've never seen the effects you're describing. Either you're doing something equivalent to the people who clip a heat shield into the 1-man pod (thus reducing its drag to nothing) or you've got a bad install. I mean, I've done hyperbolic returns at 25 km and the pod comes down perfectly fine, so I'll need more information before I can find out what's wrong.

Hodo: Thrust was not greater than drag. Since you had the FAR Flight Data window up, we can prove it. In pic 5, the ramjets are creating 328.4 kN each, for a total thrust of 656.8 kN. As for drag: D = Q * Cd * A D = 218,680 Pa * 0.035 * 133.7 m2 D = 1023.3 kN So in pic 5 you've got a 366.5 kN deficit. In pic 6, the ramjets are creating 289.8 kN each, for a total thrust of 579.6 kN. ANd your drag: D = 162,330 Pa * 0.035 * 133.7 m2 D = 759.6 kN So in pic 6 you've got a 180 kN deficit. In both cases, FAR's drag overpowers the engine's thrust and you should decelerate. I'm curious, what method were you using to calculate drag that gave you answers less than your thrust? Whatever the case, you're flying way too low in both of those cases. Frankly, the fact that you got a plane that big up to Mach 2 at those altitudes is astounding in itself, considering the only plane of comparable size was the Concorde, and that needed to get above the altitudes you're at before it even went supersonic.

Well, the syntax changed a bit, and it allows order-of-operations in applying the configs, which is kinda necessary for a lot of realism overhaul stuff. If you try to run the current module manager config with an old version of module manager, things will likely break.

@Azimech: But that's what it is. Tapping is just poor man's PWM. @Shania_L: Dynamic Control Adjustment. Lessens control inputs at high dynamic pressures. Activated by clicking the last button on the Flight GUI.

No it doesn't. I play with only a keyboard, and I'm just fine; you just have to learn to use pulse-width modulation on the controls, which has always been a useful way of getting fine control working. And if the DCA makes the craft non-responsive, odds are you can get away with turning it off.

Try turning on the DCA. It'll scale down control inputs above a certain dynamic pressure, except for trim.

That's about right. Full control surface deflection at Mach 0.5 - 0.6 at sea level can cause structural failures, particularly since there can be very nasty compressibility effects at those speeds; you might be better off just making the control surfaces larger and use smaller deflections if you need that amount of control at those dynamic pressures.

@MAKC: All of the relevant values have been moved out of the config.xml, into the FARAeroData.cfg so that they can be accessed by other mods. The only one that needs to change any more is the attachNodeDiamterFactor, and that's only for RO, so that should be handled on RO's end. @illectro: It detects when aerodynamic forces should be enough to start causing parts to tear themselves off, at least sort-of based on real-life data. The problem is that the new joints system uses jointDrives (like KJR did and does) to keep the parts from flexing, but the forces applied by jointDrives don't count towards the "breakForce" and "breakTorque" limits of the joint. So in essence, it's very hard to get a structural failure to occur due to anything other than a physics glitch as a result. So FAR works around it instead. If you're worried about the strengths being too low, there are configs in FARAeroStress.cfg that can be modified to tweak how much parts can take. As it currently stands, if you get a rocket going at 1500 m/s at 5 km it'll be fine so long as it stays pointed prograde, though it falls apart if you go off by any significant amount. @AndreyATGB: I see why the wings and control surfaces aren't being affected by that setting; I'll upload a fixed version once I get a chance to look at ayana's issue. The control surfaces breaking, well, it depends on what forces are being applied to them and what AoA they're at, since I've never seen that happen myself. Usually it takes getting to ~250 m/s before control surfaces start coming off, and that still only happens at full deflection. If you're concerned that they're too weak, go into the FARAeroStress.cfg and buff their template up drastically. @theSpeare: Those first 3 items... that's what you're looking for.