Common buttons section for all aircraft

[sikorsky77]

Hi all

is it possible to have 2 buttons settings for a single Profile aircraft, a common one as G1000 and a specific one related to the aircraft

exemple :

Cessna SkyHawk 172 G1000 with a

[Buttons.Common G1000] (a common G1000 avionic buttons section for all aircraft using a G1000 avionic)

and

[Buttons.Cessna 172 Skyhawk G1000] which is used for all another's cockpit buttons not used in G1000 avionic

------------------------------------------------------------------------------------------------------------------

DA62 with a

[Buttons.Common G1000] (a common G1000 avionic buttons section for all aircraft using a G1000 avionic)

and

[Buttons.DA62] which is used for all another's cockpit buttons not used in G1000 avionic

-----------------

etc...

--------------------------------------------------------

this to set a single time all G1000 avionic functions in a common buttons section i can reuse for all aircraft using G1000 avionic

Thanks all 

[John Dowson]

No sorry, that is not possible. The only thing you can do at the moment is to use different profiles for the C172 based upon the name, using one with the G1000 assignments and the other without.
If you want to use the G100 assignments in another aircraft, you can manually copy the assignments in your FSUIPC7.ini to another profile, remembering to change the index numbers if needed.

I have thought about this issue, i.e. to have common assignment blocks for AP systems that can be used in different profiles, but there are two many issues to handle. For example, on some aircraft you can change the AP systems on-the-fly (via a flypad or EFB). This means I would have to look into how to determine when the AP systems have changed and update the assignments dynamically, which would be very difficult if not impossible at the moment. Its also difficult to manage such assignments via the assignments dialog (e.g. where to save assignments to - general, profile or common block, when/how to trigger a common block load, etc)

You could also use multiple FSUIPC7.ini files(e.g. FSUIPC7-G1000.ini, FSUIPC7-G540.ini, etc) for different AP sub-systems, and rename them to FSUIPC7.ini before starting (or before reloading assignments if already started) to use them.

John

[sikorsky77]

Thanks John

i suspected that it is not possible like i want to do , but the copy of G1000 assignement from an base aircraft can be a solution

a question about index for copy

to avoid index conflict with the rest of button assignment when i copy the base Button.G1000, can i create a new Button.G1000 section then when it is finished , renumber index function with 1 by 1001, 2 by 1002, 3 by 1003, etc... , so when i copy the buton.g1000 section into another aircraft profile, i couldn't have conflict with the other functions starting with 1 to 999 ?

What do you think about this idea

Thierry

[John Dowson]

4 minutes ago, sikorsky77 said:

to avoid index conflict with the rest of button assignment when i copy the base Button.G1000, can i create a new Button.G1000 section then when it is finished , renumber index function with 1 by 1001, 2 by 1002, 3 by 1003, etc... , so when i copy the buton.g1000 section into another aircraft profile, i couldn't have conflict with the other functions starting with 1 to 999 ?

Yes, you can do that. However, there is a limit on the index number, so be aware of that. I think it should be ok up to 2099...

As a side note, I have been thinking about this issue for a while now. I am thinking of implementing an 'include' directive. So, you could do something like:
   [Buttons]  (or [Buttons.<profile name>]
   Include=G1000
   1=///
   ...
  [Include.G1000]
  1=...
 

However, if/when I implement this, it will still be a manual process to:
  - create the include section. Basically, once you have assigned all functions to a specific item, you would need to manually remove these and create the include section yourself
  - You would then need to manually edit your profile section to add the include directive

And I need to consider how to handle conflicts - should they augment or replace? And more complicated when you consider the general sections + profile sections (currently axes assignments replace, button + key assignments augment).

There is also an issue with lvars - they really should be a/c specific, not profile specific. I will also add a mechanism so that lvars can be a/c specific, so that different LvarOffsets sections can be used for different a/c within the same profile.

However, please note,  I am not doing any development at the moment. I am on a holiday at the moment (or sort of...). I am only covering support and implementing bug-fixes. I am leaving any new development until mid-September . I will advise if/when I get around to looking at this in detail.

Cheers,

John

 

[sikorsky77]

Thanks John

for the moment , i can use the solution you validate (a renumbering to 1001, 1002, 1003) for G1000 bloc Functions and add this to the other function set below 1000

for the limit , in a 2 x G1000 screen + audio-com module , we have 73 buttons/rotators function in PFD, 73 in MFD and 27 in audio-com module, so a sum of 173 offset functions, if you add a second FO PFD , 246 buttons settings, and if you you want to have a rich glass-cockpit with 4 screens, you can add a second FO MFD pushing the sum of settings to 319 buttons settings, so 2099 functions limit is largely enough for G1000 and specific buttons/rotators for an aircraft profile 

The potential [include] functionality is very interesting, we can add another function interrogation point ,

you select a button or rotator in the G1000 module in an aircraft profile using the [Include] G1000, you attribute a different function versus the same button of [Include] , do we change the [Include] section that will impact all aircraft using it or does this specific setting of G1000 must exclude the same G1000 "include" function  

a lot of development analysis question in perspective

I am too in Holidays this morning , so i stop to disturb you with my questions

good holidays John and thanks for your support

Thierry