Aircraft Configuration: Variant vs Livery

[MSFS 2024] Questions & Community Discussions Aircraft
1

I’m trying to figure out how the aircraft selection screen works to try to sort out a little of the chaos caused by everyone apparently following their own naming conventions rather than sharing the same so the screens would make sense.
I’ve figured out the following… (assuming what I’ve learned is correct).

The entries on the aircraft selection are controlled by icao_model. So two aircraft with icao_model = A1 will appear as a single item on the selection screen. icao_model = A2 will be a second item.

The text shown for the selection screen item = ui_manufacturer ui_type - ui_creator
This is also the text shown as the main aircraft naming text in the configure screen

So the text doesn’t affect how aircraft are grouped… and the grouping doesn’t affect how the aircraft are named. I think… if you have two aircraft grouped, but with different names… the most recently selected one is the name that appears.

The sort order for aircraft is by ui_manufacturer ui_type - ui_creator. icao_model does not affect sort order.

The text shown in the variant and livery selections for each option is ui_variation. Leaving ui_variation blank results in the display showing ‘Default’

The main thing I cannot figure out is… what determines if a specific ui_variation should appear under the variant tab or the livery tab?

And from there… how do you set a specific livery to be tied to a specific variant?
At the moment… all the liveries seem to appear their own variant and not connected to any actual variant (including the default). So my variants are coming up as livery 01, default, floats, skis… etc.
Default, floats and skis have only their 1 default livery. All the liveries actually appear as liveries for the livery 01 variant. Changing the livery selected doesn’t appear to change the name of the variant from livery 01 to, for example, livery 01.

I also have no idea what controls the sort order of liveries.
By setting liveries up as 01, 02, 03, 4, 55, 06, 07, 08
I actually get the order 01, 07, 4, 02, 55, 03, 08, 06. What’s going on there?

My ideal aim is to figure out how to set up a single entry in the aircraft selection… with variants (Standard, Floats, Skis) and then maybe standard liveries (white, blue, red etc… ) but with the ability to have float specific liveries (maybe 1,2,3)

2

good to discuss this issue… 2 additional points, one maybe useful, the other more of a query:

  • having the same aircraft but a different [FLTSIM.N] ui_createdby is enough to have MSFS2024 add another entry to the “selection screen”

  • There’s a related question of which livery/variant is chosen as the one plane to show on the “selection screen”. Even for a plane never selected it’s not necessarily FLTSIM.0

1 Like
3

I’ve noticed both of these points. For the first, I recreated my 2020 aircraft packages to keep the ui_createdby field consistent. I see a potential issue with 3rd party liveries as the creators typically use this field for their name which might cause their livery (of your aircraft) to shoot up to the aircraft selection menu instead of keeping it down at the 3rd level livery selection.

4

Here’s how I sorted out my 2020 aircraft to appear correctly in 2024 in the Aircraft Selection menu, following the Aircraft->Variant->Livery hierarchy. Note that the attributes shown are not all inclusive to what’s needed in the aircraft.cfg, but seem to be the main (key) drivers:

Aircraft
Key Attributes:
icao_model=“Your Aircraft model here” <-Keep this common for all your Variants if you want them all collected under one aircraft listing
ui_createdby='Your Creator name here" <-Keep this common for all your FLTSIM.X entries for all Variants if you want them all collected under one aircraft listing

Variant
Key Attributes:
ui_type=“Your unique Variant name here” <–Keep this common for all your FLTSIM.X entries and unique for each Variant

Livery
Key Attributes:
ui_variation=“Your Livery name here” <–Keep this common for all your FLTSIM.X entries and unique for each Variant

Please feel free to comment if there’s anything I missed.

2 Likes
5

so… does that mean that on a variant definition, we should leave icao_model, ui_createdby blank. And then on a livery icao_model, ui_createdby and ui_type should be blank?

6

Yeah :slight_smile: I didnt follow this either . . .

Perhaps a fuller more detailed description ?

7

No, not blank. As an example, here are my entries for the J2F4 Grumman Duck “Argentina” livery. The J2F4 is one of three Variants (J2F4, J2F5, and J2F6), and there is only one aircraft (Duck) model to choose from in the Aircraft Selection menu.

