I know Asobo is working on a full-fledged AI live traffic solution with bespoke models and liveries, and that other third-parties are working on their packages as well, but the wait is understandably long and I feel something is needed in the interim (and it’s something that IMHO would make Asobo’s full solution better and third-parties’ work easier when those come).
We need a simple do-it-yourself solution that lets us set models and liveries on our own. I know there are already ways, but they’re very cumbersome and buggy and require editing a lot of different files.
What I propose is having a master configuration file (of course, this isn’t the only possible solution, there could be more, but gives the idea of what could be done) that lists airline and aircraft ICAO codes and possibly an override for optional individual registrations, which the simulator would parse in order to spawn the right model and livery for each aircraft.
Here’s an example structure (it’s just an example to showcase how it could work, not actual code haha).
[Registration]
JA37AB: AI738_Skymark_Pikachu ← registration points the sim directly to the livery’s “Sim” value.
LX-YCF: AI748_Cargolux_Mask
[Aircraft]
B738:SKY:AI738_Skymark ← Aircraft and airline point to the livery’s sim value.
B738:ANA:AI738_ANA
…
The optional registration section is to enable special liveries. If the sim parses that and doesn’t find the registration, it moves on to the aircraft section, looks for a match of aircraft model and airline, and spawns the appropriate model and livery. If no match is found, a generic is spawned instead.
Of course, for this to work, the bug that spawns erroneous liveries needs to be solved.
There are several advantages to a simple method like this.
1: it can be published as soon as ready without needing for Asobo to have all the models and liveries for the full-fledged solution.
2: it can be edited directly by users quite easily and quickly, adding whatever models and liveries they want. They can do as little as they want or as much as they want.
3: third parties have a much easier job in implementing their models and liveries packages.
4: even when Asobo finally implements its bespoke AI solution, they already said that they need an official license to include any model and livery in the simulation. This means that their solution will inevitably be partial. With this solution at the base, users can simply integrate Asobo’s solution easily and quickly by adding their own models and liveries even if Asobo can’t license them. They can also keep it updated in case changes happen in the real world and Asobo can’t keep up.
5: it’s very easily scalable depending on whatever hardware a user has available.
6: It creates a healthy market both payware and freeware for people who want to create & or sell simpler low-poly models of certain aircraft made especially for AI, or AI livery packages (or combinations of both). This market already exists for other sims, but it doesn’t in MSFS.
7: It encourages payware aircraft developers to include a lower-poly model of their aircraft in the package specifically for AI. The user can then easily add it to their configuration file so that it’s used.
Of course, this would solve only half of the AI problem, The other half is the inactive aircraft parked at the gates of airports (which at the moment are random, which is really inadequate as soon as you start having real models and liveries), and for that, an additional feature could be added (at the same time or later, nothing says this all needs to be implemented in one go).
Whenever an airport is loaded into memory, the simulator should poll Flightaware’s history for aircraft (specific registrations) that have landed in the past X hours, then compare it with those that have taken off in the same period and subtract those from the “landed” list.
Then, spawn all the aircraft that remain in the list at the airport (from the configuration file above). You could spawn a number (starting from the latest landed that have not taken off yet, I guess) depending on where the user has set the ground aircraft density slider, so not ALL need to be spawned if the user doesn’t have the rig required to handle it.
Whenever flightaware sends the sim a notice of a departure (this is already partly implemented), the sim should check the list of the inactive aircraft that are already spawned. If a match is found, that aircraft should be “activated” and depart. If no match is found, a new aircraft with the matching model and livery should be spawned.
IMHO, the foundational problem of the current AI solution isn’t the generics. Those can be replaced. but the fact that the implementation is unnecessarily cumbersome, buggy, and difficult to edit. A simpler approach to model & livery matching like the one described here would help everyone, Asobo, users, and third-party devs.
