Ben Russell

You need to post your Log.txt and perhaps a screenshot of your SkyMAXX and X-Plane rendering options. These will be far more useful than pictures of the crash report message. Have you tried reducing your options and/or different aircraft, different scenery? X-Plane is a complicated collection of parts these days and can be easily crashed if you pile on the options and the content all at the same time.

The simplest way to find this is to start backing off your settings until you're satisfied by whatever compromise you have to make. You're at ~8%. Try 20% ..30 50... Maybe back down to 40... The trade offs will vary by the options you've selected for yourself... It's up to you where you feel you can compromise.

Here's a video of how "Impostors" work in a graphics engine like SkyMAXX. Jump to 2m 40s if the embed doesn't work..

Instead of looking at the VRAM left as a whole number; eg "300 meg", look at it as a percentage of your video cards resources. 3.5 x 1024 = 3584 300 / 3584 * 100 = 8.4% Do you really think your video card enjoys being thrashed with only 8.4% breathing room to allow for dynamic content? Run your OS to 93% of its ram usage with no swap and see how fun it gets.

Thanks for posting the Log.txt file. It's pretty clear that SASL is going crazy. There are lots of repeating nonsensical messages in your Log.txt file. I cannot give you any advice as to what they mean. I can say that problems with SASL are extremely rare and no one else is reporting any. Because your case is an isolated event limited to only your machine I'm going to have to ask you to use a different aircraft. I suggest choosing an aircraft that doesn't use SASL at all. As the product (RWC) is new to market the next few hours may show that other users have a similar problem to yours but I certainly do not expect this to happen.

Please attach the entire log file. In the mean time, try using a different aircraft. SASL is clearly throwing an error just before X-Plane explodes.

You should already have your SkyMAXX 3 discount code in your Inbox. Discount codes for RWC will be sent out when the "Upgrade Window" expires. Probably just before RWC is placed on sale in the store. This may mean that you need to wait a few hours in some cases while the Internet delivers mail. In most cases it should take only a few minutes from the time Cameron sends the discounts out until the time you receive them.

Fragmentation and an overloaded VRAM demand could easily turn out looking the same as a memory leak. Reduce your scenery and other options so that SMP has a clean-sheet of VRAM to work with. Then when your driver is NOT fighting with possible fragmentation run your long duration burn in tests and I suspect you will find no "leaks".

http://www.x-aviation.com/catalog/contact_us.php Please do not send multiple e-mails or this will delay our response to you!

There'll probably be more content there as the product launches Tom.

Please just be patient with tech support. I'm not 100% sure what the results of a second purchase will be. I believe Cameron will have to process it manually to increase the allocated slot count. That would result in you waiting for two purchases which would frustrate you further.

We work on a "per computer" basis. Not per hard disk. You can install 100x on the same computer and it will only count as one. Re-install your operating system (Windows, Linux or OSX) and your computer is considered a different computer.

At this point I think it's fairly safe to say that Gizmo has more known bugs than IXEG. We just try to avoid the ones that splatter on your wind screen.

video timestamp please?

Fir, Maple and Cedar are clearly present in the photo!

Top Secret photo of the team hard at work beta testing our latest build;

From my discussions with Ben Supnik; - X-Plane may use Vulkan some day. - IF it ever does, it will setup an managed OpenGL environment so that plugins will continue to work as they always have. - Various flavours of OpenGL and probably Vulkan are available now to plugins if you can be bothered to do all the system calls to "spin one up". We get a default OpenGL context to play in that supports almost everything you'd ever want to do with X-Plane so I'm really not sure if anyone bothers with a custom context. Vulkan isn't some magic bullet, if anything it represents a massive hurdle in the way of small development teams to adapt to. It basically throws out all the convenience of a driver for the sake of ultimate speed, if you want it and need it. Epic needs it. They build Unreal Engine which is mind blowing in capability. Truly cutting edge. How many small teams do you really want doing all the micro management of the GPU state? Seriously; if nVidia and AMD have so much trouble publishing high performance bug free drivers for known systems like OpenGL that have been around for twenty-four-years how many average developers do you think have any hope of coming anywhere near those kind of performance figures? I see Vulkan as a massive step forward for things like VR where latency is nauseating. For us, working with X-Plane, we're far better using tools off the shelf with known limits, APIs, demos and documentation. No ones even come close to the possibilities of OpenGL yet. Just the idea of "Vulkanizing" something represents such a massive amount of GPU micro-management that I haven't even looked at the specs or docs. It will be some years before there's any need. I'm still trying to teach artists about VBO's and Shaders. Big teams, on big name games, all work in the same space. They can sit down in pairs, shoulder to shoulder and polish things out like you wouldn't believe. Our teams? We're peppered all over the planet, working as lone individuals most of the time. There are various effects in our products, shipping and otherwise, that utilise various mixtures of primitive OpenGL and OBJ8 hackery to work through the limits of X-Plane, the SDK, alpha bugs, FPS limits, customer hardware, etc. We have plenty of work cut out for us moving them into "modern GL". @Tom; you've seen some very small snippets of the stuff I've been working with, rain shaders and so forth. I think you'll be amused with some of the things we unveil in future. There's a lot we don't show. I think the IXEG 737 will be a transformative product for X-Planes future, in more ways than one.

