MSFS 2020 airplanes variants grouping errors

Version: 1.0.72.0

Frequency: Consistently

Severity: Low

Context:

probably the same bug for my different mods :

  • Reims Rocket 2020 build in community dir
  • C172 taildragger 2020 build in community dir
  • C172 bushkit 2020 build in community dir

Bug description:

1st bug
Reims Rocket pkg contains 3 simobjects : 2 planes & 1 amphibian

  • In airplane selection : Plane selection show 1 plane (1st simobject) and twice the amphibian (not the 2nd simobject variant)
  • In airplane config : the 3 variants are displayed correctly (without pictures : separate reported bug)


2nd bug
Both C172 taildragger and C172 bushkit contains 1 single simobject.

  • In airplane selection : Plane selection show 1 plane (bushkit)
  • in airplane configuration : Plane selection show both planes

They are different planes but grouped as one : that’s confusing

image


Repro steps:
Drop mods in community, select planes & configuration

Attachments:
https://www.bagolu.com/dl/bagolu-c172-reimsrocket-hawkxpii.zip
https://www.bagolu.com/dl/bagolu-c172-taildragger.zip
https://www.bagolu.com/dl/bagolu-c172-bush.zip

The problem is not fixed with 1.0.87.0 but is different :

With my plane “Reims Rocket” containing 3 variants, 3 different planes are now presented in main screen :
Instead of the 3 variants, I have 3 liveries of the amphibian variant :


And when selecting one of them I only have some of the connected liveries and sometimes the livery of another variant.

My two mods C172 Bush & C172 Taildragger are still grouped as a single plane with 2 variants :

I have access to all the liveries for the correct variants.

The only “problem” is that the 2 planes are considered as one

This could well be something wrong in my aircraft.cfg files causing this different behavior in 2024 and not in 2020.

What are the criterias in aircraft.cfg to determine :

  • How are the planes grouped in main selection ?
  • How are the liveries groupes in variant display ?

Thanks !
Bagolu

Raul pointed me to :

It looks like the same thing.
I’ll try the suggested changes as soon as I can

I managed to sort out the variant selections for the Reims Rocket (and its 3 variants)

For an unknown reason, my two other planes are grouped

=> not a big deal as long as there’s not more strange grouping between different planes (possibly from different editors)

Bon courage avant la sortie :wink:
Bagolu

@bagolu,

Aircraft are grouped by (icao_model + ui_createdby). What are the two planes you are mentioning that are wrongly grouped according to you?

Best regards,

Eric / Asobo

That’s two different mods of the 172, I’ll separate them with the ICAO value as I prefer to have them separated in the aircrafts list.

Thanks a lot for the reply
I think this ticket can be closed

So… in terms of whether or not a particular plane/livery appears under the variant or livery tabs of MS24…

icao_model = variant
ui_variation = livery ?

1 Like

This is bad because depending on the amount of products a developer has he will need to update each of his aircraft.cfg files to be updated in MSFS 2020 so that it works correctly in MSFS 2024 without errors.

1 Like

I’m not sure how the liveries will get in the way of that, as they often come with overriden variables.

I can’t disagree with this. I’ve had to update my 2020 craft to appear properly in the aircraft selection menu within 2024 per the following:

Besides having to redo my aircraft.cfg files to cooperate as expected, an issue may arise where 3rd party livery creations will likely appear in the aircraft menu as individual aircraft rather than within the respective aircraft hierarchy. This is because the field “ui_createdby” is quite often used by the livery creator for their own name and not the aircraft developer.

2 Likes

Exactly @flyndive
I experienced this error when a livery creator made new liveries for some of my products and the product showed up as “new” under the livery creator definition instead of the product creator.

I am redoing the aircraft.cfg files as well for full compatibility, but it is a time consuming process unfortunately

1 Like

Is that it, the only criteria?

I group my aircraft by manufacturer and type, would love to be able to search by typerole, and assign multiple typeroles to aircraft. Is this capability gone?

I’ve asked repeatedly, along with many other people, to have multiple criteria to sort aircraft by. And to be able to add multiple typeroles, just like an aircraft can be assigned to multiple types of parking spots. Including by favorite. Will Asobo EVER consider this?

