Work in Progress Report

I figured users would like to know what’s happening in the world of XSquawkBox given all of the movement on the VR front at Laminar lately.

Just as a general disclaimer:  Any development or features mentioned in this blog post may be subject to change prior to the actual release.


There are two distinct branches of XSquawkBox coming up – a 1.4 release which largely contains bugfixes but no major interface changes for X-Plane 10 (and maybe 11 if you don’t want to deal with the changes in 2.0), and a 2.0 release which will be specifically for X-Plane 11 and newer, and will be snapped up to the current accepted practices for X-Plane at the expense of familiarity and compatibility with older versions.

Due to the way development is shaping up, XSquawkBox 2.0 might be released before 1.4

After these releases, XSquawkBox 1.x will most likely become a maintenance-only branch with no new features, and will most likely be retired by the end of 2019.

Possible Changes in XSquawkBox 2.0

This is a rough list of the things that are likely to change from the current status quo in 1.x:

  • Strictly for X-Plane 11 (or newer) only.
  • VR Support
  • The Text Radio window will become a proper floating window, and not a special-transparent one.
  • The Who’s Online window will become a proper floating window and not a special transparent one.
  • Map Overlays for locating other aircraft and active controllers
  • LegacyCSL removed completely before the final release of 2.0
  • Text Labels removed completely before the final release of 2.0

Bug Fixes and Improvements that will be included in XSquawkBox 1.4

This is a rough list of the stuff that’s working in the interrim 2.0 family branch(es) that I will be backporting to 1.4, or will be added to 1.4 because it makes sense to do so:

  • LegacyCSL Texture ID allocation bug with certain third party aircraft (libxplanemp bugfix)
  • Obj8 CSL simplifications/improvements:
    • GLASS components are gone
    • LOWLOD will probably be removed shortly as libxplanemp is not using LOWLOD anywhere except as a fallback for the lights-only model
    • The lights only model will be used when the aircraft is beyond full model range (surprisingly, this was never in Ben’s experimental Obj8 code and I never noticed until I refactored it).
  • Obj8 Asynchronous Load (it works in the 2.0 branch – pretty sure I know how to fix the legacy branch now)
  • Text Label Size with HDR/FSAA Bug:  Turns out there’s an art control which tells us what the scaling ratios are for the FSAA mode in use so we can correct the text projection when we render the labels.
  • Anisotropic Filtering will be enabled for legacy CSL aircraft to match the simulator’s own setting (Anisotropic Filtering has been in libxplanemp for a while actually, just turned off by default because I didn’t want to add a separate option to control it in XSB).

Two of the above fixes (Text Label Size and Anisotropic filtering) are dependent on specific Art Controls being available to allow us to match the simulator’s behaviour (Sorry Ben).  Fortunately, both of these do have non-fatal fallback outcomes if the art controls go-away – just that specific behaviour will revert to the old (absent or slightly broken) state.

Ground Clamping

A simplified version of it is in libxplanemp 2.0, but XSB 2 will most likely not use it when ACCONFIG is available as a lower overhead alternative will be available to us.  This should make it into 1.4 along with ACCONFIG support.

libxplanemp 2.0

In the past week, I’ve been hard at work refactoring (and rewriting) a large chunk of libxplanemp.  The changes aren’t public yet and won’t be until I’m happy they’re mostly correct (should be within the next week or two).

  • libxplanemp 2.0 makes use of the new XPLMInstance API which features in X-Plane 11 for Obj8 CSLs, but uses the compatibility wrapper for older releases of X-Plane.
  • ACF support is gone.  LegacyCSL support is optional.
  • Some overlooked queries against the OpenGL state got optimised out – on X-Plane 10.30 and newer, there should no longer be any queries for GL state data through the GL driver, removing a long-standing potential source of rendering pipeline stalls.
  • A bug with LegacyCSL texture loads got fixed that has been affecting FF A320 users, and was possibly also still breaking with older versions of the IXEG 733 on X-Plane 11.
  • The Obj8 asynchronous loader finally works properly, removing the sim stutter as aircraft get rendered for the first time.
  • Thanks to some overlooked art controls, FSAA no longer shrinks or distorts aircraft labels.

