Best idea yet is to add another variant called Avionics since many developers use hot swap. This would replace the old hot swap method. And also if the dev does not have multiple avionics then this button will not show. For the structure just like you have the presets folder we would get a new folder called Avionics.
I figured instead of actually adding a 3rd tab called avionics, instead when you are on the variant tab and make your choices this effects what avionics, gauges or even cabins are available for a specific variant. Because not all variants are going to always work for every secondary packages you plan to include. This is like a filter and basically only a single extra step for the user in the existing variant tab.
More detailsā¦
The variant is for the shape of the aircraft and the additional secondary option is for any type of gauges, avionics or even different cabins. These secondary options will display with any title we choose for each one and they will filter (only show up) based on the dev connecting them to the variant they want to or some variants may have none.
This could be extended to cabin variants also. I.e. in the Kodiak we have cargo, mixed, passenger and executive times two (one for each gear type). It may be easier to make avionics options and interior configurations a separate button each.
Interesting idea. How do you envision it would work? Something like a second preset directory where you merge the attached_objects from the avionics preset into the main preset?
It would be the same number of variations but just split into two UI sections. But then you could apply the same thought process to other combinations of variations. Perhaps a better solution to too many variants is a UI redesign with sorting, filtering or other ways to display a large number of variants.
Your missing the point. If I add 4 panel packages to all my existing variants, 6 right now, then 6 X 4 = 24. This would be annoying to the user just like it was with 2020 with too many livery choices based on panel options. This is why hot swapping became a thing. Asobo needed the variant for things like cabin variants or fuel variants so we could have more cfg files.
So adding a third tab just for avionics keeps all three tabs low on choices and less confusing to the user. And if a dev does not have panel options this tab will not exist. Brilliant right?
Yes you would use attachments. I already use attachments now for hot swapping but for hot swapping attachments are not required. But for this option just like presets you would be forced to use attachments. This makes it easier for the dev and the users.
While adding hard-coded UI categories (such as avionics) would help alleviate the overabundance of selections, it only solves the issue for that specific category.
Although thatās still an improvement, I think the possibility would exist for it to be more open ended. If I remember correctly, early alphas had numerous categories - gear, engines, avionics, etc
What could be a possibility is a system where the aircraft developer could define ātagsā that could be used for organization or separation of variants. If the user would be able to selection of filter by more than one tag, the user could then quickly filter down to all results that match the selection of tags.
For example, you might have an aircraft with 4 different cabin variations, 3 different gear variations, and 3 avionics variants. By displaying to the user the available tags for that aircraft, the user could quickly narrow in on all the variants that use cabin variation # 2 and avionics variation # 3, etc.
Of course, the other reason for hot swapping is the presence of addon avionics in the market that require ownership of the avionics unit by the end user. Itās much cleaner to present a hotswap option buried away in a tablet or some such to allow the users that own those avionics to swap to them. If you make those avionics choices a preset, you end up presenting not-fully-functional aircraft choices to users who donāt own the avionicsā¦
I actually also thought of changing my request yesterday. I was thinking of something similar.
I figured instead of actually adding a 3rd tab called avionics, instead when you are on the variant tab and make your choices this effects what avionics are available for this variant. Because not all variant panels are going to always work for every avionics packages you plan to include. This is like a filter and basically only a single extra step for the user in the existing variant tab.
Does not matter if they choose in the tablet or the preset if they do not own the 3rd party avionics they both will not work. But having the avionics hidden is worse as I get too many users asking why they canāt find the correct panel when loading a flight. So the conclusion is the idea I posted is optional to the dev so you can still continue to use hot swapping. And if you like my tweak this makes it even easier for the user with no extra tab.
A matter of perspective. To me, the idea of making presets available in our products that require other third party purchases to be fully functional, and presenting those presets to all users - even those who have no interest - is much worse.
While the hot swap method might generate support requests from customers who might not understand how to access it, a preset method would generate support requests from users who might not even understand what those third party avionics are and might be confused as to why the aircraft in that preset has non-functional avionics panels to begin with.
Perhaps one of the improvements that might be made in the preset selection screen is the ability for us aircraft developers to be given more space to better describe the preset being chosen; then Iād be more comfortable with that idea.
(To be clear, Iām not a fan of hot swapping either. I think itās a less-than-desirable situation that aircraft developer have been placed in, where we need to provide support for other third party products. Iād be a MUCH bigger fan of Working Title eventually replicating the Garmin GTN units to a high degree of accuracy so that this becomes much less of a requirement.)
This idea is for multiple avionic panel options not 3rd party presets. If a developer chooses to add a 3rd party then that is the same as offering it in the preset or the EFB. So keep in mind we are not talking about 3rd party.
That would throw basically throw the expert under the bus that develop the GTNās. And WT is too busy with their current projects and bugs.
This idea is for multiple avionic panel options not 3rd party presets. If a developer chooses to add a 3rd party then that is the same as offering it in the preset or the EFB. So keep in mind we are not talking about 3rd party.
That would basically throw the experts under the bus that develop the GTNās. And WT is too busy with their current projects and bugs. They are good at upgrading and converting not full development. Too many current users already own these GTNās and would not need a lower grade version. You can get a free copy from PMS50.
I am glad to hear this. I am not a fan as well. So hope you can see the light as to what I am trying to get here. Remember that my latest tweak is that there is no extra variant tab. And you just add the info into the current preset folders this way there is not a ton of extra files. By enabling something in that preset you can offer the variant panels. Then when the user chooses say A or B variant one may only offer 2 avionics choices in the same variant tab window and the other may offer 3 avionics choices. Almost like auto filter as you mentioned earlier. And the devs can also not enable this feature if they choose to use hot swap method. Genius right?
I like the idea that you could add tags to each preset and the UI could present those tags as filters. That sounds like it could cover a wide range of possibilities. If it was just avionics as a second dimension, thatās a more narrow use case.
It would be nice for the UI to display a paragraph-sized description of the preset which could allow for the type of notes @JimStewart envisions.
At least thatās how I would look at it from a UX design. It should be backward compatible and doesnāt add extra UI clutter and confusion. If you allow combinations of filters, thatās even better but can result in combinations with no results. It seems like a reasonable request.
So if I understand your saying this is still what I requested. The avionics filter can be anything as we can label it as we please.
The variant is for the shape of the aircraft and the additional secondary option is for any type of gauges, avionics or even different cabins. These secondary options will display with any title we choose for each one and they will filter (only show up) based on the dev connecting them to the variant they want to or some variants may have none.
Any solution seems to still require developers to create all the preset variations but these donāt have to contain very many files so that doesnāt bother me too much. Itās mainly the attached_objects.cfg that would differ although it would be nice to be able to alias thumbnails or panel.xml files to reduce duplication.
As an example, letās use an aircraft with passenger and cargo presets. Then for simplicity, each of those could either have GPS-based avionics or just com/nav avionics. That requires four presets covering all possibilities.
The presets would have the following tags:
tags = Passenger, GPS
tags = Passenger, COM/NAV
tags = Cargo, GPS
tags = Cargo, COM/NAV
In the UI, four filters appear: āPassengerā, āCargoā, GPSā and āCOM/NAVā. With no filters selected all four variants appear. With any single filter selected, two variants would be shown and with two filters selected, you would either see only one variant that matches or none (Passenger + Cargo).
With that system, you could have any type of arbitrary tags/filters that make sense for your project. It would be up to the developer to not go too crazy but otherwise this could support hundreds of combinations and still be reasonably usable.
There would still be reasons to use a hot swap system if you wanted to provide the user with more fine-grained customization but this could support avionics āsetsā quite well.
But of course, avionics is just one possible dimension. You could have different engine types or landing gear configurations or anything else. And developers can offer only certain combinations as it suits them. Players would have a way to navigate all the possible combinations without having to scroll a long list.
Not 4 presets. What I am now asking for will still only have two presets and each preset will have a new method for the attached objects.
So for example anyone that does not need a secondary option will just use a single attached_object.cfg and for those who do want a secondary would have two or three or four attached_object.cfg files that are added to the filter for each preset. Presets never changes. So I have come up with the perfect system that involves hardly any extra work and is still optional as well.
Another issue is the G3X you canāt use hotswap with PMS50 and TDS or even the WT gns530. So this is key to have or we end up with 20 variations for 4 actual variations. Customers will not want this.
This is actually the same issue I am facing but with the WT GNS in 2024 as a SimAttachment. It is nice to have a native, built-in GNS instrument that we 3rd-party developers can use, hence saving time with modeling, texturing and coding, but not having the hot-swapping capabilities is a blocking issue to me as well. In the meantime, I have to rely on the GNS instrument that I made before for 2020 and re-use the old code too until the hot-swapping capabilities get eventually implemented in the 2024-native instruments, not just the GNS but the G3X too. Hoping Asobo can sort this out
Regards, Carlos Daniel GonzĆ”lez GĆ³mez CEO & Lead Developer - NextGen Simulations
