After a minor hiccup this week with the XSquawkBox server list which required a last second fix to be made, XSquawkBox 1.3.1 is now available.
It’s highly recommended that all X-Plane 10 users upgrade to 1.3.1 in order to avoid connection problems to the network in the near future.
Please Note: if you are upgrading, you will need to explicitly re-select your preferred server when connecting for the first time after the upgrade – the way XSquawkBox represents VATSIM servers from the downloaded server list has changed internally, and we can’t fix your preferences automatically.
Highlights of the 1.3.1 release are:
- Bugfixes to the VATSIM Server List support which should fix any server connectivity issues related to name resolution problems.
- Linux support is back – although it’s limited to 64-bit Linux systems only, it now contains fixes for some long standing bugs to do with audio device selection.
- A bug fix from Roland Winklmeier of the Swift Project for a potential crash to desktop issue in the VATSIM voice compression codec. Many thanks to Roland for this.
You can download 1.3.1 from the Download page.
As Wade previously mentioned, I’ve been hard at work and we now have a new release of XSquawkBox ready for Windows and MacOS X users.
The new release of XSquawkBox features:
- support for newer CSL objects
- improved compatibility with X-Plane 10’s HDR and global shadow rendering features
- improved manual
You can download the latest client from the download page.
I’ve also received reports from some of our beta testers that the new release does not exhibit the issues they had previously experienced with audio static on Windows.
As for Linux, I’ve been working hard on trying to get the Linux plugin into a usable form – we have everything except sound working reliably, and a surprise breakthrough I made last night unveiled the real source of the problems, and I feel that it’s now safe for me to announce that a closed beta for the Linux plugin will be commencing shortly.
I’d like to thank all of the people who have volunteered for the XSquawkBox 1.3 closed beta – you’ve all been a great help in getting this release out the door.
I’m happy to announce that after some incredibly lengthy delays due to the VATSIM NDA process, two new developers have come onboard and started work on XSquawkBox.
Chris Collins & Ivan Stankovic will be working together on future versions of XSquawkBox.
Chris has worked hard on a new release and it’s ready to go for Mac & Windows. I know many of you are waiting on a 64-bit release of the Linux client, and Chris has been working hard to try to make it happen. However, the problem is in order to do a 64-bit Linux client, the Linux audio code is going to have to be rewritten. Progress is being made, but it is not yet complete.
I’ll let Chris follow up here with details on the new release availability & specifics on the Linux issues and their progress, since he’s the one that has done the work and deserves the credit.
Life has a way of changing. I’m not currently flying or controlling on VATSIM at all, and have almost no time to program. Unfortunately, XSB support is suffering because of it, and neither Ben nor I want that to continue.
I’m looking for some help in maintaining XSB. The ideal candidate would have:
- Experience in C++ and OpenGL
- Ability to compile on OS X, Windows (using free MS compiler) and Linux
- A PC capable of running Windows and Linux for X-Plane/XSB testing on those systems.
- Experience with CMake is a plus
- Be over 18 years of age and willing to sign the VATSIM NDA (which basically just says you won’t release proprietary code)
- Time and enthusiasm for making XSB and VATSIM better
However, that is only the IDEAL candidate. It may be that such a person doesn’t exist at this point and time. It may be that we need multiple people – one dealing with OS X, one dealing with Windows, and another dealing with Linux. Or some other combination of the three.
With multiple people, the requirements for each person go down. For example, if you know C++ and are a Linux person, you don’t necessarily need to know OpenGL if we have others who do. You just need to be able to compile and test on Linux.
I’ve received a lot of offers for help over the years. While appreciated, those offers have not been acted upon because for the most part, XSB was working. However, now is the time we do need the help. If you think you are a good candidate to help, email me at:
and let me know why.
Version 1.2 of XSquawkBox is available on the download page. The only change in this version is the removal of the expiration date.
For the Linux users, progress has been made in completing the Linux build. It’s not yet ready for release, but I hope to have an update soon.
XSquawkBox 1.2b is available on the download page.
This version resolves the incompatibility with the Gizmo plugin, used in many aircraft such as those from X-Aviation.
XSquawkBox 64-bit is here for Windows and Mac in the form of XSB version 1.11. Work is occurring on the Linux version, but we do not have a planned release date yet.
It should be noted that the packaging of XSB has changed with this version. Make sure you follow these instructions:
1) Move your current “XSwquakBox Resources” folder out of the X-Plane/Resources/plugins folder to a safe location, such as your desktop.
2) Once you unzip the new version of XSquawkBox, inside the “for plugins folder,” you will find a folder called “XSquawkBox.” Drop that entire folder into your X-Plane/Resources/plugins folder.
If after doing this step, XSquawkBox does not appear in your plugins menu in X-Plane, you have not installed it correctly.
3) As you desire, you may drop custom resources such as CSL’s from your old “XSquawkBox Resources” folder into X-Plane/Resources/plugins/XSquawkBox/Resources (the new location for such files).
Note: Due to changes in the Apple compilers, XSB 1.11 supports Intel-Macs only, and OS X 10.6 (Snow Leopard) and later.
We have received a potentially useful Mac audio patch, and we are following up with the author now. I am out of the office next week, but I will try to post something more definitive about future beta plans later in August. In the meantime, we are all set for code contributions.
In a previous post I listed two bits of code we were looking for: a 64-bit clean port of libxplanemp (which XSB, Pilot’s Edge and X-Ivap use for multiplayer visualization) and a rewritten audio HAL for OS X, since the old one we use is based on technology from 1635.
Well, we don’t need libxplanemp anymore – if you look at github you’ll see we have a 64-bit branch, so that’s taken care of. In fact, the only thing we need is Mac audio.
When we have Mac audio, we can figure out how to run a beta program. If enough time goes by eventually I can code it myself, but code for VATSIM is something I do in my spare time when not working on X-Plane itself and chasing a two-year-old around the house. (His idea of a fun time does involve feeding plastic food to a stuffed dog but does not involve sitting quietly and watching me code. Who knew?
So if you are the kind of person who knows how to write code for OS X and can hack out a new implementation of the audio interface, you have the power to get things moving in a big way.
When last I checked, VATSIM has a policy that developers need to be registered and sign an NDA to work on VATSIM code. I will not go off into a rant about this policy here*
But there are a few parts of XSB that are open source; if you are a programmer and would like to work on moving XSB (and other plugins) to 64-bit, you can work on these open source problems now, no need to sort out VATSIM stuff.
- Core Audio Support. XSB’s audio comes from implementations of an abstract audio class; fortunately this class is open source. You can download the current audio code here. If you know how to write Core Audio code for OS X and can write a Core Audio back-end for this abstraction, this would be huge in advancing the 64-bit port. (The current SoundManager code, besides being quite embarrassing for everyone involved, is not portable to 64 bits.)
- 64-bit safe libxplaneMP. XSB’s CSL multiplayer code comes from libxplanemp, which Wade has posted to github. If you can port this code to 64-bits, that’s another win in moving the plugin over.
The Problem of Open Source Management
The main problem at hand is that Wade and I are out of time. This unfortunately means that not do we not have time to code, but we also don’t have time to manage other coders. Invariably we will be contacted by more volunteers than we need, some of whom will provide no useful development work.
My hope is that by posting the two tasks above, tasks that can be entirely worked on without XSB itself, without any NDAs, and without repo access, we can let motivated developers get started on real work without us. This way, Wade and I don’t have to be management bottlenecks.
* If you are part of the VATSIM administration and would like to help unjam software development, contact me, and I can tell you what ‘opening’ of the software policy would be directly useful to projects like XSB; we don’t need complete GPL-style communism to get more work done. 😉