Feature request: Support for SimConnect custom variables

[Simon853]

I've an idea for a useful feature:

Say I create a wholly new system for an aircraft in a C gauge file, let's call it "WhizzBox", that has a power switch on it. In order for the user to map a key or button to operate the switch (if they don't want to use the mouse) I have to identify an existing aircraft system event that isn't in use in that aircraft, (like a arrestor hook on a helicopter for example), and trap those key events to operate the switch. Explaining this to new users especially can be confusing for them and I quickly run out of unused standard events implementing complex systems.

As my gauge files often include a SimConnect client, I can map custom events to be trapped and operated on by the embedded client, for example "WHIZZBOX.POWER_TOGGLE" or "WHIZZBOX.POWER_SET".

It would be incredibly useful if it were possible for FSUIPC4 to support these custome events, so they can be selected in the key/button mapping action drop-down list. An implementation could then save and load them from the FSUIPC.ini file. I could then distribute a list of custom events with my gauges for users to add themselves for saving in their aircraft specific FSUIPC settings.

Is this possible? Would you consider implementing such a feature?

Regards,

Si

[Pete Dowson]

As my gauge files often include a SimConnect client, I can map custom events to be trapped and operated on by the embedded client, for example "WHIZZBOX.POWER_TOGGLE" or "WHIZZBOX.POWER_SET".

It would be incredibly useful if it were possible for FSUIPC4 to support these custome events, so they can be selected in the key/button mapping action drop-down list. An implementation could then save and load them from the FSUIPC.ini file. I could then distribute a list of custom events with my gauges for users to add themselves for saving in their aircraft specific FSUIPC settings.

Is this possible?

I don't know. Are these custom events visible globally, and if so, how? I use names for all my events internally, too, but I didn't think SimConnect made them visible to others. I thought the only way for separate SimConnect clients to communicate was via custom data, when you allocate so many bytes, identified by a chosen (unique) name, and used the offsets within as you liked.

That mechanism could conceivably be used for implementing something like what you say, but it would need the creator of the custom area to tell FSUIPC about it, and also perhaps to give details (names/sizes) of the field lengths and actions for them. I suppose that could be via a DEF file or something to save new calls into FSUIPC.

Alternatively, FSUIPC could create a custom area with a published name for other apps to use in the same way. But then we're faced with the usual clash problems for multiple apps unless each is assigned their portion on application. I wouldn't want to operate such a system -- it's awkward enough doing that with FSUIPC'sd offsets for apps.

Regards

Pete

[Simon853]

Custom events are visible globally. I've tested it myself by writing a stand-alone SimConnect client exe and sending them to my client in my gauge dll. They don't even need to use matching event ids, as when you use MapClientEventToSimEvent() with your custom event name, i.e. "WHIZZBOX.POWER_TOGGLE", the SimConnect server handles the translation to the client specific event ids. The only thing you need to be careful of is reletive event priorities and masking of in the two clients to ensure that the client actioning the event is a higher priority than all those capable of sending it.

I started writing a utility myself to handle all event and joystick mappings so people could do this without the confusing and awkward need to map new switches to obscure events in the FSX settings like Concorder nose visor events, but then I realised that since almost everyone uses FSUIPC already that if it supported this then I could save myself a lot of work and users the confusion of having two similar utilities operating simultaneously and potentially clashing on priorities and SimConnect bandwidth.

Si

[Pete Dowson]

Hi Si,

Custom events are visible globally. I've tested it myself by writing a stand-alone SimConnect client exe and sending them to my client in my gauge dll.

That's useful. In that case it would have been really nice for all these complex aircraft makers to use that facility rather than expect folks to assign and use obscure key combinations.

So what exactly do you propose providing FSUIPC so that it can add these to its assignments drop-down lists? Just a data file with a list of names? Shouldn't FSUIPC check that whatever it is actioning these is actually running, or doesn't that matter?

And have you got anything I can use to test the facility with, once implemented?

Best Regards

Pete

[Simon853]

Pete,

I can certainly make a small gauge project with an embedded client to trap and action some test custom events. It'll just take me a day or so to pull it together and then I'll email it to you.

FSUIPC wouldn't need to know whether the aircraft is loaded or not because simply mapping the client event should then make it available to other clients. (i.e. It shouldn't matter which client maps the event first.) However, since you already have aircraft specific mapping profiles in FSUIPC you could take advantage of that. However, there is one potential problem: If a developer build a complex avionics package, like an MFD that was not aircraft specific and could be placed into existing or other aircraft by the user, then FSUIPC wouldn't know that those events were available to be used.

There is one other potentially very useful ability you could consider via custom events: When users map events to persistent (i.e. non-momentary switches), as in home cockpits, when the aircraft is reloaded the client has no idea what state the hardware switch is actually in, so the user has to reset all the switches without triggering toggle events and getting the sim switch positions out of step with the hardware. What I did in my experiment was to create a custom event in my gauge client to poll the switch interface client (which would be then FSUIPC in this instance), with something like WHIZZBOX.GET_ALL_POSITIONS event (posted as at normal priority level.) The interface client then sends the current state of all custom event switches, like "WHIZZBOX_POWER_SET, 1", etc. By doing this the hardware cockpit switches are always synced with the sim switch positions whenever the aircraft reloads. (In the gauge I trap all events at highest maskable, so FSUIPC would need to send the custom events at normal for them to be intercepted.)

