ferram4

I doubt the number of users on win64 builds are anywhere near peak levels. For one, we don't have an official win64 KSP release anymore, and for two, the steps necessary to make the hack work aren't straightforward and require you to download all 1.6 Gb or whatever of Unity. That's a fair bit of time, effort and bandwidth that users don't seem to be willing to go through with. I'll also note that since 1.0, despite the increase in users, I have had many, many fewer "why no win64, ARGHBARL GIVE WIN64 SUPPORT NAO" kind of posts. On the other hand, if you're using "x64" specifically to include Linux users in a kind of "technically correct, but deliberately misleading" kind of way, then you are correct. But you're being deliberately misleading by being too broad. All mods will fail under some circumstance, precisely because of what win64 builds of KSP are. Win64 KSP build are like sandy, waterlogged ground in an earthquake zone; any building you put there that's more substantial than a hut (and if you put enough of them, even that) will collapse into the ground eventually. As noted, win64 KSP == guaranteed failure at some point. This has been proven by our tests again and again and again, and it doesn't matter which mod it is; it's all of them. It's nice to know you're on our side though. Oh, thanks for pointing to Contract Configurator as having a win64 locking version that you haven't figured out yet, that led me down a few paths that should allow me to prevent the unfixer from working. Should be very useful. And now, instead of being able to address the legitimate issues that win32, OS X, and Linux 32 / 64 users have posted, they have to hope that I see those when they've been buried in a flood of "Y WIN64 NO WORK?!" posts. It makes the signal to noise ratio a lot worse. We tried this, and user support for anyone on the other builds suffered. A lot. Then, you know what happens? As was already noted earlier, though you seem to have ignored it as it was inconvenient, users try random things to make their installs work, like delete ModuleManager and other hard dependencies. Things break more. Eventually, they come back and try to get support and make more noise, and guess what then? More signal to noise ratio worsening, plus, until we recognize that this is a bug entirely caused by user error, we've wasted development time tracking it down. The end result is that it adds more work for us and screws over your fellow users because they can't get good support, and mod development slows too. So I gather you want us to have more work, your fellow users to get less support, and for mod development to slow.

Try again, with a better description of your issue. In addition, follow the full steps in the sticky from the Modded Support forum, all the other mods you're using, and whether you installed through CKAN or not. If you don't do this, I can't hope to help you.

That indicates user error, as the only way that could occur is if you turned on the AoA limiter and never turned it off. This is not a bug, this is FAR doing exactly what you asked it to do.

So, current progress: Work is being made on area ducting through vehicles for getting cross-section right. It's currently very ad-hoc and will probably get a lot of changes to make it make more physical sense, but it does function.

You never answered what would count as broken. Why not? Except that hasn't always been the case. There was that Realism In KSP thread awhile back that got locked on the basis of going against a moderator (or something near to it, from when I talked to Rows about it) because Sal said something rather silly about physics in KSP, and Ippo made a snarky comment about trying that on his next physics exam. Because it was criticizing Squad after Ted and a ton of the moderators came in to defend them near the end of the thread it was locked. To be honest, unless you guys explicitly state when it's a moderator action in your posts and when it's not, you're bringing the power you have as moderators to the front to win the argument, especially when you bat for Squad in the way that steve_v mentioned. We know how this works, we're not stupid. We know that you're only human, not perfect god-creatures, and that that means that you'll be tempted to reach for that moderator panel if you think it'll help.

Known issue, fixed in dev build.