Developer oriented changes include:

  • The libxplanemp observer API has been removed as nobody was using it.
  • The callback mechanism has been removed in favor of a bulk push mechanism which applications can use to update a lot of aircraft with a single call.
  • The reliance on XSquawkBox’s configuration callback has been removed, instead favouring a struct which can be get/set using a specific method in the API.
  • Doxygen documentation should be available for libxplanemp 2.0 by the time it’s ready for general consumption by third parties.

11 Replies to “Work in Progress Report”

  1. Looking forward to the improvements in both XSB 1.4 and 2.0, Chris!

    Out of curiosity, will XSB 2.0 allow for sound notifications of incoming text and/or private messages? Also, any hope of SELCAL support?

    1. Aural notification is on the cards in XSB 2.0 only (to fix it in the 1.x branch will require a significant change – the existing plugins should continue to work there). No word on SELCALs yet – now that it is significantly easier for me to add things to the UI, I will see about it once the aural notification work is done.

  2. “The Text Radio window will become a proper floating window, and not a special-transparent one. The Who’s Online window will become a proper floating window and not a special transparent one.”

    This is cool! But will it work in full screen mode too?

    I prefer to not spam my screen with tons of windows when flying but to only see a window when/if there’s something new or I manually open/close such windows.

    The question above with the sound notification and SELCALis really interesting. In case the sound notification is not on your to-do-list – will the respective seperate plug-in still work?

    Thanks for all your effort and hard work. It is amazing what you do for the XP/VATSIM community. Thank you so much!


    1. In XSB 2.0 at least, the windows will be native XP11 windows – these can be undocked by clicking the appropriate button on the titlebar. (Like the Map Window can be). You can have them operate in the traditional multimonitor captured to X-Plane manner, or you can undock them and float them wherever you want. This support was necessary for VR support – the old style windows simply aren’t supported with the changes for VR. (We can’t repose the windows into the VR space otherwise).

      Windows will not pop-up automatically – you will need to summon then when they’re required. This especially goes for the Console/Text Radio – whilst i can force them visible, it’d be too disruptive in VR. I will make sure there’s a mechanism to notify the pilot that a message is pending.

      1. Thank you for your reply. OK, so I understood that full screen mode still will be supported and a notification will be available in case there is a Text-Message. Just like the built in moving map, it would be useful to have the ability to allocate a key to the windows to show or hide them. The perfect solution would be if the client software could run on a second PC via LAN connection to the SIM PC – but I think this would make it pretty complicated.

        1. There will be a command available for show for any window that may be useful in flight. If the window is a “non-dialog” single-instanced window, you should be able to toggle and hide them via commands too.

          That is to say: The console and who’s online windows will definitely have show/hide/toggle commands. The flight plan window will probably only have a show command, requiring mouse/pointer interaction to dismiss it.

          The client will not be split out of X-Plane any-time soon simply because that’ll make it harder to make VR usable. There may be provisions later for an external communications UI to be connected, but it will probably never be able to drive all of XSB’s features.

          1. It seems like I have to learn accepting that people really want this VR thingy. I have no clue how one will read charts and checklists with that VR space helmet on or how to take notes when i.e. receiving complex taxi instructions – but this ain’t be my problem.

            Just one more question about the message notification: Will that be an audible one? Also it would be very useful to have a warning sound if X-Squwkbox gets disconnected (some servers do this from time to time and if you study charts at that time, you don’t even notice that you are offline).


  3. Oooops, sorry – I just did’nt get it, my bad.
    Yes you already answered to the notification question.

    Maybe you’d like to consider my recommendation for the audible “disconnect warning sound” as well…

    Thank you for all your effort. I wish there was a donation button – I would click on it!


    1. There’s nothing wrong with model matching in XSB that I’m aware of anymore – The mismatches I’m largely seeing are mostly a consequence of other people not setting their details correctly to begin with, or a consequence of the decision within the Bluebell CSL to map airline liveries to the generic livery slot.

Comments are closed.