An aircraft can be a single engine prop AND amphibious, yet, currently, I can only assign one. What if I want to look at my “vintage” aircraft, and choose something from that list?

A very typical user has over 100 aircraft to choose from; this is a horrible choice of sorting. I don’t really care who the author is, why would I want to sort my aircraft by author? Sure, sometimes I’d like to show aircraft created by a certain author, but I don’t want my library sorted that way. I rarely care who the author is except when understanding what the quality of the plane I’m about to purchase is going to be like, it plays a role there. But, after I’ve purchased it, I don’t really care who the author is (no offense). Why would anyone want to sort their library by author? How will I possibly find the aircraft I want to fly? By memorizing who created it?

What happened to sorting the library by ui_manufacturer, ui_type, ui_variation, and ui_typerole?

And while we’re at it… Why is ui_typerole restricted to so few choices? In FSX, I could assign any ui_typerole I wanted. Granted, I was still stuck with one choice back then, but, at least I could create them. In combination with ui_manufacturer, ui_type, ui_typrole added a very powerful method of sorting my library since by having the same ui_manufacturer and ui_type, since having a different ui_typerole created a new slot for variations, it was very powerful way of setting up my library view like I liked. And, yes, I liked the way the FS2020 and FSX library view showed a page of aircraft at a time.

I’m sorry, but, choosing ui_createdby was an absolutely ridiculous UI choice. WOW. I usually accept design choices, unwillingly sometimes, but, life is what it is sometimes, but this one literally makes me angry.

BTW, one of the major reasons I’ve chosen not to purchase from the Marketplace in the past was because Aircraft.cfg files are typically created willy-nilly with all sorts of incorrect values, and I go through and edit nearly every single one to keep my library organized and consistent. That way I can make sure manufacturer and type names are consistent, icao_model is correct and consistent, etc… It’s been one of my pet peeves for decades. Now my ability to manage my library has literally been blown out of the water by this UI design choice.

While I totally agree that ui_createdby is an important field to give credit where credit is due, it is not in ANY WAY a field I would ever consider using for sorting my library.

And, no, this ticket cannot be closed. Or maybe a new one needs to be created. If authors willy-nilly start changing the icao_model so they can control where their plane shows up, how is model matching going to work? icao_model should ABSOLUTELY NOT be used for laying out where a plane shows up in the list. It should be correct for every single aircraft so it can be properly model matched. This choice leaves it open for authors, again, just choosing whatever they want. It should be chosen from the icao list (which is already confusing anyway, since the same plane and model can have multiple icao_model names). It’s like when the ui_manufacturer is used by authors with their own names instead of the actual manufacturer. I realize this might cause licensing issues, however.

There are so many issues with this UI Design choice I just can’t believe it. SMH.

1 Like

Sometimes it’s a trademark workaround. Not every company allows use of their name here.

Yes, I know. But, as a user, I’d like the ability to change it to what it should be. And the result of that is all Carenado aircraft are made by… Carenado. I should delete that post, though, it’s ranty and uninformed. I understand how it works better now, it’s not the only determinant in grouping or organization, so, that’s better.

The old method of how it worked was, yes, flawed programmatically kind of, but, it allowed me to reorganize the library without needing access to encrypted files. Now that it’s more modular, that’s not possible anymore (I tested it). Also, ui_createdby used to only be informational. Now that it’s used for grouping, along with, as you noted, a flawed ui_Manufacturer field, it’s going to matter how ui_createdby is filled in, and the choice by authors is going to affect how the Library is going to work/be organized. Fortunately there’s a field in the Manifest.json to allow authors to get credit for their work. But, it’s kind of not fair, and I’m pretty sure some livery authors will put their name in the field rather than the author of the plane. Which is “working as designed”, but, not ideal.

The search problem the manufacturer trademark workaround creates could be solved if the Marketplace team made sure all authors properly filled icao_manufacturer in with the official manufacturer names, and made the all the icao fields searchable. Or, Asobo could create yet another database of manufacturer and type fields, or use the atc_name and atc_model fields for searching, too, and add even more manufacturers and models ot the list, and make sure authors search that list to fill in these values instead of being all lazy about it.