Aircraft
icao_model=“Duck” <-Keep this common for all your Variants if you want them all collected under one aircraft listing
ui_createdby=“flyndive” <-Keep this common for all your FLTSIM.X entries for all Variants if you want them all collected under one aircraft listing

Variant
ui_type=“J2F4 Duck” <–Keep this common for all your FLTSIM.X entries and unique for each Variant

Livery
ui_variation=“J2F4 Argentina” <-Keep this unique for each livery

1 Like
8

So… in that example, you have ui_type set to a variant name, “J2F4 Duck” “J2F5 Duck” and “J2F6 Duck”… and one of those will appear as the aircraft name on the aircraft selection screen. There’s no way to have the aircraft selection show “J2F Duck” as the collective name for all variants?

What I’m trying to aim for (and maybe it’s not possible… but it should be IMHO), is the aircraft selection to show J2F Duck. Then on the configure screen… the variants to show named J2F4 Duck, J2F5 Duck, J2F6 Duck… with no liveries showing as an option.
Then on the livery screen… the listed options are the various liveries for the selected variant only. So for example, if you had J2F4 Argentina, J2F4 USA, J2F4 Canada, J2F5 UK, J2F5 France, J2F5 Germany… I want the F4 liveries only to appear if the F4 variant is already selected… and the F5 liveries to only appear if the F5 variant is selected.

That’s what I’m hoping for… it’s what I feel is logical. But it’s feeling more and more like that it’s not achievable… even though it appears it should be.

Oh… and no… i’m not making a J2F Duck… just trying to reuse your example.

1 Like
9

That’s how I would like it displayed as well, but alas, it doesn’t seem possible.

1 Like
10

@EPellissier

Eric, do you think a way could be made for us to have a over-ride for our aircraft planes to show in the order we need? Like perhaps a string in the aircraft config that would have the placement of the plane on the list? That would help us out so much.

Bill
LHC

11

I can ask the design team but I am unsure how much they’ll want to change - I guess I could slip in a change for 2020 aircraft but I suspect your query applies to 2024 ones as well?

Best regards,

Eric / Asobo

12

I can ask the design team but I am unsure how much they’ll want to change - I guess I could slip in a change for 2020 aircraft but I suspect your query applies to 2024 ones as well?

Best regards,

Eric / Asobo

13

While they’re at it… maybe worth seeing if improvements can be made to the aircraft selection tiles in general.
It seems under the thumbnail, we get this big blue box… perfect for listing all the relevant information. But we get just two lines of text:
ui_manufacturer ui_type - ui_createdby (which inevitably doesn’t fit and has to scroll)
ui_typerole

followed by a big empty blue space that does nothing apart from take up space that could have been used to add a third row of aircraft to select from.

So why not use that space and have more lines of information:
ui_manufacturer ui_type
ui_variant (I know… it doesn’t exist. Perhaps it should)
ui_variation
ui_typerole
ui_createdby

1 Like
14

Hi Eric,

This thread is exactly what I was talking about in the other thread.

Hopefully you don’t mind me listing all the issues I can see at the moment, and this is only for the default and Marketplace aircraft I’ve purchased. I haven’t integrated other planes I’ve purchased yet, so I don’t know the impact that will have on my library view. I imagine many of the below issues will be fixed? They haven’t been since the planes came out, so, I dunno.

I was able to fix all the issues in 2020 because I could hijack the layout of aircraft by putting the SimObjects\Airplanes\XXX directory of a livery alphabetically before the base model directory, and it would use all of my aircraft.cfg information instead of the base aircraft. Hopefully that hasn’t changed. I haven’t tested it.

Being able to choose the aircraft I want to fly is very important to me. And, essentially, I’m a collector, and if you’ve ever dealt with collectors of anything before, they really like to admire their collection and peruse it. That requires the ability to organize that collection the way they want it organized. I’ll get to that point throughout. I’m going to list the issues I’ve found so far. I imagine many of them have been logged, but, I want to lay them out so we can see the issues we’re dealing with and why I want to be able to fix them. The team is really busy fixing other wayyyy more important bugs, and I don’t want to bother them with stuff I should be able to just fix myself by editing aircraft.cfg files, and removing liveries and variants I don’t want.

