Intercepting VC Buttons and controls to assign them to keys and buttons

[Zoandar]

I have been working on trying to figure out how to assign Saitek X52 joystick buttons or else keyboard buttons to some VC controls in Aerosoft's payware Seahawk + Jayhawk helicopter addon for FSX. I tried following the nicely written guide here:

http://a2asimulation...hp?f=23&t=19751

But after getting a registered copy of FSUIPC 4.79e set up, what I learned was that operating these controls do not appear in the VARS LUA log as "normal" aircraft controls do. Specifically, my current goal is to map the buttons used on the AFCS Control panel, which is a flight stabilization and autopilot system on these helicopter models, so that I can engage some of them from my joystick or the keyboard rather than clicking on them with the mouse. Is there some other way (aside from making use of the "log lvars.lua" ) that I can discover what events these mouse-clicked buttons are generating and then build them into a macro?

I use these controls most of the time from a windowed view of the AFCS panel, which is always in exactly the same place and size on my displays. So one possible alternative might be to map the joystick to some kind of on-screen mouse click on a specific spot (over the desired button), if anyone can recommend a way to implement that. I have used macro programs which can emulate mouse clicks on screen coordinates, such as Quickeys, but that one in particular interferes with the operation of other assigned control keys and buttons in FSX, so I have to shut it down when flying.

[Pete Dowson]

But after getting a registered copy of FSUIPC 4.79e set up, what I learned was that operating these controls do not appear in the VARS LUA log as "normal" aircraft controls do.

Actually the use of L:Vars this way is a relatively new system and certainly not used by all add-on aircraft. It is commonly used with gauges written using XML rather that those more traditionally programmed in C or C++.

Is there some other way (aside from making use of the "log lvars.lua" ) that I can discover what events these mouse-clicked buttons are generating and then build them into a macro?

The more usual way is via the "Mouse Macro" facilities built into FSUIPC. That works for aircraft gauges built using the Microsoft C/C++ Gauge SDK. Check the FSUIPC User Guide -- most of the work in discovering or making these is automated.

If neither of these two techniques work, and there is no SDK provided by the aircraft author to interface his controls, then I'm afraid you might be out of luck.

Regards

Pete

[Zoandar]

Mouse macros turned out to be just the ticket! When I was first reading about them I got the mistaken notion that a mouse macro was a set of actions which were put in motion by use of the mouse, for example using the scroll wheel to adjust the heading bug. So I didn't immediately think to try them. But once I did try them, I found the process easy to use and it does exactly what I needed. :)

Thanks!

Have you considered allowing multiple mouse clicks in sequence to be assigned a single key press? There are a few instances where it would be handy to have pressing a single key click more than one control on the screen. Ultimately this can be accomplished by programming a keyboard or joystick control to execute sequential keys, each singly assigned to click one button, but I just wondered if you had any plans to add that feature?

[Pete Dowson]

Have you considered allowing multiple mouse clicks in sequence to be assigned a single key press?

No, FSUIPC doesn't assign any mouse clicks. It never sends mouse clicks or movements. I really don't want to get involved in screen coordinates -- things move all the time. Sending mouse stuff is a real pain.

There are a few instances where it would be handy to have pressing a single key click more than one control on the screen.

Forget the screen. The screen isn't anything to do with it. You can assign almost any number of controls or keypresses or macros to one button or switch, and similarly almost any number of controls or macros to one keypress. But to do it you have to edit the INI file, adding the extra lines in there. I simply do not want the dialogues made more complex for such a feature.

Regards

Pete

[Zoandar]

No, FSUIPC doesn't assign any mouse clicks. It never sends mouse clicks or movements. I really don't want to get involved in screen coordinates -- things move all the time. Sending mouse stuff is a real pain.

Perhaps I could have better worded my intent here. What I meant to suggest was to refer to the stage of mouse macro creation where you are looking at the FSX screen and the name of the control on which you just clicked is being displayed, along with a prompt to ask you to enter 'your' name for the function. It seems this is geared toward creating a single click event and name, although I did try doing 3 of them in succession as an experiment. The resulting macro that was created did not work, so I had to delete it and start over. Perhaps the better way to word it would be to ask if you have plans to allow 'harvesting' of multiple click events during this stage.

Forget the screen. The screen isn't anything to do with it. You can assign almost any number of controls or keypresses or macros to one button or switch, and similarly almost any number of controls or macros to one keypress. But to do it you have to edit the INI file, adding the extra lines in there. I simply do not want the dialogues made more complex for such a feature.

Regards

Pete