I had a quick look at this with a color sampling tool and none of the pixels in the cloud zone are above 4% brightness. There's not much margin there and pure black in reality is extremely rare. If anything, X-Plane needs to lighten it's landscape. 0% light return from land is.... unlikely.

Hardware is guaranteed to get faster. People are guaranteed to get slower. It's not fair to expect that ancient hardware is specially catered for on a multi year project. Having said that; hundreds of hours have been poured into Gizmo in the last year or so to make it perform as fast as possible and more time will be invested in the 737 to ensure that your modern hardware is utilised where and when we can. It's more prudent and beneficial for all our customers to focus on making any product run as well as we can on modern and future hardware than it is to spend time making it run on ancient hardware that is, relatively speaking, the cheapest part of the development chain and the only one certain to be thrown away eventually. This becomes more and more important as we start moving into the age of VR. Modern VR latency requirements and old legacy hardware support are simply mutually exclusive options. I don't think there are any current X-Plane payware products truly technically suitable for use in a VR sim at every level. It's very easy and very tempting to use legacy GL features to provide features that users want today while getting us into a bit of technical debt for features people are going to want tomorrow. (200 fps, VR immersion, full use of modern GPU's etc. etc.) The sanest course is to set the GPU resource usage as high as possible because by the time your product is eventually released the hardware will be there, or be there shortly. ...a bit of a rant, but please, over five years plus, it's impossible to set a legacy hardware target. I think everyone will be able to find a happy medium. It's an experienced team building the product on a varied set of hardware.

Kinda hard to sneak in a jerry can of 50,000 lbs...

"Ground? Is this ground? Hi, can I get some gas and, um, a pushback truck over here at um... gate... um..." "Does your mom know where you are?"

I had not come across ZMQ ... I became interested in MQTT because of the ESP8266 uC, it seems ZMQ isn't quite so easy to pull off there. In any case, it'd be some kind of new plugin that adds protocol support. Just posting to give a general heads up that we're aware of and interested in some of the more esoteric ways to setup custom hardware. Thanks for the pointer.. bookmarked.

There's also my somewhat dormant "x-httpd" project which is part of the roadmap for getting Gizmo-powered systems onto things like tablets and smart phones as a "Remote FMS" input system. External hardware and integration is definitely on our radar, at all levels.

I've been dabbling in the world of Arduino/ESP8266 and IoT. My preferred protocol at the moment is MQTT. Gizmo will be getting more powerful USB API options in future too so we can make sure any of our product integrations are 100% seamless.

Everything you have posted in this thread has been inflammatory pointless and inaccurate. It begins with you digging up the thread after five idle days for no other reason than to serve your own curiosity and share your own opinions. Then today, after another three-four days idle, you come back to share more of your expert opinions while ignoring what I have attempted to point out. You have both misunderstood and twisted what I have laid out very clearly. I gave a very crude simplified example deliberately to show basic math and you have attempted to turn it into some kind of elaborate technical argument that it was never meant to be. As a programmer with such a wealth of experience you should know that while the bulk of the work is reusable there are always going to be difficult annoying edge cases that suck up vastly out of proportion amounts of resources to solve the problem they're responsible for. What % of the market would it serve to document an exact technical example? How much more time would it waste justifying what is ultimately my FREE CHOICE to make? You have attempted to undermine my post to inflate your own Ego by attempting to technically belittle a post that I opened with the words: "Gross simplification;" How can I possibly have made the intent that post any clearer? Further, after highlighting in red bold text that Linux is the only source of LOSS, you attempt to twist my words into insinuating that I believe OSX to be a lost cause? I have put the CLEARLY LABELLED AS CONTRIVED numbers there for you in black and white, and yet you attempt to turn them into something else. I have been saying this stuff for years. I have been told that I am wrong for years. I have been harassed into supporting Linux for years. When it comes to actually backing yourselves, supporting yourselves, spreading the word yourselves, the way "The Linux community promises it will" ... what then? Crickets. Nothing. Silence. Until the next round of harassment. But by all means, keep telling me how I'm wrong. Now, please, take it elsewhere. I don't care about being your internet friend. I'm only here for the engineering.