TurbofanDude

I have personally added that feature and it'll now be in the next update.

While I can't promise everything, I agree that point 1 should be a feature. I'll get it on the list for the 1.1 update.

Apologies for the late reply here! The easiest way is on our Discord or via our social media outlets - as of now, the P3D version is still behind visually, but it'll be updated soon.

Hi all - just wanted to comment on the pushback issue in case other developers experience this. The problem was caused by the fact that P3D treats any contact point with a lateral offset of 0 as a "nose gear", even if there is another point further forward. We've moved the center gear 0.01 to the left and now it pushes back properly. The 1.1 update will address the embarrasingly obvious issues (animation clipping, broken controls, the pushback problem). Code-wise, the P3D version is already nearly identical to the MSFS version. Edit: To anyone else, I realize this post is now coming up on a year old. We've made significant improvements to the product since this topic began (it did, admittedly, need work when it first released).

Rob, Your whole reply impressed me - very well said. Henry, In response to your original question, I've got a few points that I think about when picking a language. I'm fluent in both C#/.NET and C++ (and C++/CLR, which is .NET for C++). My thought process on using .NET is this: similar to what Rob said, many times, chunks of the code aren't available directly to client and won't be as easily accessible to a "hacker" or decompiler or if it is, does it really matter? The other thing to consider is the amount of time it would really take somebody to reverse it. For example, smartCARS (our ACARS platform) was written in C++ using the .NET (CLR) for the GUI. There are parts of it, that, if decompiled, would reveal something similar to the original source. That said, it's mixed in with native code that generates line after line of bit shift operators or ridiculous references that I can't even figure out when comparing it line by line with the original source. The amount of time it would take to put that back together, even with partial source, isn't at all worth it for a "hacker." Our installer system is written in C# - if it's decompiled, yes, it would be visible. In this case, it's not the technology that's important, it's where it's used. There are only so many ways to accomplish the same task of installing files. The above points, of course, supplement Rob's points. Simply using C++ isn't an obfuscation method - it does stop things like dotPeek from reversing it to easy-to-read source, but it doesn't make it edit proof. To answer the original question, what keeps us using one language or another? It's what we need - we deal with language-relevant problems as they come. If you need flexibility and integrated support/tools - use C#/VB. If you need heavy optimization or native interaction (gauges, etc.) - use C++. That said, ultimately, it's mostly up to developer experience and preference as both sides of the field are starting to balance out.

Oh, I know it. Still an exciting thing to think about. Also kind of scary that there are so many companies potentially losing money and productivity by under-utilizing modern technology.

Though I don't think W10 is ugly (I like the modern UI), I can personally attest to Brandon's comment about holding developers back. There are so many cool, new, integrated features in the newer OS's that we have to ignore due to backward compatibility. I can't wait to play around with some of these things once we get past the age of the aero desktop.

So wait... everyone complains that Windows 8 has tiles and a start screen and that it's too different from 7 (and yes, the problem IS INDEED people fearing change). Then, in Windows 10, they add the features people missed from 7, so now, everyone complains it's too much like 7 (or, specifically, about the features that are like 7). Different strokes for different folks, I know, but really, are any of these people thinking logically? I haven't seen a single LEGITIMATE complaint. I can respect things like "it doesn't work for me because A, B, and C", not a paradoxical, circular argument. Open mindedness and a little patience can go a long way. (This is after spending time working with now four different Windows releases and two Linux distributions as a desktop operating system. I'm not a ######, believe me, if I could get another OS to keep the same application compatibility as Windows, it'd be off my desktop by the end of the week.) I'm excited to see Windows 10 in action. I've gotten used to the start screen in 8.1 as I can't stand running out of date anything and I see 10 as a welcomed improvement to my desktop workflow.

Agreed - I tend to avoid "Metro Apps". They're usually rather useless and ineffective. I haven't experienced the ads myself, but I believe it, and I'm sure that'd irritate me.

Oh, Uplay isn't TOO bad - Origin is what kills me. It's no tablet though, it's a rather powerful desktop.

Here's my Windows 8.1 desktop - it seems to get the job done.

Hi guys, Normally, I can find an answer prior to posting a topic, however, this one is stumping me. I have Windows 8.1 x64 with updated (one shy of latest) NVIDIA drivers for my GTX 670 and 8GB of RAM. I can't seem to be able to get through a whole flight. I get about an hour or so in and the sim freezes and silently closes (no exception, no crash message, no event viewer log, nothing). I was flying the NGX both times and running Squawkbox externally (all internal modules removed from the dll.xml) - only running the Addon Manager (bglmanx) and FSUIPC4 (and of course, the NGX modules). Any suggestions on debugging?

Why are we turning a legitimate conversation about the future of the FS world into a bickering match over Windows 8? I like it and use it, but I find issues with it - it's certainly not perfect. Edit: Maybe we're not quite there yet, but I can see it coming.

I have to say, I wish developing a flight simulator was as easy as people seem to think. Sarcasm aside, Brandon is right in that developing an aircraft, although difficult, is a minuscule project comparatively. Have you ever read the credits at the end of a high-profile game? The list of developers who had their hands in the physics and rendering engine is quite long. The task is simply too large for even a few developers to do well and in a timely manner - this, in combination with the concept of battling the enormous existing market competition, is what discourages most developers from doing this. I imagine that a new platform will emerge as king once FSX is no longer compatible with the latest Windows operating system - that's when we'll get to see what it really takes to create such a massive product.

Sir, Please check your PM box sir!