With access to the aircraft.cfg’s for all aircraft, I could EASILY fix all these issues. There is NOTHING proprietary or momentous in the aircraft.cfg file.

  1. DHC4 Caribou is listed Aircraft.ui_Manufacturer
  2. I own a bunch of Carenado Marketplace aircraft.
    a. The Mooney, WACO, PA44 Seminole, C337, the White Livery, and the Piper Arrow are all Variants of the C170.
    b. Let’s say I want to Fly the Mooney. If I search for it, since it’s a variant, it tells me it doesn’t exist. I have to somehow know it’s a variant of the Cessna C170. This is a Marketplace plane, so, the Marketplace doesn’t have any way to update the files for the vendor to fix the variant problem.
    c. All the Carenado planes are listed under Carenado. So, If I want to fly a Piper today, I’m not sure which one, and I search for Piper… oops, I don’t own any Piper aircraft. That’s interesting because there’s 2 of them currently in my library.
    d. Why is the White Livery a variant when the C170, when there’s another variant? Oh, I see, the first one at the start of the list is the Tundra wheels (it doesn’t say that in the Gear description), and the White livery, 4th in the list of a bunch of planes, is the regular Wheels variant. So, it makes sense that there’s a Wheels and Tundra variant. The Gear should say Tundra for the description, and obviously it’s a misconfiguration that all those planes are variants of this one (that’s and example of the “explosion” issue I discussed, there’ll be all sorts of misconfigurations as authors set their aircraft up and misunderstand the SDK, which, for 2020 was actually extremely clear, I don’t understand why nobody read it).
    e. Oh, why oh why is the all white livery ever the default livery? sigh. I don’t ever want to see an all white livery in my collection. It’s only there for the painters.
  3. ATR - I fly into Tampa all the time, and I love the Silver Airways livery. I want to use the Silver Airways ATR 42-600 Highline Silver Airways livery today. I search for Silver, no result. I go into the ATR 42-600 Highline and I’m faced with 4 variants. Hmm, I wonder what the difference is for each of the 4 variants? I check out Highline 02, nope, no Silver Airways in there, Next is Air Saint Pierre F-ORLB, that’s a livery with no indication there are any liveries inside it, but, let’s look. Look at that, there’s Silver Airways livery under the Air Saint Pierre Variant. Why is the Air Saint Pierre a variant, and why is a completely different airline a livery in that variant? Then of course, randomly, there’s, in order, variants House Livery F-WWLY, Highline 03, and Highline. None of those Variants have liveries in them (because really, they’re liveries, not variants). The same organizational issues exist for the rest of the ATR ui_models.
  4. This is a me thing, but, I don’t want any Aviator liveries on my system. They show up in parking spots, take valuable space in my library that I have to sort throuch chaff I don’t want to see. I want my library as lean as possible. Hopefully, I’ll be able to remove those when we get the ability to remove things from our library.
  5. Antonov AN-2
    a. I have Bare White, Metal, GNS 430/530 Models. Why are the Bare White and Metal Models, I can’t tell, there’s nothing in their information that says there’s any difference between any of the 3 Models, it seems like they should be Variants, or liveries of the AN-2 model? And I can’t hop in the cockpit and look anymore, maybe they’re analog gauges? Who knows? If they’re both Analog gauges, why are they two Models and not just the both the same Model with two liveries, and maybe there’s two models of the plane GNS and Analog, or a single An-2 model, with GNS and an Analog Gauge variants. I thought maybe one of the Bare metal and white variants was a Tundra, but it looks like it’s the same wheels. So I have no idea why there’s 3 models of the AN-2, all by the same author.
  6. Why is the software running my CPU and GPU at 40% as I search through my library? And I can’t even admire my planes in the hangar anymore :sob:. I can’t even spin them around a bit to see what a livery looks like. If it’s just a static plane, why make it 3D and run my computer so hot. If your’re going to show a 3D model, let us spin it and hop in the cockpit like we could in 2020. I mean, it’s cool and all to see the 3D, but, not much utility in it at the moment. It might as well be a static picture that doesn’t run my computer so hot.
  7. Why are some of the planes so small I can barely see them? Some zoom to the proper size, but, planes like the Pitts, I can barely see them. They come in large, then zoom way back.
  8. Ok, today I want to fly an Amphibious plane. Hmm, I don’t see any in my library as I scroll through… Let’s search… Nope, the search tool says I don’t have any. Hmm, I know there used to be an Amphibious C-172, but all I see is a C-172 Cargo version… Let’s look in there. Oh, ALL my C-172’s are under the Cessna 172 Skyhawk Cargo plane. You mean every time I want to fly my Analog C-172, I have to click into the Cargo plane (which should be a Variant of the C-172, not the main version in my logic of how I sort planes if you know what I mean. I mean, the model should be C-172, that’s it. That’ll make me want to look inside maybe). Actually, this one makes sense, that all the Cessna 172’s are under the Model, but, the variant scroll list area is so short, it’s hard to know what’s in there because I have to scroll a long list of variants. And the variants I’ll never use are first. And, why does it say Cargo if it’s all the variants at the first screen? If you’re going to be consistent and just have the model in the tiles, it shouldn’t list the first variant, unless we are allowed to choose which is the default variant.
  9. Why is DORNIER capatilzed? I realize this is a nothing burger in the grand scheme, but, these are the things I fix in my sim. I’ve been doing this work for every version since there was a list of planes to choose from.
  10. Clearly, there’s some way of making a livery default, because if I go into the list of liveries for the DHC-6-300 Wheels variant, the Borek livery is first in the list, but the Default livery (the white one… why is that default???) is the one I have to choose by default.
  11. Oh… please don’t get me started on the organization of the DC-3 famous flyer… sigh :zipper_mouth_face: :unamused: The organization of how to choose which DC-3 you want to fly is an absolute disaster. From a purists point of view. Sure, in the grand scheme, who cares, there’s more important things to worry about. I get it, my feelings on this are inconsequential to the grand scheme of FS development. But, it makes me sad. Couldn’t it at least have variants?
  12. Just a comment, but, boy, I thought there was more than one livery for the G-21A Goose?
  13. Heart Aerospace ES-30… What’s up with the names of the liveries?? How can I tell the difference by the name?
  14. P-51, why so many ui_models? Shouldn’t they be variants of the P-51? Granted, a P-51A is a different model than a P-51D, but, the rest, better if they are all variants of the P-51 Model. Sure, when I look at the variants of the P-51, I could see choosing from different vendors as being different variants, but, they’re all the same model. As I noted, I want my main tiles to be sorted by model, and then variants inside that with liveries for the variants.
  15. Different subject, but, are all my Reno Texans coming back?