Oh, I see. The fact that I didn't give Squad a free pass like you wanted to is a problem. Or would something else have been sufficient? Oh my god. Someone hacked into their servers to release it? Or held their family hostage? Or blackmailed them? I mean, if it was actually dragged from them unwillingly, why didn't they say so? What made the crisis end? You haven't answered my question: What would cause it to count as broken? What, above and beyond how win64 was, would be necessary for that criteria? I thought the main reason for 64 bit was to make modding easier. Why ignore the portion of your userbase that has the most experience with modding? Noted, but I will also note that when someone talks about things that reflect very badly on Squad, and then a moderator comes down to criticize it and play up Squad as so perfect, on Squad's forums, and there is no mention that it's a personal opinion, it gets very difficult to tell whether it is an official moderator notice or not. Especially since it is against the rules to criticize moderator actions, so basically arguing with a moderator is asking for trouble, because your posts are in a superposition of moderator statement / not-moderator statement at all times. This is actually a serious problem with the forums. It's impossible to tell if a moderator is acting as a moderator or a user. ...which was a good thing... I fail to see how any of this forced their hand. I fail to see how them not thinking about the consequences of letting a (let's go with your words) completely unfinished (to the point of nearly being unplayable) version be released would not have negative consequences. I can't see how this isn't some form of negligence on their fault. Labelled it as unstable only after, what, 3 months of (implicitly) claiming that it was stable? And then pulling the build after over a year of hell with it? There's a lot of blame, but not for the ones that decided to make everything worse by releasing something that was clearly "unfinished"* when "they knew it wasn't ready." Got it. *Thinking about it, I like this. It's a great euphemism, and fits KSP's development pretty well too. Thanks!

@Ricardo.b: Yes, during animations FAR revoxelizes the vessel. If it causes a significant amount of lag though, that points to either: Your computer is doing a lot in the background, which interferes with the threads for voxelization. You have lots of other mods creating spewing tons of memory garbage, which makes the garbage collector work very hard. I cannot fix either of those. @Empiro: It's possible, but that's an extra thing to calculate and display. FWIW, just look for segments of the green curve that, well, curve. Yellow line is a measure of the curvature of the green one, so anywhere where it isn't straight will contribute to non-zero S''. @63Hayden: Ask the CKAN guys, it's their problem, not mine. That's the case for any CKAN issues, including install issues from CKAN. CKAN is like win64 KSP; all the issues are out of my hands, and we'd all be better off if it would just go away. @rsparkyc: FAR does things based on the vessel as a whole, and it also doesn't require tons of funky part-by-part overrides like the stock model does. Seriously, cargo bays, decouplers, etc. all require specialized treatment in stock because of the hollow section. Also, as NathanKell mentioned, stock barely has any stall, doesn't account for wing shape (in actuality, it lets wings transform from glider wings at Mach 0 to essentially F-104 wings by Mach 0.3 for no apparent reason. Wings don't even hit compressibility effects at that low Mach number). It's... a very hacked together kind of mess. No one wanted to try and do things right, only hack it sort-of together.

I see you didn't read the second sentence of the first paragraph where I acknowledged that; I guess it was inconvenient to your argument: Is it really wrong to note that, for 0.24, if a user looked at the KSP download page, there was no message that win64 was unstable? Do you dispute this? Do you dispute that there are many users that do not use the forums, whose first awareness of the win64 build was when it appeared with no warning message on the store? If you do not, and you acknowledge that there are portions of the KSP userbase that were not aware of the hack or its instability at the time of 0.24 going out with it, you can't defend Squad here; they made things a lot worse through neglect. And considering that it was Squad that truly opened the floodgates on this, and carelessly at that, I see no reason to not give them a share of the blame. Perhaps you didn't notice that it wasn't Squad throwing the contradictions and misconceptions around in my post? The implication that users were to blame? Was that also inconvenient to acknowledge? I see... "broken" is a rather loaded and unfair term for something that was broken? What would be the criteria for it being broken? Would crashing unpredictably, with multiple additional bugs count? If not, what does? I get that you're trying to defend Squad, I get that it's your job, but really; it fits the definition of being broken. For each of the modders doing that, there were a dozen users demanding the opposite. The difference was that the people asking for it to be pulled had their work directly hurt by it existing; Squad went and made things much more difficult for a group of people that created content for their game for free. Why? I see you completely missed the point of my post. I provided a history of what happened; that they made large mistakes and made things much worse is a fact, and none of this mess would have happened if they had never released the win64 build in 0.24. Honestly, I'm kind of confused; I've stated facts throughout. Is it against the forum rules to state facts about what has happened if they reflect poorly on Squad? Is that what I should take away from a moderator getting involved here?

Since you're asking to understand, I think I'll fill you in on a brief history of win64 KSP builds and how this has all gone. It helps explain a lot of how this worked out. It starts back in 0.23.5. Up until this point, while Squad has toyed with win64 KSP builds privately, none of them were deemed stable enough to be released. Someone (whose name escapes me currently) in gets into modding by coming up with the method to hack a win64 build of KSP together; the same exact method that is used for the current hack. It gathers a small following, despite the random crashes, and some work starts to try and determine what mods are compatible with win64 KSP. The thread fills with contradictions and misinformation, with mods listed in the OP as "incompatible" being reported working fine later on, and lots of bad solutions throughout. Nevertheless, because of user interest, Squad releases a win64 build of KSP for version 0.24. It is more stable than 0.23.5's hack (in that a rather critical, reproducible bug was fixed by upgrading Unity versions), but it still crashes rather frequently and without warning; despite this, no warning of its instability is mentioned anywhere in the store or on Steam. The end result is that a large number of people who had previously not used win64 jumped on to it and suffered a ton of issues once they installed mods and increased the memory usage, leading to them (wrongly) blaming the mods, rather than the broken engine/game. This is compounded with a new PartModule saving bug, that could cause issues like multiple instances of engine modules to show up on re-loaded vehicles. Simply due to the mechanisms of the bug, lots of mods got hit with the stock behavior from two sides, turning support for 0.24.0 into a living nightmare; the PartModule bug was fixed for 0.24.1 and 0.24.2, but the win64 crashes weren't, and in a bid to reduce the workload, lots of modders declared "NO SUPPORT FOR WIN64 KSP BUILDS." Unfortunately, this didn't work. No one bothered to read OPs, people continued to blame mods for crashes due to the stock game, and a large number of users simply refused to believe that win64 KSP was unstable; if it was, why would Squad have released it, especially without a warning? In the lead up to 0.25, a few modders (including myself) asked for Squad to pull win64 builds. They were unstable, modders didn't support them, and the crashes were most often caused by high memory usage (read: above 3 Gb); if the win64 build became unstable when memory usage was still below the 4 Gb limit, why bother with it? It's useless for mods. Further, word was that 0.25 would have Porkjet's SpacePlane Plus mod integrated, increasing stock memory usage, possibly making the stock game less stable, and certainly making modding it less stable. They didn't pull it. Instead, they only added a label of it being "unstable," but by this point, users didn't care that it was labelled unstable; they were certain it was the mod's fault, it couldn't possibly be KSP itself, and the modder not providing support was a jackass. Best solution was to keep demanding support, keep telling people bad ideas to "fix" mods that were fine (that would cause support issues later), and generally just make support work for modders. So a bunch of us made the decision to lock out mods from functioning on win64 builds of KSP using the CompatibilityChecker utility that many mods include. (Side note: locking out mods on incompatible versions of KSP was the original concept of CC; it was downgraded to warnings for the first usage after some debate, but it's funny that users pushed it back towards its original plan). If users wouldn't read the OP and understand "not supported," maybe they'd understand when they couldn't run it. Everything. Went. To. Hell. Apparently one KSP version with win64 was sufficient to make users expect it forevermore. Flamewars erupted, people filled mod threads with hell over this, and even threw enough flak at Squad over this that they needed to make an official statement saying, in essence, "No, modders don't owe you anything, they can choose not to support or even allow their mods to work on win64 if they so choose." Which is kind of amazing that such a post was needed, but I digress. This leads to a few adventures in other technically proficient non-modders taking steps to try and undermine this. One of these was Cerebrate, who initially tried to release a fork of stupid_chris' RealChutes with the win64 locking removed, which was removed due to not including he proper license; this led to stupid_chris re-licensing RealChutes with a more restrictive license to try and avoid this (with a few bugfixes as well), while Cerebrate created the first of the win64 UnFixer utilities to hack the dlls as a way around this. The end result is that stupid_chris took a rather long hiatus after that and nearly quit modding. Another adventure was that of Senshi trying to maintain win64 forks of FAR and a few other mods (I forget which), on the basis that he would handle all the bug reports and nonsense from that. Despite this, people still tried to get support from the original modders and bring win64 issues to our threads; I only found out because Senshi's fork of FAR was off of a dev version that included a rather predictable bug that occurred in a few support requests in my thread. Eventually he gave up because of win64's instability combined with the users that he had and the mess involved there. Things stayed relatively calm throughout 0.90, with the occasional thread on this subject, some like yours, others insisting that all the modders must irrationally hate win64 because it stole their firstborn or something, few of them wanting to accept the answer of, "leaving all of this open makes modding enough work that it makes us consider quitting. Please stop making this difficult for us, or you'll eventually lose us." I guess the idea that you could be causing problems for people is best answered by being a jerk and causing problems to prove they're right? I dunno, few of the response really made sense to me with those. And finally, the leadup to 1.0 comes around, and Maxmaps floats a trial balloon about pulling win64 on a Squadcast, and pretty much all the modders involved in this have a combination of, "finally!" and "what took you so long?" as their reaction. 1.0 comes out, win64 is pulled, sadly, Linux 64 was as well, despite its stability (seriously, never had any issues with Linux 64 and mods, no idea why they pulled that). edit: nope, they didn't; misunderstanding on my part. Things look like they might be stable again. And then the win64 hack comes back, and the thread starts up, with people trying to figure out which mods are compatible and which aren't, filled with contradictions and misinformation... And so it goes.

This issue was fixed a long time ago, and Procedural Parts is not updated for 1.0.3/1.0.4 yet. I would wait until it is made compatible first.

Alright, so v1.3 is out, with some fixes to the volume calculations to make them a little better.

Alright, so v0.15.3.1 "Garabedian" is out, with a few little changes for KSP v1.0.3 compatibility, one last fix for the no drag bug, and a nice little main axis issue fix for structural panels.

@smartdummies: Okay, I thought I had fixed that. If you would like to try and get numbers for it, it should take fewer reverts with a vehicle that "fills" its bounding box very well; so straight cylinder rockets and command pods will probably cause the issue fastest. If you can get some data on that, it would be great, since I've just pushed out a dev build that I think might fix it, but having a number of reverts would be really helpful just to make sure; once you've got a number, try out the dev build, I think this should have finally fixed it. Edit: tested and reproduced with ~10 or so reverts with a single pod in Froude, can't reproduce in dev build. Cool, I'll pack in any other bugfixes or little necessary things and then get 0.15.3.1 out soon.

@sashan: And there was a bug similar to that that I fixed, though it had nothing to do with engine gimballing. Try Froude, see if it works, if it doesn't, list all the parts on the vehicle that have animations built-in; note that this does not count engine gimbals or control surfaces, FAR never revoxelizes on those movements. @scavenger: If you don't put in the work yourself, you'll blame me or the person who provided you with the build or the tool when win64 crashes. You're on your own pal, and I'm sorry, but you're not getting any support either. @Deep silence: I don't see why it wouldn't. Only issue might be if its configs are put together poorly so that it attempts to identify two planets with the same index. That's unlikely, but if it does happen, FAR will refuse to load, and it should be a simple single-line change for the author to fix the FlightGlobals index if that happens.

Probably not, but let's try, shall we? What par-takes here is that. As does the current hack from my experience. So you agree, it's unstable then? And this, combined with what I have seen myself, makes me think everyone talking about it being more stable is just lying in hope that there are better chances of it being fixed / made official again if they lie. Seriously, repeated crashes are just glitchy? Do you really expect me to believe that? I have. What did you think I based my experience on? It crashes about as much as it did before, in the same circumstances. Maybe a little higher memory usage, but it's still a broken hunk of junk. If your argument is that any of those bugs were to fix win64-specific bugs, well, that's funny. I can't exactly fix random crashes in Unity itself, and I couldn't really keep the game running long enough in win64 to achieve anything besides frustration. All the issues existed in all KSP builds (because, remember, the code is identical regardless of word size or OS), and were reproduced in win32 builds. Yes, and none of this fixes the people who'll come into my thread and bury good bug reports with their whining, or the people who will replace good common support knowledge among the userbase with poor common support knowledge because they're fighting with a monster, and all of the arguments that I can ignore it just because it's a hack are bunk because we all know your goal is to get the official win64 version back. And we all remember how bad things got when that was out, right? At a certain point, I think you need to acknowledge that win64 is unstable and stop acting like it's perfectly fine but for a few mods. Win64 is broken as all hell and crashes without warning. Has with the first hack, has with the official versions, has with the current hack, will probably do it with whatever comes out next. Fundamentally, nothing has changed. Except, as already noted, the people who don't listen to that and don't care and the unintended consequences in the common thought processes of the community, and the eventual added crap from when Squad finally caves again and pushes out another busted win64 build. I think you have failed to realize that the issue is not with the mods, or the modders; it is with users that don't understand, "not supported" (did you not think that we tried that before locking the mods?) and then turn every single mod thread into a win64 argument. There are more consequences to this than just whether you get to play with an official version of broken win64 KSP. Look up how things went before. See how bad things got. Hell, look at the unfixer; that was Cerebrate's runaround around stupid_chris's win64 locking and license restrictions, all because stupid_chris just wanted to not deal with win64 reports from his userbase. Turns out, that's unacceptable, because he still got tons of bug reports from that. The fact that you think declaring that modders don't support win64 is the end of it basically proves that you don't have any concept of how things go once the broken versions are out there. Of course I'm blaming you! People like you, the ones that have pushed win64 with reckless abandon, disregarding all the instability, all the issues, downplaying anything bad and broken related to Unity or KSP themselves, making sure that only the mods are left to blame... you're the ones that made win64 a nightmare to support (when we did), and then a nightmare to deal with anyway, because no one cares whether we support it or not, they'll crap all over our threads and bug reporting systems out of spite. You, and everyone else like you, that pushed for the official win64 version, the ones that jumped on modders the second they realized how broken KSP was, you're the ones that turned 0.24-0.90 into a wonderful hell of trying to deal with a broken game, and then users that were ticked that they couldn't play the broken version and then crap all over the modders for problems that aren't their fault, after you've set everything up so that they're the only ones left to blame for anything. Don't talk about "healthy" community behavior when you're talking about win64 KSP either; this thing is nothing but cancer, and the sooner everyone accepts that it's broken and a mess, the sooner we can let it die for good and we'll all be better off. As they should have for the time that they spent with the broken builds available. As they should have for the damage it caused to the modding community. If they managed to get away with it, that's impressive, but the fact that they got away with it doesn't erase all the damage that it has done and that the hack threatens to bring back. And you should be smart enough to not push for something that will cause a ton of damage, and doesn't even work either. I really wish they were as quick to pull it as you think they were. We asked back in 0.25 when it was apparent that 0.24 was a complete disaster. They refused. We locked mods as a last resort to try and reduce support workload because telling users that you don't support it doesn't work. Everything went to hell. And now you want to bring us back to that? Why?! No, they'll release because there are a bunch of people screaming that it's so stable (even though that's a lie) and that Squad screwed up by pulling the build then, and they'll release it under pressure, just like they did before. And it'll be a disaster, just like before. Because this has all happened before. Nothing is different, it's the same lies, with the same behavior, the same blind eyes towards issues. Ah, yes. Let's stop debating publicly after you get the last word and dismissed all of my points. I do think you're right, there's no point arguing directly with someone who has seen fit to dismiss all of my points and to ignore what I've said when it's convenient for the argument. On the other hand, continuing for the sake of everyone else is quite good. I get it. You'd like win64 to be stable. It's in your interests to present it as stable. If it were stable, that would be great for all of us. But it's not; I've tried it, it crashes just as badly as before. It's just not worth dealing with.

Now see, that makes sense. This also lends credence to my point that the win64 hack is unstable if issues still occur. Funny, I've always gotten memory crash errors more easily with win64 than with win32, despite the crashes occurring at a lower memory usage. Very stable. Considering what I've seen, trying to play it off as if it might be stable is really, really pushing it. All of the indications are that it isn't, but that you would really rather not admit that because it gets in the way of what you want. I have, it seems just as unstable as before. I'm sure this is the point where you tell me that I obviously did something wrong, because, after all, if I did everything correct, that gets in the way of what you want. See, this is the kind of garbage that makes me hate everything to do with win64. The code for mods doesn't change between x86 and x64; it doesn't need to, if it did, then all the Linux 64 builds would have had so many problems despite the fact that they never have. This is the same exact garbage that came up before with the 0.23.5 win64 hack; "oh, of course it's not the win64 build being unstable, it must be the mods." This has all happened before, and it is all happening again; don't take me for a fool and think you can play this off as something different, because I've already seen exactly how this mess goes. There have never been any recorded cases of irreparable damage, but good job trying to downplay all the other issues by comparison. I see what you're doing. Of course it's not the mod's fault! Why would it be, we're just implying that it is... we'd never say it out loud, no, that makes people very upset. At least be honest and blame me to my face. Have some honor with the accusations you throw around; stand behind them, don't run and try to say that you're not blaming any of us modders, because you are. You did before, you're doing it now, nothing has changed. ^^See? It's totally not win64's fault, must be the mods. "We are not demanding official win64 builds of KSP, but here are some reasons for why we should have win64 builds of KSP, and look how stable it is! Why did Squad pull the builds when it's so stable now, obviously all the problems are just with the mods!" >_> Do you really take me for such a fool? This is the exact same thing that has happened before, with the same exact blaming of mods and modders (but we're not, we swear!) and the same exact downplaying of any stability issues. The only difference is now, in addition to convincing Squad to bring official win64 builds back, you need to convince modders to unlock their mods. I would like to think that having a stable win64 build would be nice. But given the behavior in this thread, and of the community at large when faced with win64 issues (to blame mods and modders for it), combined with the continued issues that I've seen and heard about, an official win64 build of KSP would be a greater disaster than the 0.24 win64 release or the 0.25 win64 mod locking.

Well, then at least tell me everything that you did that session. And I mean everything; how many times you loaded from the editor to flight, how many saves you went into, how many times you switched between vehicles, how many times you came in and out of timewarp, how many new vessels were created and if they were created simultaneously or not. This entire bug reporting nightmare has been plagued by people leaving out important information out of some misguided attempt to help, but then following it up with, "but I can't reproduce it at will." Well, if I can collect a few dozen full reports of everything that has happened in the course of playing the game, I should be able to find a common denominator and work out what happened. For example, one of the issues was because of the editor -> flight transition. Know why I never looked at that? No one ever bothered to say, "I reverted to the SPH X times / launched X number of vehicles" or anything like that. You cannot provide too much information here.

I actually think that the continued issues with mods that have had their win64 disabling removed is simply proof that, contrary to popular belief and the desires of people in this thread, win64 KSP has not gotten more stable with the hacked 1.0.x version, only less stable. That is because all of the mods that are being claimed to be incompatible with win64 for actual code reasons (FAR, PP, RealFuels, RealChutes, etc.) have worked perfectly fine in previous official versions of KSP when the win64-lock code is removed; much of the code in FAR that is being accused of causing the issues hasn't been updated for over a year, well before 0.24 and the first official win64 version (where FAR worked perfectly fine, I might add, all it took was the 4 GB memory limits being exceeded and all of a sudden funky things happen). So either the win64 unfixer is borked and it's doing a terrible job of removing the one or two lines of code that it needs to, or win64 is so broken with this hacked version that previously usable mods can't be, even after the win64 locking code is remove. Now, since the win64 locking code hasn't changed since 0.25, the unfixer shouldn't have changed in that time, so the sudden fact that there builds leaves us with only one conclusion: the 1.0.x win64 hack is far, far less stable than even the disaster that was 0.24's win64 build. Now, if that's not the case, one of you rebuilding any of these mods from the source against the win64 hack binaries and with the locking code removed should be sufficient to make the mods work and prove that win64 is as stable as you claim. However, all evidence up until now (including the vast majority of this thread) indicates that this is exactly the same thing that we've seen with the first 0.23.5 win64 community hack; it has very serious issues that make it highly unstable, but those issues are blamed on mods (again); were it to be made an official win64 build again, those issues would persist, and rather than the issues being blamed on Unity / KSP, it would be thrown at modders (again). So if it's not as broken as it seems, and the stability claims aren't just marketing to try and convince Squad to put win64 back into production, you would be best served by trying to prove that it is more stable rather than trying to ascribe all the issues to mods that worked perfectly fine when win64 builds were first released.

Alright, so FAR v0.15.3, Froude is out. This is a serious bugfix update that should have killed almost all of the voxelization issues to date, as well as a few other, more minor issues. For fun fluid dynamics thinking, people may be interested in the Froude number, which is one of many dimensionless numbers in fluid dynamics, in particular dynamics at a fluid interface, like the surface of water.

It looks like a picture of wings creating drag. You may want to actually articulate what the issue is and how to reproduce it rather than hoping people guess correctly. Follow the steps in the forum sticky.

@Vegatoxi: Point by point: 1) The IL-76 is an airliner, correct? Pulling absurd manuevers in an overloaded airliner will cause the wings to come off. You should probably post the wing area of your replica and its mass and then compare it to the real thing; I suspect that you will find that your "replica" is about 20-30 tonnes overweight. 2) Many problems with this Su-27 replica. For one, of course it flips back, you put the main gear in front of the CoM; if the gear is in the correct position, then all this proves is that you put the CoM in the wrong position. For two, your vertical tails actually look a little too small, which will cause yaw instability. For three, the cockpit / nose section looks like it's about 2m too short. For four, you have no leading edge extensions along the forward fuselage. This doesn't appear to be an Su-27 replica. This seems to be a lot closer to a traditional early jet fighter, which will certainly lack supermanueverable capabilities. Should be rather fast, but very brick-like. And remember, supermanueverability is really only possible at Mach < 0.7. Higher than that leads to either disintegration or changes in flight characteristics making the plane more statically stable. Also, remember to check that it isn't overloaded with fuel. 3) I dunno how you managed to screw this up, but unless the entire thing is chock-full of fuel, that'll fly just fine. I've built plenty of SR-71s, and they've always behaved just as you'd expect; accelerate well, take off well, slightly unstable, tend to go sideways above Mach 3.5. I think your designs are overloaded or aren't close enough to the real designs to function properly.

@Jared: You just called me naming all the inter-related parts of the same theory fragmented... why? I see that you haven't bothered to look at them, and that this description: Shows that you don't even understand the defining factor of subsonic flow, which is that downstream effects can affect the upstream conditions. That's the whole thing that makes subsonic flow subsonic, as opposed to supersonic flow. If you consider it wrong that someone should be annoyed after the person they're talking to (claiming to ask for answers) simply hasn't bothered to look at any of the stuff that has been provided as answers, then I dearly hope that you come across someone exactly like you in your field. I expect that you will be perfectly understanding when they deliberately ignore everything that has been said to them. I expect that you will be perfectly understanding when they claim that the integral parts of a theory are proof that it is fragmented (seriously, thin airfoil theory starts as incompressible (linear by definition) potential flow, which leads to the standard solutions of source, doublet, and vortex flows (with singularities at their origins, hence the name...), which leads to creating the flow over an airfoil by a distribution of those singularities (hence, singularity distribution method), which then simplifies down to the defining characteristics of thin airfoil theory: that dCl/dAoA = 2pi per rad that camber shifts the AoA of zero lift by the factor -1/pi * integral{dz/dx * [cos(theta) - 1] dtheta}, where x = 0.5 * (1 - cos(theta) and z is the height of the camber line that there is some amount of upwash ahead of the airfoil, and some amount of downwash due to the circulation about the airfoil caused by the vortex distribution that the entire distribution of lift is built around the fact that the flow must separate at the trailing edge, forcing the pressure gradient about that and the vorticity there to 0 that all of the lift on the airfoil is created by the requirement that the flow separates at the trailing edge, and that in the absence of that, no lift is created But it seems like you didn't bother to look at any of that. If you're really here to learn, I don't see why you didn't bother. Oh, btw, that fluid sim you used? You might want to try it without the airfoil stalled, since I know that you picked that orientation to deliberately reduce the circulation around the airfoil and create less upwash at the leading edge. And you had massive flow separation even at 0 AoA, which indicates that you set it up with either too low a Reynolds number or too large a cell size. Next time, for your counter-example, you might want to actually set up the sim properly; maybe show the settings that you used as opposed to hiding them, hmm? @Kitspace: Because teachers fail at explaining things, and then people like Jared muddy things up. Follow that with the fact that we focus on Bernoulli's equation a lot (which is more useful as a tool rather than an explanation) and the fact that no one wants to accept, "they're both correct explanations, just coming from different angles," and you get flamewars on the common correct topics, which keeps people from dealing with equal-transit-time theory and AoA-doesn't-produce-lift theory and mystical-earth-focused-lift theory. FAR uses the best models that can be run in real-time. In particular, it uses a modified form of lifting line theory, which is a generalization of thin airfoil theory to 3d wings. There are a few modifications to handle sweep, changes in Mach number, and of course, supersonic flow, where the trailing edge really can't affect the leading edge. But otherwise, it uses exactly the theories that I would point Jared to, if he would take a minute to actually read them rather than dismiss them in ways that prove he never bothered to look at them.

So this: Is inaccurate then? Your justification for it being different than my earlier points was that it was new gameplay that you didn't like, and worth complaining about now (as opposed, implicitly, to any other minor gameplay complaints, because those have been there for a longer time), because it was changed recently. Or am I just having difficulty because I'm trying to find justification beyond, "I dislike new constraints." This is me trying to figure out what your basis for disliking this is, and to be honest, I'm trying very hard to find reasoning that is deeper than, "it won't let me do what I used to do, therefore, it is bad," which is really the way this entire argument comes off if you refuse to elaborate on why any of those changes are bad. Remember, you still haven't justified why any of what you've cited is bad gameplay with anything other than, "I don't like it." I'm starting to come to the conclusion that you really would be best served by what earlier commenters have suggested by going into the cheats menu and switching the older drag model back on. What you are complaining about, fundamentally, can't be fixed universally. If your standard for "good" gameplay is that the aerodynamic properties will match whatever the player wishes they were... then you're chasing a lost cause. Any set of changes to make whatever example you come up with behave the way you want will also make some other example shift from behaving as you'd like to behavior that you don't like. I think you would be best served by either creating a mod to make the changes you want as an example (and then deal with the unintended consequences), or to just own up that you want the old behavior back and switch to it.

@Jared:Why are you ignoring everyone saying that both AoA and camber contribute to lift? I'm not surprised that you didn't bother to look at the derivation for Thin Airfoil Theory, considering that it would have explained both the contribution of AoA and camber to lift, as well as explained how pressure disturbances can move forward from the trailing edge to create the upward deflection of the air just ahead of the wing. This stuff is documented, explained, and tested very well; you don't get to argue that the theory is wrong (which is what you are doing, don't try to deny it) when it has been verified so much without being a kook. If you are a physics student, you should be well equipped to work through the integrals and calculate the streamlines around an airfoil at an angle of attack, and you will see the upwash at the leading edge created by circulation around the wing; it's a very well documented effect, needs to be considered in the effects on the fuselage in airplane stability, believe it or not. Seriously, go and look at the theory; thin airfoil theory, potential flow, and the singularity distribution method of generating solutions to linearized potential flow (focused primarily on vortex distributions) will have everything form nice and completely. Your thoughts would be correct, but you're forgetting that this is subsonic flow, where the downstream effects can shape the upstream flow, and that's what happens; the entire flow around the airfoil in subsonic flow is controlled by the flow at the trailing edge. Now, here's two last questions: if you're right, and AoA and camber are not the cause of lift, what is the mystical aerodynamic-like force that only cares about the plane's orientation wrt the ground, without regard for any fluid dynamics? And why are you so insistent on arguing rather than actually looking at tested theories? This is like going and arguing ballistic trajectories with someone who hasn't started with kinematics. @andymc1: Known issue, should be fixed in the dev build, hopefully an updated version soon-ish once I get some other things fixed.