Aircraft Configuration: Variant vs Livery

[MSFS 2024] Questions & Community Discussions Aircraft
21

Yes, that was always a conundrum for me.

Do I put all my North American Aviation P-51’s under that, or do I have North American Aviation P-51A, North American Aviation P-51D, etc… I always chose the latter, which could be done with the Hawker Hunter.

But, yes, your organization is just as valid.

(and then you also run into the problem with, some people call it North American Aviation, some people call it North American, etc. etc. so the same plane ends up being a different plane, and I throw up my hands, lol)

To me, putting all the Hawker Hunters under Hawker Hunter means I need to make more clicks to get to the plane I want. Take the de Havilland Beaver for example. All the Beavers are under a single model tile. I liked having the wheeled beavers as a model tile, and the float beavers as a model tile. Because I tend to fly the amphibious Beavers more than the wheeled Beavers, I liked having them readily available.

22

Yes, that was exactly the intention. Each of your variants in your list actually has a different icao_model designation. Edit: Oops, nope, they don’t. But they should! lol

It’s the same thing with 737-300, 737-400, 737-800; each would get it’s own model tile.

The nice thing about grouping by icao_model is that it avoids the Manufacturer name conunmdrum, kind of, if developers don’t make up their own icao_model names, which they kind of have to do, and there’s even multiple icao_model names for the “same” model of plane (sigh), and they get grouped together, kind of, if the library is sorted by icao_model under the covers.

This is exactly why I got so upset about the change, lol. Programmatically the change makes sense, especially when you consider they’ve integrated the Marketplace into the library. But, the screwy way it used to work allowed me to organize the library the way I wanted even when the aircraft.cfg files were encrypted… sigh.

Edit: I just checked… ICAO decided the only Hawker Hunter model we need is Hunter, lol… sigh
Even the P-51 isn’t separated by A, B, C, D, etc… 737 has a ton, though. And, of course, Developers can make up their own… :flushed:

I am coming around to understanding the logic, though I, as you, see holes in it. I just hope someday I get to name planes the way I want and organize my library the way I want like I used to be able too.

23

BTW, the bigger problem, which is what you found, is that the tiles are separated by ui_createdby. So liveries where the author puts their own name in the ui_createdby will end up creating a new tile. Then, if no icao_model exists in the aircraft.cfg, all those ui_createdby’s will be grouped under a single tile with all sorts of different plane as variants.

So the Marketplace team needs to go back to the developers and have them rewrite their 2020 livery aircraft.cfg’s. And somebody has to come up with a consistent format for how it should be done. Or not. :man_shrugging:

24

Microsoft/Asobo has a simple solution: simply and explicitly describe in the SDK how developers should fill out the aicraft.cfg file

If done correctly and unambiguously, the problem would be solved.

1 Like
25

Im sorry but the words “unambiguously” and “SDK”
Don’t really belong in the same post :wink:

1 Like
26

Yes, it took them a long time to document it fully, and, it could get more detail, but I thought they did a pretty good job of describing the fields.

They did a very good job of describing the rules for the use of models in AI traffic and how to set up those fields. Though, it seems most developers don’t bother to read about it.

The issue now is they’re using fields they never used before as far as we know. All they said was “these are the icao codes you can put in the model” but were silent before on how that data was used. So many planes don’t have the data (e.g. Carenado as far as we can tell, given their aircraft.cfg’s have always been encrypted), and you had to come here to ask about, for instance, what to do when the atc_name and atc_model information wasn’t in Asobo’s database in the locPak files. When they explained it, I never could understand how to make it work, and it seemed like it depended on a hardcoded path from what I could make out of the explanation of how to deal with it.

It would have been way easier if you could have just added the appropriate line to the local locPak file like you can do with so many other fields.

But, yes, I agree. Especially this change. It’s a pretty big change, and I only learned about it in a passing comment here at DevSupport.

Another one that irks me is the atc_parking field. So many developers just punt and put “ANY”, and then I end up with Piper Cubs parking at Airline Jetways, smh. Hence, why I want to edit every aircraft.cfg.

