aua668 Posted July 30, 2015 Report Posted July 30, 2015 Pete, One question: Is there a possibility in future versions of FSUIPC, that the parameter in the macro call from LUA will be passed to mouse macros as the mouseflag? Example: ipc.macro("XXX:MyMouseMacro", 17) triggers the mouse macro in file XXX.mcro with parameter 17 as mouse flag. Why would this be nice? With certain payware aircrafts, you need to work with mouse macros. And some of them need a sequence of the same macro with different mouse flags (e.g.17, 11, etc.). You have an example in your documentation. But some aircrafts need a certain delay between mouse down and mouse up. As in macro sequences there is no mechanism to generate a short delay, you must implement this via a LUA code and with some ipc.sleep(xxx) between the several macro calls. But to call these different commands with different parameters you have to create seperate instances of the mouse macro with the relevant parameters. Example: 1=MyMacro=RX3170*X8b90 2=MyMacro11=RX3170*X8b90,11 3=MyMacro17=RX3170*X8b90,17 and then I can use this in my LUA like this: ipc.macro("XXX:MyMacro") ipc.sleep(1000) ipc.macro("XXX:MyMacro17") ipc.sleep(300) ipc.macro("XXX:MyMacro11") So passing the parameter to the mouse macro as the mouse flag would simplify the coding: Only one macro entry in the macro file and you can pass any parameter as mouse flag from LUA (especially useful if you have to experiment with the flags to find the right sequence). So no new functionality, but maybe you have a chance to check, if this enhancement could be implemented easily. Best regards Reinhard
Pete Dowson Posted July 30, 2015 Report Posted July 30, 2015 One question: Is there a possibility in future versions of FSUIPC, that the parameter in the macro call from LUA will be passed to mouse macros as the mouseflag? Example: ipc.macro("XXX:MyMouseMacro", 17) triggers the mouse macro in file XXX.mcro with parameter 17 as mouse flag. equence). ... So no new functionality, but maybe you have a chance to check, if this enhancement could be implemented easily. Looks to be a reasonable idea. I'll take a look. Won't be till next week though. Pete 1
aua668 Posted July 31, 2015 Author Report Posted July 31, 2015 Pete, Good to hear. No hurry. Take your time and whenever it fits into your plans, it's fine for me. Best regards Reinhard
Pete Dowson Posted August 3, 2015 Report Posted August 3, 2015 Okay, the facilty is in version 4.942, which I needed to release for other reasons in any case. Here's the description of the change, from the Changes document: Mouse macros for which no “mouse action” parameter has been added in the .mcro file can now take a parameter supplied by the calling mechanism – i.e. the assignment in FSUIPCs options, in an ipc.macro call from a Lua plug-in, or by the use of FSUIPC offsets 0D6C and 0D70. If a parameter of 0 is supplied by the caller, and in the macro file, or simply omitted in both, then it is assumed that the normal single left click action is required, the same as a parameter of 29. If a parameter is provided explicitly in the macro file then that is used and the calling parameter is ignored. This implementation thus retains the previous operation and only adds new functionality. Enjoy! Pete
aua668 Posted August 4, 2015 Author Report Posted August 4, 2015 Pete, I enjoy it !!! I did some first tests and everything works as expected. Developing and testing is now so much easier. No reloading of macro files via the Dialog. It's really a great enhancement. Many thanks! Reinhard
gr8guitar Posted January 5, 2017 Report Posted January 5, 2017 Hello. Okay, on the onset. I realize that FSUIPC 3 is no longer supported but this function of: ipc.macro("XXX:MyMacro") Is that already available in FSUIPC 3? On page 4 of the LUA manual, it shows: ipc.macro("macroname"). I have tried: ipc.macro("A321:FCU_100") in attempt to access: A321.mcro which has: 12=FCU_100=RX31d10*X8bcc. In FSUIPC.ini, I have: [Keys.A321] 3=76,11,L24:R,0 where I am attempting to access A321.lua. Also, what does the "R" stand for in the L24:R,0. I did search for it but never did find an explanation.
Donovan Posted January 5, 2017 Report Posted January 5, 2017 Its been several years since I used FSUIPC 3.999z8, but referring to my documents from the time, the ipc.macro("macroname") was available in the lua library at that time. In the keyboard assignments, the R in L24:R,0 stands for "Run" (which refers to Lua Script #24 in the FSUIPC.ini in your example) but that wasn't explained in the FSUIPC for Advanced Users released with FSUIPC 3.xxxxx, or else I couldn't find it there either. (This information is in the FSUIPC4 for Advanced Users on page 30, so I imagine the functionality was present earlier, just not elucidated in the docs.) From your code snippets, it appears the syntax you posted is correct, but as these are only snippets, there might be a syntax error somewhere else in the script or macro preventing execution. Does the mouse macro work properly when you just assign it to a key (as a test)? If so, then enable logging to see where the error is in your lua script syntax. If not, the mouse macro itself may require one of the additional <mouseflag> parameters. Some mouse macros do require them to function correctly (e.g. 12=FCU_100=RX31d10*X8bcc,17 which actually activates upon release of the mouse....) Best, Don
gr8guitar Posted January 5, 2017 Report Posted January 5, 2017 Hello. Thank you for your response. I will have to get back to you. When I started up the flight simulator this morning, it gave me all kinds of problems - strange because other than not getting the lua to work, it worked fine last night - ugh! Change! :) I forgot an 'end' command in the lua, geez; tunnel vision. It works perfectly now. Again, thank you for your info. and of course, FSUIPC.
gr8guitar Posted January 9, 2017 Report Posted January 9, 2017 Hello. Thank you for your response. I will have to get back to you. When I started up the flight simulator this morning, it gave me all kinds of problems - strange because other than not getting the lua to work, it worked fine last night - ugh! Change! :) I forgot an 'end' command in the lua, geez; tunnel vision. It works perfectly now. Again, thank you for your info. and of course, FSUIPC. Okay, a few issues about the other morning: 1) Somehow a '-' got in instead of an '=' in the panel.cfg. 2) When I had unknowingly a sound card failure, I also had gauge issues (gauges using dsd_xml_sound.gau) And 3) Of course the 'end' required in the lua. All resolved except: Now I came across some logic confusing me. In the generic section [Buttons], I have the following: 27=B66C2=5 PM,18,K65,9 ; [SH]A=Bank Angle Limit dec 28=B66C2=5 PM,19,K87,9 ; [SH]W=Bank Angle Limit inc And in the [Buttons.738]: 13=B66C2=2 PM,18,K69,9 ;[SH]E =DH dec 14=B66C2=2 PM,19,K71,9 ;[SH]G =DH inc Even though B66C2 had two different values (5 vs 2), the generic buttons wouldn't work until I removed the logic in the [Buttons.738], do you know why?
Pete Dowson Posted January 9, 2017 Report Posted January 9, 2017 5 hours ago, gr8guitar said: Even though B66C2 had two different values (5 vs 2), the generic buttons wouldn't work until I removed the logic in the [Buttons.738], do you know why? If the aircraft you have loaded in one of the 738 profile, then your profile specific assignments override any other non-specific assignments for the same buttons. If this wasn't so chaos could reign! If you want all 4 actions for the Profile you need to put all 4 assignments in the Profile. Pete
gr8guitar Posted January 10, 2017 Report Posted January 10, 2017 Hello. Thank you for your response. I will have to get back to you. When I started up the flight simulator this morning, it gave me all kinds of problems - strange because other than not getting the lua to work, it worked fine last night - ugh! Change! :) I forgot an 'end' command in the lua, geez; tunnel vision. It works perfectly now. Again, thank you for your info. and of course, FSUIPC. Okay, a few issues about the other morning: 1) Somehow a '-' got in instead of an '=' in the panel.cfg. 2) When I had unknowingly a sound card failure, I also had gauge issues (gauges using dsd_xml_sound.gau) And 3) Of course the 'end' required in the lua. All resolved except: Now I came across some logic confusing me. In the generic section [Buttons], I have the following: 27=B66C2=5 PM,18,K65,9 ; [SH]A=Bank Angle Limit dec 28=B66C2=5 PM,19,K87,9 ; [SH]W=Bank Angle Limit inc And in the [Buttons.738]: 13=B66C2=2 PM,18,K69,9 ;[SH]E =DH dec 14=B66C2=2 PM,19,K71,9 ;[SH]G =DH inc Even though B66C2 had two different values (5 vs 2), the generic buttons wouldn't work until I removed the logic in the [Buttons.738], do you know why? Hello. Thank you for your reply. Yes, I can see how using the same buttons in different profiles versus the generic - if there wasn't logic to assist in determining when to execute it - would indeed cause havoc. I had hoped that the logic that the B66C2 would be compared first before going onto the next instruction. The reason I says this is, it comes from a little background in PLC's (programmable logic controllers). A fancy term for another type of computer, most used in industry. Its logic is, as it scans its "rung" , when it comes across a "false" condition, it no longer scans that rung and moves on to the next rung. So the following instructions (logic) within that rung would never be recognized. We're taught, if able, to write the the logic of a known false condition first. 1) In that case, nothing else following the false instruction gets scanned (read into memory). 2) It speeds up the over all scan rate. - It was worth a try. Knowing that it cannot be done, I can move forward. Again, thanks.
Pete Dowson Posted January 10, 2017 Report Posted January 10, 2017 2 hours ago, gr8guitar said: I had hoped that the logic that the B66C2 would be compared first before going onto the next instruction. Well, yes, it does, but the button identity is the reference. There's no point in processing all the conditions all the time for every button button press. That would be a waste. And in any case the look up table is built each time you change aircraft according to whichever profile it belongs to. 2 hours ago, gr8guitar said: In that case, nothing else following the false instruction gets scanned If this were true here you'd not be able to have multiple assignments to a button, which is often a very useful thing to be able to do. 2 hours ago, gr8guitar said: Knowing that it cannot be done, I can move forward. But it can. You just need all the assignments for that button in the Profile, or all in the Generic section, as you wish. Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now