XSquawkBox 2.0 Released

The stable release of XSquawkBox 2.0 is now out. Thanks to the users who followed the issue reporting procedures and provided valuable information to help iron out the issues through the beta.

XSquawkBox 2.0 includes some quality of life changes over beta6 to reduce user confusion, but has no significant changes in the voice system or other major components over beta6 otherwise.

Now that XSquawkBox 2.0 is out, I will be focusing efforts on essential fixes for 2.0 only, with any new effort going into 3.0 which will target X-Plane 11 only, and will specifically target Vulkan compatibility and a VR friendly user interface. I hope the delay to 3.0 will be a lot shorter than the delay from 1.3.3 to 2.0.

With the release of 2.0, XSquawkBox 1.3.3 will be deauthorised from the network. You must upgrade to continue using XSquawkBox.

Continue reading “XSquawkBox 2.0 Released”

About the XSquawkBox/VATSIM X-Plane Simulation Rate Enforcement

Introduction 

I’ve written this article to explain a bit about the simulation rate enforcement decision, how it came to be, and the goals and theory of operation of the actual mechanism as implemented in XSquawkBox and other clients that use the XSquawkBox detection algorithm. 

I’m also going to briefly touch on the alternate plans I considered, and where possible, why I didn’t follow through with them.

Continue reading “About the XSquawkBox/VATSIM X-Plane Simulation Rate Enforcement”

Minor Update Incoming…

I’ve just been informed by the AFV team that the standard radio effects have been reworked slightly – I’ll be posting an update at some point during the week to incorporate those changes.

You might want to hold off on updating to 2.0 until tomorrow (Tuesday) just in case I get the updated effects out before 1 April.

Reporting Issues

Whilst a lot of our bug reporters read the instructions and do the right thing, there are still quite a few people who report potentially serious issues and fail to read the instructions on the page.

I cannot stress this enough – you must include the full, unedited, Log.txt in your submission.

Anything less is mostly useless. A number of our issues to date could not have been resolved without the additional context the full Log.txt provides, as well as the fact that most people who try to filter it, do not actually capture all of the related messages.

Just copy and paste the whole Log.txt when you report an issue.