Originally published on https://www.justflight.com/articles/developers-diary-traffic-global-for-xplane-11

Welcome back! Last month if you recall, we found out that X-Plane makes it rather harder to add AI traffic than Prepar3D and briefly talked about the two different areas that will need to be covered – providing the routes and models, and getting the sim to use them.

For one of those two areas I’m lucky. There’s already another package well under way which provides both a traffic database and hundreds of aircraft models, Traffic Global for Prepar3D. There’s a catch though, in that this is for Prepar3D (and FSX and FSW). Those three simulators are very closely related and can to a large extent share data. X-Plane is a completely different beast though, so is any of this any use after all?

Happily, yes, it is! Let’s take the traffic data first. A flight is a flight is a flight. It leaves somewhere then flies to somewhere else at a given time on a given day. Well, unless you’re flying with… no, let’s not go there! Precisely how that information is recorded really doesn’t matter and since X-Plane doesn’t have a flight database format of its own, why not just have it read the Prepar3D data directly?

Yup, you read that right, X-Plane will be reading a Prepar3D BGL file.

Anyone at the back of the room spluttering about cross-contamination, think about it for a second. Why invent a totally new file to do something that’s already done perfectly well elsewhere? Let’s say I did invent a new file format. I’d still need to write a converter or compiler to go from the base flight schedule data to this new format, so it makes sense to just keep using the existing tools and file formats. In fact there are a couple of catches, namely macOS and Linux, but I’ll get back to those later. It helps that I already know the formats from years of writing other tools to read them, and more recently working with traffic and AI on Flight Sim World, but even without that it would still save a lot of time. Okay, okay, and I admit I just like the idea of making X-Plane read BGLs!

What about the models though? It’s not going to look great having hundreds of stock B737s lined up at the gates. X-Plane does, naturally, already have a well-defined file format for models and, equally naturally, it’s totally different to Prepar3D’s format. Option one is to rebuild them from scratch. Not really the most efficient approach, even if it’s just going back to the 3D modelling software and re-exporting. In reality it’s more involved than that anyway.

Another option would be to buy the rights to pre-existing models and then do thousands of repaints, but this would still take a huge amount of time as well as being expensive. Again, certainly possible, but not ideal. Using pre-existing flyable airliners is also not ideal because they tend to be much, much more complex models than you want for computer-controlled planes that might exist in their hundreds.

So how about converting the existing, specially-created low detail Prepar3D ones? A lengthy sniff around the web doesn’t come up with a converter tool. There’s one for taking an X-Plane model and converting it for Prepar3D, but not the other way round. Annoying – but if it’s possible one way then it’s usually possible the other way too. So, that’s what’s been done! X-Plane will be loading a Prepar3D traffic database and converted Prepar3D models.

After defeating some slightly bizarre application of maths in certain animations, it’s working nicely. All of the Prepar3D models have been converted and animate correctly in X-Plane. There’s a few rough edges yet but they’ll get smoothed off between now and release. More importantly, as improvements are made to Traffic Global for Prepar3D, those exact same improvements will be picked up for X-Plane with minimal effort; no re-working, no duplication of effort, just a batch conversion.

When I say “just” a batch conversion, I’m glossing over the whole subject of actually writing the converter! This was several weeks’ work in itself and, even so, still needs a few details to be completed. Reading the Prepar3D models is fine, I’d already got code to do that as part of some of my older tools. Writing out a basic, non-animated model that X-Plane’s “Object Previewer” could read was fairly simple too, Laminar Research are generally very good with documenting things. The tricky bit was getting the animations, effects and lighting right.

Remember, these are external models only, we’re not trying to map a load of cockpit switches automatically, but there are still a lot of moving parts that expect to receive Prepar3D data. Take something simple like rudder deflection. Prepar3D models might be set up to receive this based on a value between -1 and 1 for full left to full right, or -100 and 100, or an actual angle which might be in either radians, grads or degrees, while X-Plane might only provide rudder deflection as a percentage. Prepar3D even supports basic arithmetic and logic in animations, which X-Plane doesn’t, and all of these options need to be handled for dozens of moving parts across hundreds of models.

The goal, of course, is to have all this complexity made invisible in the finished package. If you’ve just bought a traffic add-on and you need to spend the first three hours downloading models from here, paintjobs from there, customising look-up tables, manually copying files and editing configs and running conversions and so on, it’s going to be a bit of a let-down, right? That’s why, as a developer, it’s nice to write about the bits that are usually hidden. The idea is to get everything working smoothly, to make it appear effortless, but the fun and satisfaction of actually doing the programming in the first place is in getting all the conflicting, complex parts to mesh. It’s like the old image of the swan, serenely gliding along on the surface and totally hiding the furious paddling going on underneath.

If you were to look in X-Plane right now, you might think there’s not much progress to see. You’d be right in a way; there has been progress, but very little of it is visible. It’s often the way in larger projects though; there are a lot of separate things that need to be put in place, each of which depends on something that isn’t quite done yet before it can start doing its thing. You might not be able to see much – the swan’s not moving and the feet are just beginning to twitch – but the foundations are being laid.