I understand. When I first started dealing with keyboard and mouse macro programs and such I quickly learned what a headache it is to try to emulate a mouse click on a specific spot in a program window. I try to avoid doing that whenever at all possible. The FSUIPC utility is a very nice alternative, harvesting the name of the control on such a "spot" and allowing a key to be assigned to it. It is unfortunate Windows doesn't have such a feature built into the GUI.

The control panel I am working with sometimes requires the helicopter pilot to press 3 buttons in succession to get into certain types of hover mode. It would be nice to have one key or joystick button handle all 3 of the on-screen click events, so that turning hover mode on is similar to engaging an airplane's autopilot. I presume the vendors of this payware helicopter were after recreating the most realism possible. But sometimes it it nice to just flip a switch. ;) Especially when using both hands on helicopter controls.

Thanks!

[Pete Dowson]

What I meant to suggest was to refer to the stage of mouse macro creation where you are looking at the FSX screen and the name of the control on which you just clicked is being displayed, along with a prompt to ask you to enter 'your' name for the function. It seems this is geared toward creating a single click event and name.

Of course. It has to record an address within the gauge module which has to be called directly by FSUIPC code when you want to use that function from a button or keypress you assign later. What else could it possibly do? Each possible action that a suitable coded gauge can execute has to have its own recorded entry point in the code, to be called to carry out that action on request.

although I did try doing 3 of them in succession as an experiment.

One macro file can contain as many as you like, each one with a different name to identify it. what exactly do youo mean "3 of them in succession"? It is more usual to do a complete cockpit in one session, making one macro file with all of the controls encoded for that cockpit..

The resulting macro that was created did not work, so I had to delete it and start over.

One macro from three separate mouse clicks? Sorry, I really don't understand.

Perhaps the better way to word it would be to ask if you have plans to allow 'harvesting' of multiple click events during this stage.

What would that mean? It makes no sense to me. If each place you click has a difference action, each has to be recorded. Each will have different characteristics. What do you think you would be trying to do with this "harvesting"?

Once you have all your macros created you can put them together how you like, assign multiple actions to buttons, switches, keypresses and so on. Assignment to macros comes later. First you need to record them.

The FSUIPC utility is a very nice alternative, harvesting the name of the control on such a "spot" and allowing a key to be assigned to it. It is unfortunate Windows doesn't have such a feature built into the GUI

I see you still don't understand. FSUIPC in NOT recording a "spot". It doesn't care anything about the window or the display. Once the macro is recorded it will work with no display, with the gauge hidden. The graphics and mouse become totally irrelevant. The macro is directly calling the code behind the gauge, the actual code making it work, directly. There's no mouse, no graphics involved.

The control panel I am working with sometimes requires the helicopter pilot to press 3 buttons in succession to get into certain types of hover mode. It would be nice to have one key or joystick button handle all 3 of the on-screen click events

Oh dear. This IS hard work, isn't it. :-(

I repeat, there are NO MOUSE CLICKS involved. The mouse macro system is a way of FSUIPC finding out what actual code to execute inside your aircraft.

One the macros are recorded you can easily have your three successive actions associated with a key or button. I already explained all that a reply or two back. You can assign as many macros or keypresses or controls as you like, by editing the INI file and doing it there, by hand. THIS IS TO DO WITH ASSIGNMENT ! You do your assignments AFTER you make your macros! You are totally confusing yourself, mixing separate stages altogether!

Pete

[Zoandar]

One macro file can contain as many as you like, each one with a different name to identify it. what exactly do you mean "3 of them in succession"? It is more usual to do a complete cockpit in one session, making one macro file with all of the controls encoded for that cockpit..

THAT single statement, which is something I had not understood from the beginning, nullifies all my previous comments! I understand now, and I have just finished re-creating my key assignments by gathering all the 'gauge module addresses' (a.k.a. mouse click function names) in a single session within the VC, assigning all of them to the AFCS macro. Sweet. It is exactly what I had been trying to ask you if you had intended as a feature in the future, because I did not understand that it works that way NOW. :)

Perhaps the terminology was part of what led to my misunderstanding. Up until tonight's epiphany, to me a 'macro' was a set of any number of events, assigned to an individual trigger (most often for me, a key on a programmable keyboard or a function within, say, a word processor) but ALL OF THEM executed when the trigger was engaged. Whereas, here, the term Macro is being used to describe essentially a whole library of 'possible' events, any one or more of which could be assigned to any one or more trigger events. So this was a whole new definition of the term macro for me.

I apologize for the frustrating confusion. I have learned that when something doesn't make sense to me, it usually means I am missing some information. That was the case here.

