ferram4

@coldblade2000: And nothing else? Using stock parts? Wings needed or just anything will do? Edit: Oh wait, this makes sense. Mach 0 corresponds to V = 0. Okay, I'll add something to prevent that.

I tried leaving it open. I also tried allowing mods to run on KSP versions that they weren't intended for, so long as the user acknowledged that they were broken. In both cases, people ignored it and proceeded to make supporting the mod more difficult. So no more of that now, I'd rather spend time working on issues that I can fix rather than issues that are from older builds or that are Squad / Unity's fault that I can't do a damn thing about. I'm not going to help support something as broken as win64 KSP; that should have never gotten out of experimentals in the first place.

What? That basically means that KSP's physics simulation is broken. Alright, let's find out what's up. Follow the steps here: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

I know. Do it all the time. Try setting the gains. It doesn't automatically do it for you, because tuning those values automatically will always go badly. Try setting the AoA limit lower? It's to prevent you from overcontrolling the plane during high-dynamic pressure maneuvers. Maybe you should mess with the options. Well, yes. Did you not think that a control system needs an interface of some kind? ...Apparently not. I'm quite amazed, most people complain about how badly SAS handles FAR, and even I think it's terrible at it. SAS has never been good with anything that has a lot of control authority. Why yes, there is. Dunno what I can do. I code the forces, not autopilots. You only have to click one button. You don't need to update the CoL before the sweep; the button is there for if any errors occur for the indicator alone. I'll make sure to remove it to reduce confusion. It actually remembers three different values, but I'm not sure what you want: another entire window for the settings for each sweep type? There was. Then Squad updated the plane parts and they were all broken.

@DaMichel: Wing mass is computed using the "supported area" of the joint, which is calculated from that wing's area and the area of all wing parts that are children of it. This supported area is then multiplied by a constant (in FARAeroData.cfg) to calculate the wing mass. I picked a number that I calculated for the wing mass per unit area of a MD-83 for that, but perhaps it should be lower. @Senshi: Not until the win64 build isn't a crash-prone nightmare that should never have seen the light of day. It shouldn't have even been released for 0.24, it was so unstable. Maybe once it's not a complete disaster, but that's not happening for a long, long time.

I did last time. Everyone did last time. People still complained to me about the win64 build's inherent issues that I couldn't fix. We tried that solution, and users couldn't handle it.

http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 <- We can't help you without more information.

@DaMichel: The wing mass is based on the wing area that needs to be supported by that wing's connection; this makes wing roots a lot heavier than wingtips. The default masses of wing parts don't matter anymore. @Wanderfound: The mass of hydraulics is abstracted away completely for simplicity. Current dev version has a tweakable thing submitted by NathanKell. It also has an attempt at a fix for cargo bay issues.

They gained about an order of magnitude more mass. Some of the much larger configurations are even heavier. Previously, they were equivalent to the mass of ultralight wings at the most realistic, and even then it was a little too light.

@Boomerang: Known problem, there's a fix in the current FAR build, but that won't be in NEAR until I finish up what I want for FAR and bring the fixes over. @Virtualgenius: Or it doesn't do the correct thing with those forces. In any case, nothing I can fix.

@Jim Kernan: Then you are not loading up KJR v2.4.4. The CC settings were updated for 2.4.4; I suspect you are still using v2.4.3. @odmonk: Thanks for understanding. I wish the win64 build wasn't such a disaster, but it is. I'd rather work on support for issues that I can fix rather than ones that are out of my control.

NEAR applies forces. It does not provide control systems. Controlled flight into terrain is due to control system or pilot error. Nothing I can do.

@krenshala: FAR has never affected parachute forces at all. Nothing has changed there. @Wanderfound: Ok, so that sounds like very lightly damped short-period motion, and it's just as dangerous in real craft as you've found. It's one of the many reasons why single lifting surface designs aren't often used unless they're highly swept delta wings with very low AR (which results in slightly better damping from the wing alone). I'll note that your aero analysis stuff is pretty good, except fro the part about the yellow Cm line on the static analysis graph. The sign of that is less important for stability than the slope; when the line slopes down, the craft is stable. When it slopes up, it's unstable. The absolute magnitude is mostly just an approximate idea of how much pitch control you'll need to keep the thing at a given angle of attack; the plane will stabilize at the AoA where the Cm line crosses 0 (for a downward-sloping line), and the primary effect of increasing / decreasing the pitch deflection is to shift the Cm line up or down, shifting where it crosses the X axis, and so what AoA it will stabilize at.

Because it's only accounting for the changes in CoP when you pitch the rocket. So any changes in CoP along the yaw axis aren't accounted for. Obviously, I will need to make changes to account for this.

@Wanderfound: I see that I'm going to hate the stock swept wings now, they make figuring out the configuration of the plane from a picture difficult. Okay, what exactly do you mean by "porpoising"? Is it just changing AoA rapidly? Then you need more pitch damping, add larger horizontal tail / canards. Is it yawing from side to side? Add more vertical tail. @Jovus: Yes, that is correct. The plane is flying sideways, so its CoP will be in a different position.

@Drakoflame & Whovian: Available on KerbalStuff or Github, just look beyond the download button for the older releases in the changelog / releases section. @Moistmonkey: Aware, confirmed, and looking at fixes. Shouldn't be that bad to fix though, I think I know what's wrong. @Jovus: Nope, the CoP is constantly being recalculated. That's how it moves when you change the orientation of the vehicle. The result it gives is correct.

CoL is determined based on pitching movement. That behavior seems proper.