1 Like
28

Can someone please explain to me what is wrong with

icao_model - Sets Main “header” for hangar selection list
ui_type - Sets VARIANT as a sub model of Icao_Model above
ui_variation - Sets LIVERY as a sub model of UI_TYPE/Variant above

for example …
BN2T ISLANDER / MARITIME / MALTESE
or
BN2T ISLANDER / CIVILIAN / RED AND WHITE

This makes a lot more sense than the existing confused and convoluted system ( and I use the word System for indication only ) :slight_smile:

29

Nothing - other than that icao_model never appears on screen at present. It’s used for sorting, but never displayed… which is odd in itself.

So at the moment, you’d get an aircraft tile titled:
Britten-Norman Maritime
or
Britten-Norman Civilian

depending I think on which ever you’ve most recently selected.

30

Okay, I’m at my wits ends right now. I’ll bring specific 2020 airplane to this now, the FBW A320.
Can someone please tell me how to group the liveries properly as Liveries and not Variants?
I managed to group all 3rd party liveries under one plane in the selection screen by basically deleting everything from the livery aircraft.cfg, leaving only this

[VERSION]
major = 1
minor = 0

[VARIATION]
base_container =  "..\FlyByWire_A320_NEO" 


[FLTSIM.0]
title = "Airbus A320neo FlyByWire CSA Modern" ; Variation name
model = "MAIN" ; model folder
texture = "CZECHAIRLINES" ; texture folder
ui_variation = "CSA Modern" ; e.g. World Air, IFR Panel
icao_airline = "CSA"

It shows as it’s own variant. What shall be added to the livery aircraft.cfg to “hide” it under the FBW base variant as a livery? I tried adding the ui_type = “A320neo (LEAP)” from the base model without success

31

The way so far I’ve been able to manage to get the liveries to appear under a correct/specific variant is to set every ui_variation field to the variant name.

It works… sort of. This way you get a single entry on the variant tab. Then when you have selected the variant and move to the livery tab, all the liveries for that variant (and only the liveries for that varant) are available to select.

The downside… you lose the variant names. So your selection is entirely by the thumbnail.

32

That’s very interesting. It could work. You just need to create your thumbnail using the front right view. This gives a better view of the livery than the default thumbnail view. This would generally be enough to allow someone to be able to select the livery by thumbnail only.

I gave it a go with the JustFlight RJ100, and this didn’t work. The RJ100 has the Cobham livery appearing as the variant name. Setting any of my RJ100 liveries with the ui_variation as Cobham didn’t result in them appearing with all the default liveries under that variant. My livery still appeared as its own variant. So I guess there is something else at play here.

Interestingly the livery in the [FLTSIM.0] position of the RJ100 was actually Aegean, and Cobham was number 7 in the list of 13 default liveries. So not sure why MSFS even decided to use the Cobham livery as the variant.

33

try:
ui_manufacturer = Avro ;
ui_type = RJ ;
icao_model = RJ ;
ui_variation = RJ-100 ; Cobham

Put this for all liveries. You’ll lose the livery name on screen, but they’ll all appear under the correct variant. (I leave the livery name as a comment so I can recover the name in future if we ever get a new variable to put it in)

Then for the other variants, set all the liveries as appropriate:
ui_variation = RJ-85 ;
ui_variation = RJ-70 ;

So you’ll get a aircraft select tile titled ‘Avro RJ’ with the selected variant name on the second line (RJ-70, RJ-85 or RJ-100).

You should have only 3 variants on the variants tab
Then the livery tab should show all the liveries for the selected variant… the downside is they’ll all be titled with the variant name instead of a livery name.

As long as all the liveries share the variant name… they’ll appear on the livery tab only for the selected variant and only the variants will appear on the variant tab.
At least that’s what I’ve found for the majority of aircraft.

The alternative is to treat them all as separate aircraft.
ui_manufacturer = Avro
ui_type = RJ-100, RJ-85 or RJ-70
icao_model = RJ-100, RJ-085 or RJ-070
ui_variation = livery name