For the most part, yes, the current layout works. As I noted, if it were me, The tiles would be organized by model, like you’re doing, with variants inside that, like you’re doing, and the author of the planes could be sorted by variant in the model, I’d prefer not at the top level tile, in other words, having multiple models of the same model, but, I understand that one.

But there will invariably be issues, as I’ve listed a bunch up above, and, many of us would like to be able to clean out those liveries and variants we don’t want, and order everything the way we use the sim. I’ve been able to do it up to this point. Hopefully that continues. I don’t need any changes today, but, please consider what I have had to say. And this is not a priority issue. It is a passionate one for me and others, though.

Side note: Why, when I want to go back to the previous page from where I was, IOW, back to the Variant page from the Livery page, does hitting ESC Save and Back take me out of Configure (instead of back to the Variant page). I get it, that’s the way an Xbox interface works, but, I’ve got some interface learning to do… sigh.

2 Likes
15

Sorry I can’t stop, but, that previous post is a lot, and most of it not to do with the SDK team per se, as it’s all technically “bugs” and can only be addressed by the developers who inconsistently set up their planes against the spirit of how the models and types are meant to be organized. So it’s mostly bug fixing and managing inconsistent aircraft.cfg writing.

What ideas could help the organization of our planes that could become part of the SDK?

  1. The search field should search ALL the data. Why can’t it find the Amphibious planes? Is it just maybe not finished or not working properly?

  2. More ui_typerole definitions to filter searches with

  3. The ability to assign multiple typeroles to a plane. A plane can be both an amphibian and a single engine prop, and lots more

  4. The ability for users to create their own typeroles and assign them to planes

