How do we remove this label?
Customers are confused if they have downloaded the correct version.
I spent 2 months making the plane detect which game its in and behave correctly between the 2, to avoid having 2 versions of each plane to support.
1 Like
You must make a 2024 native aircraft package (i.e. compile it 2024) and submit it to the marketplace as a 2024 native package.
If the plane was compiled in 2020 then it cannot possibly have all of the features available in 2024, such as support for EFB performance data, integration with the new passenger and cargo load and ground systems, pre-flight walk-around, career mode, and other features. This is what this imagery is intended to convey to customers, is my understanding.
You would need to speak with your Marketplace representative for more information or to ask if there are other ways to remove this imagery, as the developers here do not handle that aspect of things.
Thanks,
Matt
This is from a community build.
We dont have FS24 features yet, but we made the plane compatible + specific optimisations.
Customers are confused by this label. What happens if a plane is made in fs24 without any of the fs24 features?
This would be a topic better to address with your Marketplace team representative. The developers here don’t handle the specifics of that pipeline nor the policies.
Thanks,
Matt
Did you build your package with the MSFS2024 package builder?
No.
Ive had 0 success with it. And if it did work, it would only double our work for 0 improvement.
may be not as per manual or other guidance… but it worked here:
I’ve using a different manifest.json for each fo the two builds
where the 2024 has added lines:
"minimum_game_version": "1.3.23",
"minimum_compatibility_version": "3.20.0.00",
"builder": "Microsoft Flight Simulator 2024",
"package_order_hint": "",
e.g. 2020:
{
"dependencies": [],
"content_type": "MISC",
"title": "MY MODULE",
"manufacturer": "",
"creator": "MY NAME",
"package_version": "MY VERSION",
"minimum_game_version": "1.37.18",
"release_notes": {
"neutral": {
"LastUpdate": "",
"OlderHistory": ""
}
}
}
and 2024:
{
"dependencies": [],
"content_type": "MISC",
"title": "MY MODULE for 2024",
"manufacturer": "",
"creator": "MY NAME",
"package_version": "MY VERSION",
"minimum_game_version": "1.3.23",
"minimum_compatibility_version": "3.20.0.00",
"builder": "Microsoft Flight Simulator 2024",
"package_order_hint": "",
"release_notes": {
"neutral": {
"LastUpdate": "",
"OlderHistory": ""
}
}
}
2 Likes
Beware that adding this line will disable many backwards compatibility options, and so your package will no longer behave like it did in MSFS2020. It’s telling the sim your package was built with the MSFS2024 builder and all the new features, fixes, and optimisations it brings.
Be very careful with that - at a minimum, we’ve discovered it breaks legacy light effects, any gauge display emissive brightness and a myriad of other possibly unseen-at-first issues that will end up biting you in the a$$.
I already have code to adapt the lights to fs24, but its not enabled.
The lighting appears to be different on xbox and customers are also being confused by the different colours
I would add this only for a package built with the 2024 kit - and tested obviously…
If built with 2020 sdk it’s legacy in 2024 from the definition IMHO…
Is this documented in the docs?
I am not sure it really needs much documenting? The 2020 label is laid over to indicate legacy aircraft - if you build with the 2024 SDK, it is not displayed (afaik).
One simple manifest line that can break an entire plane (or mod) is a pretty viable reason to document it.
1 Like
I see your point, however, that line is generated by the SDK engine when the build occurs - I don’t think it’s made to change by hand, to be honest… so if you do change it, you’re assumed to know what you’re doing, at least…
1 Like
It would even better to have some kind of guide (or automated tool) helping us to migrate our MSFS2020 aircrafts to the new sim
I think without that it will be quite impossible for small developers to perform the migration
The manifest.json file is not meant to be hand edited or adjusted by external tools and should only be used as generated by the sim build tools.
If you’re editing it yourself, then you’re definitely proceeding at your own risk.
Thanks,
Matt
I only ever edit it by hand.
1 Like
May I ask why you are doing this?
Best regards,
Eric / Asobo
It might be useful to create a Bug Report about this here if you have a repro or screenshots of the issue. I don’t think this is something we have heard of yet.
This is still on our TODO list - unfortunately other more urgent topics have required our attention up to now. 
Best regards,
Eric / Asobo