That’ll give you three separate aircraft appearing together in the correct order on the aircraft selection screen. None will have variants, but each will have all the liveries with the appropriate livery names.

34

icao_model controls the model tile in combination with ui_createdby. If either is different you get a different model tile.

Variant should be controlled by ui_type. The name of model tiles will be sorted alphabetically by ui_manufacturer and the ui_type, then ui_createdby it seems, I don’t think they use icao_model in the name, but, I haven’t tested it. Then ui_variation will be the liveries. I’m not sure how it chooses the default variant. It seems like it’s not always the first alphabetically.

So this should work, if you want all the RJ’s under a single tile…

icao_model = RJ
ui_createdby = JustFlight
ui_manufacturer = Avro
ui_type = RJ-100, RJ-85 or RJ-70
ui_variation = livery name

Then, make sure all the liveries have ui_createdby = JustFlight. They don’t need the icao_model as [variation]
base_model= should attach it to the correct model tile, as long as ui_createdby is the same as the base model. Personally, I’d make ui_manufacturer and ui_type the same as required for each livery, too, but I don’t think they matter as far as creating new model tiles.
This should give you 3 variants under “Avro RJ-100 JustFlight”, or whichever is the default variant for the tile, and of course the liveries would be associated with their ui_type field (variant).

35

Thanks for both of your for your suggestions, but neither resulted in my liveries being grouped with the source aircraft’s liveries, or being grouped together under a single variant tile.

I also found that no matter what I did with icao_model value, there was no change on either the variant or livery tabs. Having this value the same or different for all liveries (or the source aircraft) made no difference. So I can’t see that this is even used by 2024.

I think it currently works that all downloaded liveries appear as a separate variant for each livery. I personally never use default liveries, so there is no advantage in having 3rd party liveries grouped with the default liveries anyway. All people need do scroll across on the Variant tab until they find the livery the want, select it, and they are ready to fly. On those liveries with multiple options that require the use of Livery tab, then the thumbnail_variant.png can be used by livery creators to indicate that there are more choices on the Livery tab for this livery.

My interest in this process is not to control my personal livery collection, but purely as a livery creator wanting to come up with the best solution for the majority of people who download my liveries. Bearing in mind that not all livery creators are going to embrace any solution, so my solution will at least fit in with livery creators who do nothing extra. Users will quickly get used to only looking on the Livery tab where they don’t see all the options they expect on the Variant tab. My solution just makes it more obvious.

On this variant tab you can see that the Braathens livery has more options, while the Orionair livery does not. And also that just selecting the variant, without looking at the Livery tab, will give you the livery for M-ABNF. Why make people look at the Livery tab if the livery they want is already displayed on the variant tab.

image
image1920×1228 131 KB

The livery tab then displays the 4 different livery options all with the correct identifiers, so people will know what they are selecting. This is important as the information that makes these liveries different is either not visible, or hard to see, in either the thumbnail or the 3d model.

image
image1920×1216 118 KB

I did notice that MSFS will occasionally not redraw the livery appearing on the 3d model after you select the livery’s variant or livery. When this happens just clicking on any other Variant and then back on the livery’s variant/livery sees it redraw correctly. It seems to only do this if you had used a 3rd party livery, before you shut down MSFS. And then you immediately went into the variant screen for the same aircraft after restarting MSFS. Very odd.

36

Unfortunately no solution posted so far has worked. Looks like there is no way to easily convert 2020 liveries into the 2024 system unless you change everything to use the new livery.cfg file system

37

Hmm, it worked for me for the Carenado liveries I tested. I’ll look at it again tomorrow and share my results.

It’s true, it’s not supposed to use the icao_model as the SDK says it ignores everything but the Flightsim.xxx section if you use a [variation] basemodel= section, but if you change the ui_createdby from that of the aircraft, it seems to use the header data.

It should be using the combination of basemodel and ui_createdby to put it in the same model tile, assuming all the other parameters match so it puts it in the right variant.

But I’ll test some more tomorrow.