As far as how you would mod FSUIPC to support it, you obviously know the architecture of your software better than I, but I assume you could add a push button to the event mapping tab called "Add custom event" or suchlike, which would then open a text dialog so the user could type it in and you could then store all such custom event names in the FSUIPC.ini. Developers could then just publish a list of all these events and their usage, (toggles, value ranges, etc.) in their aircraft/panel documentation.

Si

[Pete Dowson]

I can certainly make a small gauge project with an embedded client to trap and action some test custom events. It'll just take me a day or so to pull it together and then I'll email it to you.

Okay. Thanks.

FSUIPC wouldn't need to know whether the aircraft is loaded or not because simply mapping the client event should then make it available to other clients. (i.e. It shouldn't matter which client maps the event first.)

Okay.

One question, though. I assume the event name strings are the only identification -- to SimConnect and to each registering application? Isn't there some concern that different applications might choose the same string names for subtly or even wildly different purposes? There's no central register of names after all.

There is one other potentially very useful ability you could consider via custom events: When users map events to persistent (i.e. non-momentary switches), as in home cockpits, when the aircraft is reloaded the client has no idea what state the hardware switch is actually in, so the user has to reset all the switches without triggering toggle events and getting the sim switch positions out of step with the hardware.

That's often simply not soluble without the hardware being changed to supply the switch states even when they are not changed. My PFC hardware, for example, only scans and returns a small proportion of its switches. I believe many other switch-connecting boards are the same (e.g. cpFlight controllers appears to work without any regular returns). The only way I ever do it is to do a complete pre-flight check, scanning all switches and toggling those in their incorrect positions compared to the flight I am loading (normally "cold and dark").

What I did in my experiment was to create a custom event in my gauge client to poll the switch interface client (which would be then FSUIPC in this instance), with something like WHIZZBOX.GET_ALL_POSITIONS event (posted as at normal priority level.) The interface client then sends the current state of all custom event switches, like "WHIZZBOX_POWER_SET, 1", etc. By doing this the hardware cockpit switches are always synced with the sim switch positions whenever the aircraft reloads.

You could make that work with standard joystick device types, or those emulating them, because they are polled for their switch and button settings. But it won't work in general. And doing this in FSUIPC rather reverses the way it is designed -- it reacts to button/switch/axis changes, finding the action to suit the change. Operating the other way around, finding the button for each user-assigned action would require a different structure for the tables, or a duplicated one. I'm not sure I want to go that far.

However, I'll give it some thought. The easiest thing to do would be via an added control to reverse the most recently Joystick button memories so that the next joystick poll would cause all of them to 'fire'. However, that would press all joystick-scanned buttons, not just toggles, and could do more harm than good, don't you think? At that level I have no way possible to determine whether a button is acting as a momemtary or a toggle or part of a multi-way switch. In fact I haven't that information even in the action tables, only actions on press and optionally on release, which applies to all types of buttons and switches.

(In the gauge I trap all events at highest maskable, so FSUIPC would need to send the custom events at normal for them to be intercepted.)

FSUIPC always sends events at normal priority. It also traps and logs at highest maskable, but only masks those needed to meet its user's needs of course.

I assume you could add a push button to the event mapping tab called "Add custom event" or suchlike, which would then open a text dialog so the user could type it in and you could then store all such custom event names in the FSUIPC.ini. Developers could then just publish a list of all these events and their usage, (toggles, value ranges, etc.) in their aircraft/panel documentation.

I'd prefer the lists to be supplied or created as files ready to read by FSUIPC, like Macro and Lua files. I really don't like complicating the user interface further -- it isn't an area I excel at, for sure, and it has got to the state now where it is nearly saturated and would need a good re-working.

I suppose such a file would merely contain a list of names, 1=XXXX, 2=YYYY and so on. When I was mentioning how to check if the recipient application was running I was thinking of using the file's name "MYAPP.EVT" (EVT = Event list) to identify it, so the controls were only added to the dropdowns if the file was in the Modules folder AND the App was running. The controls would be:

MYAPP:XXXX

MYAPP:YYYY

etc, to highlight this, even though the event name used would still be just XXXX or YYYY.

However, if the app running isn't particularly important as you say, the filename wouldn't really matter. I'd just read all .EVT files.

Regards

Pete

[Simon853]

Developers duplicating event names could certainly cause clashes, but each developer could isolate themselves from that risk by using their name in the event string, I.e. "MEGA_ADDONS_INC__WHIZBOX.POWER_SWITCH_TOGGLE".

I like the .evt file idea. Simple yet elegant and removes the likelihood of user typos also.

Edit: remember that if simconnect is running as a client in a gauge then there is no client app running, other than FSX itself.

Si

[Pete Dowson]

Edit: remember that if simconnect is running as a client in a gauge then there is no client app running, other than FSX itself.

Sorry, I do include Gauges in this context -- I already have to determine gauge presence for the mouse macro facility where I'm executing calls directly into their code. In fact checking DLLs present in the current process is a bit easier than determining what processes are running.

Regards

Pete

[Simon853]

Pete, if you PM me your email address I can send you over the test example, exe and source.

Regards,

Simon