Requesting states of current event button inputs

[Simon853]

Pete,

There's a currently unavoidable issue with switches in custom hardware cockpits getting out of sync with the associated settings in the sim when flights are reloaded if the switches have been moved since the flight was saved.

 

Is there a way to get the state of a current button input without switching it to cause FSUIPC to send an event to the sim's simconnect server?

 

If not, here's an idea for a solution:

 

I'm using custom simconnect event definitions within an .evt file to send on/off custom switch events to my aircraft's simconnect client.  What would be ideal is if I could send a custom event that FSUIPC could trap and in response send all the custom events listed in the .evt file and mapped in FSUIPC to buttons/switches with their current position as read from the DirectInput interface.

 

This would allow my aircraft to synchronise itself with cockpit switches when it loads.

 

Is this feasable?

 

Regards,

 

Simon

 

[Pete Dowson]

There's a currently unavoidable issue with switches in custom hardware cockpits getting out of sync with the associated settings in the sim when flights are reloaded if the switches have been moved since the flight was saved.

 

Is there a way to get the state of a current button input without switching it to cause FSUIPC to send an event to the sim's simconnect server?

 

No, the switches are only seen when they change state. I always start flights in "cold & dark" mode, and just ensure I set all my switches accordingly, normally before I shutdown, but if not at least whilst things are loading up.

 

If not, here's an idea for a solution:

I'm using custom simconnect event definitions within an .evt file to send on/off custom switch events to my aircraft's simconnect client.  What would be ideal is if I could send a custom event that FSUIPC could trap and in response send all the custom events listed in the .evt file and mapped in FSUIPC to buttons/switches with their current position as read from the DirectInput interface.

 

This would allow my aircraft to synchronise itself with cockpit switches when it loads.

 

Is this feasable?

 

Sorry I don't know if it is feasible since I don't understand it. What is reading the state of the hardware switches, and how? And what is "your aircraft's SimConnect Client"? Is that different to SimConnect running in FS and being used by FSUIPC?

 

If your aircraft interfaces to SimConnect, wat exactly are you using FSUIPC for?

 

Regards

Pete

[Simon853]

Pete,

I have a SimConnect client running inside my .gau file that does lots of wonderful things for me.  I use FSUIPC (not from within the aircraft .gau) to extend the list of map-able input events using the .evt custom user event file support in FSUIPC that you implemented at my suggestion a few years ago.  This allows me to create new event bindings for custom switches that aren't natively supported within FSX/P3D.  (Wind-screen wipers, circuit breakers, etc.)  These custom events are then mapped in FSUIPC to hardware switches interfacing as joystick buttons. 

 

The problem is that my aircraft's simconnect client does not know the state of these switches when the aircraft loads and can only infer their position when their state changes and I receive an event.  Ideally simconnect would have a facility to query the actual position at any time, but it doesn't.  I wondered whether in FSUIPC you get this information from the DirectInput driver yourself.

 

So therefore, if the simconnect client in FSUIPC could receive an event from another client (in this case my aircraft) and then fire off the custom events as defined in the .evt and mapped to inputs in simconnect according to the current switch states.  But if FSUIPC itself only receives notification of switch/button states from the driver when they actually change, then this isn't possible anyway.  (Edit:  I should add that I don't know whether FSUIPC is trapping input events via Simconnect, or interfacing with the DirectInput driver and causing these events to be generated. If the former, then this idea won't work obviously as you're subject to the same notification-on-change limitations as all simconenct clients.)

 

Resetting everything to cold and dark every time is one solution, but then doesn't permit flights to be loaded in a running, in-air state.  This limits the flexibility for setting up training scenarios.

 

My current workaround solution is to present the pilot with a dialog immediately upon aircraft initialisation listing the states of all switches saved within the flight file so they can ensure all their hardware switches are set accordingly before starting the flight. (I trap and discard these events during that phase.)

 

(By the way, there are actually some things for which FSUIPC is useful for even if the aircraft's .gau contains a simconnect client.  For example, you cannot subscribe to and receive the FlightLoad and FlightSave system events in a client dll (.gau file) that gets unloaded and reloaded during a flight load/save process.  Because FSUIPC's simconenct client is outside of that process, I can use it's facilities within my .gau code to determine when a flight is loaded or saved in order to load/save corresponding config files for additional aircraft systems not native to P3D.)

 

Regards,

 

Simon

[Pete Dowson]

The problem is that my aircraft's simconnect client does not know the state of these switches when the aircraft loads and can only infer their position when their state changes and I receive an event.  Ideally simconnect would have a facility to query the actual position at any time, but it doesn't.  I wondered whether in FSUIPC you get this information from the DirectInput driver yourself.

 

No, at present FSUIPC also only receives data from normal joystick devices when something changes. I think, in theory at least, it might receive all 32 switches and 8 axes when any one of all those changes, because they are all in one structure, but I don't think there's a way to poll them instead of just receiving inputs like that.

 

It can probably be done by directly accessing them as USB HID devices rather than using the DirectInput joystick API. That can be done using the HID facilities in the Lua COM library, as you can see from some of the examples provided. Maybe you can put together a Lua plug-in to do exactly as you wish? I'm very reluctant to mess now with the innards of FSUIPC's device facilities -- they have been developed and grown continuously for many many years and any changes I make to the code are precarious as I'm forgetting things nowadays!

 

This is in fact why I added the Lua facilities, so that FSUIPC's capabilities could be extended without messing with its internals!

 

If you decide to undertake such a thing, I will give you as much help as I can and hope that the end result might be useful to others and so be published in the User Contributions subforum, or even added to the range of examples in the installed Lua package.

 

I should add that I don't know whether FSUIPC is trapping input events via Simconnect, or interfacing with the DirectInput driver and causing these events to be generated. If the former, then this idea won't work obviously as you're subject to the same notification-on-change limitations as all simconenct clients.

 

It''s using DirectInput and the Windows Joy API -- Simconnect didn't exist before FSX, and these facilities are older. But the reason SimConnect is thus limited is the same, it is more about the way DirectInput works.

 

Regards

Pete

 

[Simon853]

Thanks Pete.  There's lots of things I've got to work on and my workaround is sufficient for now.  If and when I get the time to try out your suggested Lua approach then I'll be sure to let you know how I get on.

 

Thanks,

 

Simon