In any event, I have successfully created 2020 liveries and had them organize either in the model tile of the plane, or its own model tile using the combinations of data I described above for the Carenado aircraft (which was my test subject).

38

Don’t get liveries for 2020 legacy aircraft that are in 2024 confused with liveries for 2024 native aircraft. Liveries for 2020 legacy aircraft use the same file structure that they did in 2020. The comments above around what goes in the aircraft.cfg to get it to work in 2024, are only for liveries for 2020 legacy aircraft. A 2020 legacy aircraft being one that basically hasn’t changed its structure or files for 2024.

Liveries for 2024 native aircraft use a different folder structure, and don’t use an aircraft.cfg. Instead, they use a combination of folders that match the source aircraft, and a livery.cfg, to link the livery to the source aircraft.

It also appears that Asobo has changed the UV maps for most 2024 base aircraft, so that even if you get the structure right, and convert your textures to the new KTX2 format, your 2020 textures will never work. I am referring the likes of the 152, 172, DA40, 787, Longitude, DR400, TBM930 etc. The only way round this is to create new textures from the start, once we get access to the encrypted files. The only 2024 native aircraft that I have successfully got 2020 liveries converted and working, are for those default aircraft not developed by Asobo. The default Beaver by Blackbird is one example of such an aircraft. It appears that Blackbird understand their user base, while Asobo do not.

1 Like
39

Yes, I know, and that’s what I’m referencing to. HOW TO “easily” convert 2020 liveries for the 2020 aircraft to use the 2024 livery system. And how the heck does it work, because FBW ships with 2 liveries using the 2020 system and yet their liveries are correctly in the Livery menu. I even tried to edit the additional livery aircraft.cfg to add another [FLTSIM.#] with no success.

40

We’re all very confused. You don’t. 2020 liveries for 2020 aircraft in 2024 use the 2020 livery packages. The only “conversion” you need to do is to fix the aircraft.cfg to include all the necessary information.

That, and many 2020 liveries were very poorly packaged, so they need to be cleaned up. For instance, in most situations, you don’t need the model directories, and if there’s a panel directory, it’ll likely need cleanup or deletion.

But, otherwise, 2020 livery packages DO NOT need to be converted to the 2024 livery system.

Unless what you’re really saying is you want to convert your 2020 liveries for aircraft that used to be 2020 aircraft, and have now been converted to 2024 aircraft. In that case (e.g. C172). You essentially can’t. At least not yet. We don’t have all the information on the formats yet, or the tools to easily do it. For instance, there are tools to create the KTX2 files in the SDK, but, we’re likely going to need some more information to really understand how to do it right. And I’m going to be there’s other stuff we need to know that’s not obvious to us yet. Not to mention, the UV maps are all changed, so, you’ll have to move stuff all around, if you can do that at all.

For instance, this here

I’m pretty sure this will screw up a ton of liveries? Though, not many people update the AO/Roughness/Metal files, so in most situations, it will be up to the developer to fix these files. I don’t quite understand the implications yet.

41

Please read again what I wrote and my previous posts, I think it’s pretty clear: 2020 aircraft with 2020 liveries

Aircraft.cfg already cleaned, and as I said and I’ll repeat: the plane itself ships with two liveries and they DO APPEAR TO USE 2024 livery system, even though they are in 2020 file system

And YES, the packages DO NEED to be converted to the 2024 livery system, otherwise ALL the liveries are shown as VARIANT, not LIVERY

For the less perceptive - this is how the 2020 Airplane installs in the sim, correctly placing the liveries in the LIVERY tab

Screenshot 2024-12-10 212528
Screenshot 2024-12-10 2125281920×1080 91.6 KB

Screenshot 2024-12-10 212741
Screenshot 2024-12-10 2127411072×477 43.1 KB

This is how any additional livery shows up, WRONG under the VARIANT tab.

Screenshot 2024-12-10 212550
Screenshot 2024-12-10 2125501920×1080 89.7 KB

As I said, I even tried editing the base aircraft.cfg to add additional [FLTSIM]