Rather than ui_manufacturer, ui_type, and ui_variation, you’ve chosen to ignore these values it seems for setup, you said you’re only looking at icao_model and ui_createdby. Is icao_model being used for model matching? Are you expecting them to use values from the official ICAO definition? What about those planes that don’t have an ICAO definition? Please consider the fact that planes often have multiple definitions to choose from (which could be a problem for model matching?). The model matching concept/problem/how to solve it fascinates me, by the way. My issue here is that even though the data is freely available, developers rarely ever fill it in properly.

Back to sorting by ui_model. Sure, its a nice choice to separate aircrafts by model. The problem as I see it is 1. Isn’t it also being used for model matching? (If so, if it’s not correct, it won’t work. If developers change it to game the library, then what?) 2. I assume you want icao_model to be taken from the ICAO definition? 3. the ICAO definitions are really inconsistently named and not useful for naming fields for a UI (that’s what I was afraid might happen), but, then again, if you’re just using it as a key define models but it’s not showing in the UI, that’s fine. But are you sorting on it? If you’re sorting on ui_model, that’s where the mess I was talking about being would be.

If you’re only using it to define top level tiles as a key, but you’re sorting on the ui_manufacturer and ui_type definitions, that works for me. icao_model is kind of nice because it implies the manufacturer and typically separates types, so, notionally, a P-51A and a P-51D would be different models, which I like. On the other hand, some people would expect all P-51’s to be a model, and P-51A and P-51D variants of model. Either is a solution.

  1. Point being… Please don’t sort on icao_model or use it in the UI text, but it’s fine as a key for separating models. And it’s a good search key, too.
  2. Please make sure the induction team enforces consistent writing of the aircraft.cfg aircraft naming fields including making sure all the icao_xxxx fields are properly filled out per the standard. To this point, barely any developers fill in these fields consistently and correctly, and you end up with the mess that I listed in the previous post. Developers should not put their name in ui_manufacturer, that’s what ui_createdby is for. I realize that can cause licensing issues. Which brings me to my next request…
  3. Realizing there are licensing issues for developers, how about allow users to edit ui_manufacturer, ui_type, and ui_variation? I think those are just UI related fields, and only related to sorting in the UI, so hopefully there would be no unintended consequences elsewhere.
  4. We want the ability to hide/delete liveries and variants we don’t want to see either in our library or out on the tarmac as parked planes. There’s a ton of planes I own that I don’t want to see on my airports. I turn them off by assigning them to only appear on MIL_COMBAT parking spots. I’ll want many of them to be available for model matching (let’s say I’m attending an air show in the sim), but I don’t want to see them as planes scattered around.

I realize it’s not your job to fix the bugs that I listed in the previous post, and a lot of what I’m talking about is not in your purview, but, understanding the issues we face can help guide decisions.

Perusing the library is a huge portion of what I love doing in MSFS. I, and many users, can have over a hundred model planes in our library, and that number of course explodes when you include variants and liveries. We’re collectors. We want to organize them. We want to clean out what we don’t want to see. And we want to find them.

With that in mind, ultimately, I want to use the Library to view all my planes, and I want to be able to easily find the planes I want. This is most easily done if they are well organized. Finding the plane I want is really hard today because of the inconsistent implementation of data by developers, and then made especially hard because of the limited seeming function of the search field. As I noted, is it just broken? Shouldn’t it be able to search on all the data in the aircraft.cfg?

Anyway, thanks for listening. I know I wrote a lot about a pretty esoteric concept.

1 Like
16

Dear MSFS DevSupport! After Fenix launched there 2024 version I installed it and also put some Liveries into the community folder as well. Unfortunately they appear quite randomly in the sim. I am only using Liveries from one creator and for some reason some liveries are shown under variant and others are the liveries to the liveries that are shown as variants. I understand that these are 2020 made liveries but why are they in that order when the file structure is identical and the relevant information in the Aircraft.cfg is also identical? Does it have something to do with the new folder structure and the livery.cfg and is that something we can fix with a quick manifest.json and aircraft.cfg fix or does that need further changes in the model and texture folders. I also already tried the UI Edits inside the aircraft.cfg but that did not work unfortunately. I could also provide screenshots from in Game to show what I described in the first part of this post but as this is my first post in that forum I dont know if pictures are allowed in here?

1 Like
17

Yes, I had the same experience, lol.