My continued reference to "mouse clicks on the screen" was simply because that is a step in the acquisition of the gauge module address using the FSUIPC macro creation feature. I understand fully that when I utilize the assigned keystroke to one of the macro functions attached to a gauge module address it doesn't actually "click the mouse on a button". I was just using terminology to which I am accustomed.

I think the reason why the macro failed, when I tried to acquire 3 gauge module addresses "in succession" in one macro creation session as I mentioned cryptically above, was due to something I learned just now while re-running this whole procedure. I wanted to start over from scratch, to see if in fact I could do all the VC panel buttons at once as you suggested. So I wanted to completely undo the macros I had created last night. When I went into FSUIPC and deleted the keypress assignments I had previously made, and then deleted the .MCRO files I had previously created, I could not get the Create New Macro procedure to work until I shut down and re-started FSX. The text listing the gauge module address would never appear in the VC view when I clicked on a button. I restarted FSX and then it worked just fine. So when I had tried that last night I'll bet I had done something requiring an FSX re-start and did not yet realize I needed to do so, and thus the procedure failed.

I've got a handle on this now, and I have to say this is really cool! And yet I get the feeling I have barely scratched the surface of the full potentials of FSUIPC. Much of the modification I have done all this year to my FSX installation starts out with an idea. "What if I could do this.........". Then I try to find a way to make it happen, if possible. Thanks to your tool, you brought another one of my dreams to reality.

Thank you!! :)

[Pete Dowson]

THAT single statement, which is something I had not understood from the beginning, nullifies all my previous comments!

I wonder how you thought otherwise, then, when the instructions for making a "mouse macro file" has you entering FSUIPC options to start the mouse macro mode and provisding a filename for it, then making al the macros for that file, then re-entering the options to terminate the mode and close the completed file. That's how it is documented. If each infdividual mouse operation had to be in a separate file, why would it have to involve three operations and two names? I cannot see how this is ever implied.

Perhaps the terminology was part of what led to my misunderstanding. Up until tonight's epiphany, to me a 'macro' was a set of any number of events, assigned to an individual trigger (most often for me, a key on a programmable keyboard or a function within, say, a word processor) but ALL OF THEM executed when the trigger was engaged.

Yes, and this is how the term "macro" s used in FSUIPC too. The macro facilities in FSUIPC were implemented for named groups of different (or similar, as needed) actions carried out in the listed sequence and triggered by the assignment to a single button or keypress. It is fully implemented in this way for FS control and keypress actions.

The "mouse macro" option came later and was "bolted onto" this existing facility. Since each mouse action needed some identification, a name, I used the Macro name as the specific action name in the existing macro structure. So, in this case such macros only have one entry -- the code position and check bytes for the action to proceed. There was no room without a massive re-write to do otherwise.

The same happened when I added the Lua plug-in facility. This needed the Lua filename, and again that takes the macro name position, so macros calling Lua plug-ins only have one entry. Then the same happened yet again when I discovered how to write to local panel variables (L:Vars), which also need a name.

So, I ended up with a proper macro facility, in the way you think of it, but with three special cases -- mouse macros, plug-in actions, and L:Var setting, each of which having only one entry.

Whereas, here, the term Macro is being used to describe essentially a whole library of 'possible' events, any one or more of which could be assigned to any one or more trigger events. So this was a whole new definition of the term macro for me.

No, I really am NOT using the term in that way. A macro file is still a collection of macros, each of which can normally contain a series of actions. It is only the three exceptions with names which are restricted

When I went into FSUIPC and deleted the keypress assignments I had previously made, and then deleted the .MCRO files I had previously created, I could not get the Create New Macro procedure to work until I shut down and re-started FSX. The text listing the gauge module address would never appear in the VC view when I clicked on a button. I restarted FSX and then it worked just fine. So when I had tried that last night I'll bet I had done something requiring an FSX re-start and did not yet realize I needed to do so, and thus the procedure failed.

There's actually nothing in FSUIPC excepting some of the more obscure [General] parameter options which would require a restart of FS. It sounds more likely that you deleted the MCRO file without going into the FSUIPC options and ending the mouse macro creation mode. Or simply didn't end it at all and so couldn't start another. FSUIPC will automatically end it when you close FS of course.

Note that you can manually edit the INI and MCRO files at any time whilst FS is running provided you tell FSUIPC to reload them -- each of the assignments and calibration tabs in the options have buttons to press which reloads all settings relevant to that area.

Regards

Pete

[Zoandar]

It is very likely that bits of what I had read in your user manual silently evaporated before I was able to put those documented steps into use. Sadly the state of learning in an aging mind. It happens all too often, I am sorry to say.

Thanks for explaining everything.

Kind Regards,

Zoandar