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?
-
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?
-
More ui_typerole definitions to filter searches with
-
The ability to assign multiple typeroles to a plane. A plane can be both an amphibian and a single engine prop, and lots more
-
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.
- 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.
- 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…
- 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.
- 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.