I imported a few liveries I and a couple of others had created for the Carenado planes to test things out to see if I could get the planes reorganized so they’re all separate models instead of variants of a single plane. It’s actually really funny how messed up the library is now when I added 13 liveries for 7 Carenado planes in a attempt to pull them out of where they’re sitting as variants of the C170. Unfortunately, no, you can no longer “rename” all planes by renaming one of them. All planes are modular now, and not related to their parent model if you change anything about them. Which, technically, is more logical programmatically. But it was a great way I used to use to organize my library.

I spent about an hour reading the SDK on how liveries are created now, and I’m going to need to spend a couple more days or more on the subject, and do lots of testing, figuring out how to do it properly without messing up the organization of the library if I don’t have all the information necessary to do it. With the added twist now that there’s a new file format for 2024 plane textures.

I think an announcement needs to be made not to try to use 2020 liveries in 2024. We’ve got a lot of work to do to convert them for use. They won’t work as is, at least not without making a mess of the aircraft selection menu, as you saw. All files have to be meticulously edited to a level never known before. The consequences of progress.

It’s going to be super important that we get access to the aircraft.cfg and livery.cfg files for any planes people want to create liveries for so we can keep the library organized. And with the new “Dynamic” concept, livery creation seems like it will be a lot harder for people other than the owner of the plane. I’m sure we’ll learn how. I’m just sad it will be a lot harder to fix the “errors” developers make in UI information since the planes are modularly sorted now. Those detail oriented ones of us, lol.

18

I think the easiest ideal solution from the devs would be to introduce new ui_ variables: ui_variant and ui_livery. Then change the Aircraft Selection & Aircraft Configuration screens to use them appropriately.

In cases where aircraft.cfg isn’t updated and hasn’t got either of those (which is initially all of them), then they just need to code the screens to say something like… if ui_variant = blank, then ui_variant = ui_variation and if ui_livery = blank, then ui_livery = ui_variation.

That would be problem solved… with a minimal light touch in dev work.

@EPellissier

19

So all that information you’re suggesting is already there, across icao_model, ui_manufacturer, ui_type, and ui_variation (and ui_createdby).

ui_type is your ui_variant
ui_variation is your ui_livery.

What does adding your two new variables add?

Sorry, you might have missed the fact that tiles are grouped by icao_model and ui_createdby. The list is then sorted by ui_manufacturer, and the default ui_type I think (which seems to be randomly chosen, but, there must be logic in there, I haven’t looked hard enough yet), variants of a given tile (icao_model and ui_createdby combination) are then separated by ui_type, and liveries of each ui_type are named by ui_variation.

Even though the SDK says the introductory fields of an aircraft.cfg are ignored if there is a base_model statement, if the ui_createdby is different in the livery file, it will create a new tile and a icao_model becomes important… I think.

The problem we’re dealing with right now is developers were never consistent in filling out the variables. Just like they had no idea how to fill in the atc_name and atc_model variables. It was actually quite simple, yet, barely any of them understood how to do it properly.

In the meantime, Carenado has to fix all of their aircraft.cfgs, and Aeroplane Heaven has to reorganize the DC-3. Then the SDK team needs to be clear about their expectations for ui_createdby. Do they want to group all the liveries under the respective model tile (ui_createdby, ui_manufacturer, and ui_type must always equal those of the base aircraft), or is it ok that livery creators take credit for their work and extend the number of model tiles in the list, creating a real mish mash of the list.

20

It’s not enough variables to just have manufacturer, type & variation.

For example… let’s take a look at the freeware Hawker Hunter.

Manufacturer = Hawker
Type = Hunter
Variant = F.1, F.3, F.4, F.6, FGA.9, FR.10, GA.11, Mk.58
Livery = (WV266, WV269) for the F.4 Only
(XF506, XF520, XG152, XG274) for the F.6 Only
(XE609 208th Sqdn, XE624 1st Sqdn, XE624 234th Sqdn) FGA.9 Only

And many more…

There’s no way to correctly organise those with just manufacturer, type & variation that I can think of.

I guess we could use Icao_model = Hawker to group them and them put the variants into ui_type. But the issue there is that then the aircraft tile will show a variant name of Hawker Hunter FGA.9 - DG Designs which would imply that the other variants are a subset of the FGA.9. It works… sure… but it’s not right (IMO).

1 Like