TurbofanDude

Agreed - we undershot the price on the 717 (though, given its... troubled launch, that was probably for the best). The price we initially decided on for the MD-11 would have been fine in the P3D-only market days, but the curve is changing. We'll keep reviewing to make sure we put it at the right price.

Full disclosure, I have not read all 9 pages of discussion here. That said, we've heard the criticism of our pricing decision and we are not ignoring it. It's really important for us to select a price that is reasonable to both our team, given the years of work required to bring the product to market, and to the customers we expect to purchase it. The market is changing - this is undeniable. We are evaluating options going forward to ensure we put this product out at a fair price. As always, we appreciate your continued interest and support.

We're aiming to get the final update out VERY soon.

We definitely appreciate the support - and we always do promos during events! @GameSyns is the marketing guy, so exact specifics are more up his alley.

We've been working on addressing that in the last few updates as best we can.

@DaveCT2003 You can see an itemized change log, along with the dates of release, here: http://forums.tfdidesign.com/index.php?/topic/2268-beta-change-log/ Regarding the view switch CTD, I'm very interested to hear your findings. We've been attacking it from the debugging side but have been sent down the rabbit hole of random, unrelated DLLs and useless call stacks, so a different input on it will definitely be a good thing.

Yes, the system that TrueGlass uses is a full particle system that generates real-time particles and simulates them throughout their life cycle. This is how it avoids the repeating-texture effect and is able to react properly to speed changes, etc. I have updated the wording on the pages for TrueGlass and RealLight to settle any worries about source model access - we would NEVER expect third parties to send us the source for their models. It was just a bit ambiguous wording.

@Jovabra I PM'd you so we can solve this directly - I don't want to ask for anything (email, etc.) publicly.

Did this get resolved via ticket?

All tickets get replies - if you didn't hear back, it never reached us. It sounds like you're having an issue getting our replies - have you checked your spam box? Have you messaged anyone on the forums regarding it? Have you attempted to see what's going on anywhere except venting on a third party forum we may not even see? I don't mean to be overly harsh, but we take great pride in working personally with everyone that contacts us, so it bothers me to see a post like this, especially knowing we haven't exhausted our options yet.

6 years later, and in Prepar3D v4 now, and this is STILL the way it works.

We were having some intermittent issues this morning, it SHOULD be starting to get back up now.

No, it absolutely is a matter of being complacent. We've been trained to accept mediocre as fantastic. Poorly optimized code can bring even the most powerful of systems to a halt. Nobody ever said you'd have 1m resolution imagery for the entire world - you use repeating textures setup in a way to blend naturally, maybe with some additional maps to help it determine proportionate temperature, etc. to blend as it moves across the country and world. Again, the possibilities are endless as soon as you start thinking outside of the box. That said, a GTA V level world for a simulator is INSANE and not a reasonable goal, of course. There are things like Unreal Engine 4, which has been used to create large scale flight games, that are capable of immense things at 60 FPS. Yes, you're correct, one bad feature can ruin it - this is why we should expect developers to understand this and properly optimize their code (which very little do). Even my own code can use improvements - the second you assume it's somebody else's fault or that that's all you get, you stop growing and we end up with an 11 year old platform being dragged forward. This is all from my 6 years as a professional programmer, including experience with Direct3D and HLSL, I'm not making things up. It's time to start thinking outside the box and stop accepting mediocre. That goes for both sims.

It's sad to see it come to this. Such potential, and so far, questionable, at best, ethics and business around it. Based on the information currently available, we share your thoughts.

Please open up a ticket with us - the second the display lag is fixed we will nail down CTDs are soon as possible.

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.

Just to correct the record, the Visual C++ libraries aren't actually for installation (they're for use by the program itself - providing extra code for Windows-based programs/dlls/libraries).

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.