@gilbr0ther: Read the OP, it includes info about your issue, which is not actually an issue. @Las-pen: That is because SAS is terrible at controlling anything with a high degree of control authority. That is why rocket engines only have 0.5 - 1 degree of thrust vectoring, and why stock control surfaces only work because they're so broken. They hide SAS's brokenness by tuning the parts to the SAS, not the other way around. FAR has a few control systems that can be activated for most of the things you would want when flying planes, but they were removed from NEAR because people complained about having them. The pulling to the side is the result of uneven flexing. Happens in stock too. Original solution was to strut everything well, but then Squad made struts not as rigid for some reason and that wasn't an option anymore. @Inglonias: That sounds like the rocket equation at work, tbh. Work out the dV of your rocket, and then check the dV required to cross EVE. If you use this with RSS, it'll work, it'll just be kind of weird without the Mach effects.

@Anyone having structural failure issues on load: : Without a copy of the output_log.txt and reproduction steps, I can't help you. You will also need to verify that you have a FARAeroStress.cfg in your FAR folder in GameData, and that the CustomFARAeroStress.cfg in the same location dos not have any zeroes in it. If the former, reinstall FAR. If the latter, delete CustomFARAeroStress.cfg. @Wanderfound: For the first one, that little bit of red explains it completely. Sideslip increases yawing motion, which is going to result in rolling and pitching tendencies. That sounds about correct. For the second one, why are you not considering fuel burn after getting up to that velocity? Also, you've got WAY TOO MUCH dihedral on that design, and that is probably contributing to it. A lot. I will also note that since you're not looking at the AoA Sweep for the static analysis that you actually have no idea what AoAs your plane is stable at. For the Mach 5 case, the Mw is so low that I wouldn't be surprised if it flipped sign the second you got above ~7 degrees.

Nope, sorry. Win64 0.25 is even less stable and crash-prone, and frankly shouldn't have been released in the first place. I know from experience that for all the people who will recognize that win64 KSP issues are issues with the underlying game, more will flood me with bug reports and complaints, while telling people about ways to fix it that don't. Since people are unwilling to listen and follow those warnings, they don't get the choice to disregard them.

@Las-pen: Want to go really, really fast? Keep your control inputs small, or go higher up. Rockets are the same way, and are likely to be much easier to deal with than planes, since you have no risk of getting a lot of lift from them. And no, there is no way to toggle NEAR in-game, simply because of the changes it needs to make to get wing lift to work. Further, if you want the aerodynamic properties to change between takeoff velocities and high speed flight, you'd be better served by FAR, I think. That said, no, you can't have it scale between NEAR for takeoff and stock for regular flight. That doesn't even make any sense. @qbg: That is correct. The basic jet is set up as a high-bypass turbofan, which spools up to 150 kN static thrust but loses all of its thrust by ~350 m/s. This is representative of the way turbofans behave in the real world, and its role is to get big, heavy planes up to speed to take off. Slapping a bunch on the back of a small plane is pretty pointless; maybe I should make them weigh more to balance their absurd (for a jet) thrust.

@Nagual: Yes, you will need to redownload the win32 build of the game rather than the win64 bit build. @Las-pen: That should be perfectly fine. Looks like with all that wing area it should have a pretty low takeoff velocity, somewhere around 70 - 80 m/s, right? It needs more vertical tail though, those tiny things so close to the CoM aren't going to keep it straight, but that's a different problem. For something that size, you really don't need both of those engines. That looks like the main problem here; too much engine, too much velocity, too much aerodynamic forces, too much for stock joints. I gather you want me to make joints unbreakable, then?

For future reference, pictures at night, surrounded in flames is not a good way to figure out what's going on with a vehicle. I have no idea what configuration you have there, besides the fact that you have two engines.

Then congratulations, you're applying ~5 times the forces that would have ripped the plane apart in real life. NEAR does not have special aerodynamic failure features, it just applies forces. If you applied those kinds of forces with engines, you'd rip the wings off too.

@brusura: Pictures are better than craft files. And if there is no noticeable deviation of the indicators in the editor, then it is not something that I can fix; it is caused by stock flexing issues, bring it up with Squad. @temeter: Stock issue due to uneven flexing, as far as I can tell. Nothing I can do about it, unless you can provide proof that the aerodynamic center is shifting improperly or of unbalanced masses. As for the cargo bay stuff, I'll look into it. @smunisto: I tried that. It didn't work. Did you notice that I was one of the few modders that didn't have "will not support win64" in the OP during 0.24? But I'm tired. I'm tired of being sent off chasing bugs that aren't my own. I'm tired of running damage control when someone says that "doing X fixes it on win64" when it doesn't. I'm tired of trying to maintain higher stability standards for win64 KSP than Squad has. I'm tired of giving people incentive to use a messed up and unstable build. But most importantly, I'm tired of people not reading the warnings and following them. Since Compatibility Checker has existed, we've had more and more instances of people just ignoring it, advocating other people ignoring it, and then when something actually breaks, people complain to us. Win64 KSP is no different. So after spending all this time trying so desperately hard to leave open the option to people who understand that they're being reckless, all we've gotten back is complaints, anger, and a flood of garbage that buries valid reports. Worse, CC has only drawn attention to those mods and brought more complaints and trash reports because a mod had the gall to draw attention to the fact that it wasn't properly functional. So now, after giving me hell in return for giving you a way around the warnings, you don't get to go around them anymore. "But it's not my fault! I never complained to you about win64 issues! I'm innocent!" Of course. You're innocent of being a jerk directly. You're guilty of trying to enable other people by trying to get me back into that position. You're guilty of being the reason Squad decided it was better to release a broken win64 KSP rather than pull it like I asked. You're guilty of being the reason that they decided to rush a build out after someone hacked a broken win64 version together. You can either switch to the win32 build or the linux 64-bit build. I'm not wasting my time on win64 anymore.