Ben Russell

Let's be clear here. The problem lies with the third party plugins not fully understanding how the SDK hangs together. If you can stop pinning this on me that'd be tops.

Sound mix bugs are being addressed. The team has been trying to ensure that people with low-end sound cards get an equal experience to those with normal hardware. Getting sofware working is one thing, getting it to work for everyone with every combo of hardware is quite another. All dev machines have no problems at all letting us use as many sound sources as we felt like. (It's nearly all software mixed on our Quad+ Core machines now anyway) Some customer machines seem to have a 16-voice limit so Nils has been reviewing the code to "swap" sounds around between those maximum 16~ active voice. Sadly this means we went from a perfect sound mix to a bunch of sound bugs while we try and pull in support for the lowest end hardware. The dust will settle, the awesome sound mix will return. Thanks for your patience. Known bug: No. It's a hardware feature of the real aircraft. Winglets take up the same physical space as the logo light bulbs so they're simply removed during retrofit. A sticker or label or "something" will probably get added to the switch at some point because this item does catch a lot of our users out. Cheers, br.

DO NOT OVERHEAT MAC BOOK PROS. I have two GPU-melted systems to my name. They desolder from the boards and you end up with a lovely paper weight. Go to absurd lengths to cool your machine. Run it on Dry Ice. Both my machines were claimed by X-P. You will kill your MBP, it's only a matter of time. ( I routinely clean my systems about every six months or on the very first heat crash.)

You have winglets active.

Your log file indicates that something is cycling through all the available liveries very rapidly. Any idea what might be causing this? Is it something you're doing with a button press or is it something else going on?

Can I interest you in a Flashlight app in exchange for a complete copy of your cell phone data?

We will look into sharding (possibly using co-routines) the workload when we've got the bugs sorted out. Trying to do it now would be a nightmare. Worker Threads eventually but sharding will be easier to do now with the codebase that IXEG have built up.

The X-P SDK has no facilities for this beyond calling for a scenery reload. http://www.xsquawkbox.net/xpsdk/mediawiki/XPLMReloadScenery

As a long term objective I do want to add "Worker Threads". These would; - Exchange data with the existing Gizmo thread via a text packet containing what's basically a large lua table that's been serialised into a "JSON" packet (but Lua syntax). - Only have access to the basic Lua API's. This will allow a massive expansion in power at the cost of not having any access to things like the X-Plane nav databases from the worker threads.

Many reasons. Thanks anyway. It's easy to throw a few sentences together and make it sound like we're being lazy. In reality; - The X-Plane SDK hates threads. It's recommended not to use them everywhere. - The systems are written in Lua. Lua has no native support for threads, or binary interchange structures. - Adding a simple to use, yet powerful, cross platform (as in all three) threading API that maps well to Lua and the existing Gizmo API that artists expect while also explaining why NONE of the x-p SDK functions they want to use are still available is not "a sentence" worth of difficulty. Threading is hard. Threading in a cross platform, artist-abstracted, script-friendly way is even harder.

I've got this logged as a bug to tidy up in the next Gizmo release..

Disable Windows defender for X-Plane. (Provide more info about your machine please.)

xsaitekpanels is very likely to cause issues.

4; If you want to go back to 1.0.2 just put in the hotfix code for 1.0.2

The entire team is very transparent and available. Why push the limit and cross such an obvious boundary? And then to call _me_ rude.

So how much do you get paid? Where do you work? What position do you hold? Fun, isn't it.

If you can't be polite about keeping your nose out of our financial matters please don't post. I'm only responding in kind.

Talking to Cameron now about creating a dedicated "Download Reset" request list in the support systems so that; a; you don't have to fill in the contact form to file a request. b; we can process these simple requests more efficiently during high volume periods. Thanks for your patience. I've raised this conversation with Cam and hopefully he'll sort you out shortly.

ESP8266

Three. Ask a silly question, get a silly answer.

Callum. This Log.txt looks like its from an X-Plane session where X-Plane did _not_ crash out to desktop... If you get another X-Plane crash we need you to go straight to the X-P folder and make a backup of Log.txt and GizmoLog.txt Both of these files are over-written with fresh data every time you start X-Plane. That said; There is nothing that stands out in your log file this time. I have seen people having issues with w2xp scenery packs. Not sure if you have any of those. Thanks for the report, please let us know if it happens again. br.

http://www.lmgtfy.com/?q=how+to+write+a+bug+report

Also thinking about adding a "Hardware Mode" to Gizmo that slows it down somehow, perhaps caching the datarefs in lock step with the frame counter as a clock signal. You might suffer a minor FPS hit because of the extra book keeping but it's a fair trade.

Part of the problem fun is that Gizmo gives very raw access to the scripts running systems. It drops right into IXEG systems with as little overhead or governance as possible. Because of this it could be a couple of rounds before we really get this sorted out. For now I'm going to focus on porting the replay system into the plugins realm. This lets me lock out all the manipulators and commands from any scrambled triggering of state and systems while the replay scrubber gets dragged around. I've had a naive look at this a long time ago. I don't own any hardware so I had to hack together a test harness... it's pretty basic. If I could figure out a software harness that can replicate the same kind of crash as hardware-module owners are seeing we'll be a long way towards fixing this up. https://github.com/benrussell/xpl_cmd_flood/blob/master/xpl_cmd_flood.c