ark1320

Could someone please confirm event.button() is working in the latest FSUIPC7 ver 7.3.7. I have tried using the example TripleUse.lua script "as is" (copy and paste) except for my particular yoke and button, and can not get it to work. When I press the button on my yoke the FSUIPC7 button assignment window shows Joy# Y and Btn# 0, so in the top of the script I have assigned joy = "Y" and btn = 0. My FSUIPC7.ini file shows my yoke as below, so I have also tried using joy=0 in the lua script but it made no difference. Y=Fulcrum One Yoke Y.GUID={99F39220-9632-11EB-8001-444553540000} 0=Fulcrum One Yoke 0.GUID={99F39220-9632-11EB-8001-444553540000} I have been able to confirm the script is being called when I push the yoke button, but event.button() does not seem to be calling the function "buttonpress". Here is the complete script: joy ="Y" btn = 0 interval = 500 -- 1/2 second press, gap, press limits ignorepress = false -- Function to time the button being pressed or left released -- Allow only up to "interval" till decide no change local function timebutton(test) while true do time2 = ipc.elapsedtime() if (time2 - time1) > interval then ignorepress = false return false end if ipc.testbutton(joy, btn) == test then time1 = time2 return true end ipc.sleep(20) end end function buttonpress(j, b, du) -- ipc.control(66375) -- GPS/NAV toggle used just for testing if buttonpress() is being called. This does not work when the ipc.control code is enabled. if ignorepress then ignorepress = false return end -- Note time button was pressed time1 = ipc.elapsedtime() time2 = 0 if timebutton(false) then -- First press / release counts: see if there's another if timebutton(true) then -- got another press in time, look for release if timebutton(false) then -- this was a double press, send VIEW RIGHT ipc.control(65676) end else -- This was a single press, send VIEW LEFT ipc.control(65680) ignorepress = false end else -- This was a longer press, send VIEW FORWARD ipc.control(65674) end end -- ipc.control(66375) -- GPS/NAV toggle used just for testing if script is being called. This does work when the ipc.control code is enabled. -- Enable event on button being pressed (only) event.button(joy, btn, 1, "buttonpress") If event.button() is working for others, than I will go back and see if I can figure out what I'm missing. Thanks, Al

If I understand this correctly, if for example FSUIPC7 sends the keystrokes Shift + M to the sim, MSFS only sees the M. That is certainly good to know. Thanks! Al

I certainly accept your judgement on this, no need to change anything for me. What had mislead me a bit was I looked "back" at P3dv5, which I still use, and using a button to send key strokes to activate a lua script still works. Of course, a different sim has different considerations. Thanks for the explanation, Al

I did some more testing. What is working is I can send a key sequence to the sim from a button push and get the expected response. What is not working is activating a lua script by sending a key sequence from a button push. I have tried buttons on different controllers, sending different key strokes, to different Lua scripts -- none work. In the attached files I tried 3 times to use Btn#2 on my saitek TQ to send the key sequence lctl+X to activate TestScript.lua. Sending the key strokes directly from the keyboard works. Pushing the button while in the FSUIPC7 Buttons and switches tab also "works" -- that is, the fields are filled in correctly by FSUIPC7 in response to the button. But in the sim, the associated lua script does not run when the button is pushed Of course I can always activate a script "directly" by using the right side of the Buttons and switches window (send for FS control), but I have some scripts that I like to be able to activate from either a button or the keyboard, and so to keep things consistent I use the button to send the key strokes. The question is why can't I activate a lua script by using a button to send a key stroke -- it did work previously, so what have I messed up? Thanks, Al FSUIPC7.log

Hi John, I'm using FSUIPC7 ver 7.3.6 and can no longer get sending keystrokes with a button push to work. I'm not sure when this started, but Lua scripts that worked with this are not too long ago (few weeks or less) are no longer working. All looks normal in the FSUIPC7 buttons tab when I push a button, and the scripts work if I send the keystrokes using the keyboard, but the scripts are not responding to the corresponding button pushes. Very strange. I've tried reinstalling FSUIPC7 but that didn't help. Appreciate any ideas? Thanks, Al

Thanks John. Al

I have two displays and use MSFS in windows mode. Sometimes after starting MSFS, I need to move (drag) the sim window from my normal HOME display (display 1) to the "other" display (display 2, my sim display). When I do this, FSUIPC7 Wnd library display locations do not also move to display2 with the sim, even if I restart FSUIPC7, and even if after dragging the sim to display2 I then make display2 my new HOME display and then restart FSUIPC7. So it seems the only way to get the FSUIPC7 Wnd library windows to display on display2 is to make display2 the HOME display before starting the sim. Remembering to make display2 my HOME display before starting the sim is certainly reasonable and not a big issue, but I do forget to do this at times (sigh), so I'm curious to know if by any chance there is a convenient way to get the the FSUIPC7 Wnd library displays to move over and display on display2 without having to first make display2 the HOME display and then restarting the sim, which is a bit of a pain since it takes a little while? Thanks, Al

Can a value be returned from a function called by an event in a manner similar to a "regularly" called function? For example, if I have event.key(keycode, 0, "keypressed") can a value be returned from keypressed()? I have tried value_returned = event.key(keycode, 0, "keypressed") but that doesn't seem to work. Thanks, Al

Yes! And I used versions of your script in the MSFSmoveAircraft and Set Future Pause for MSFS or P3D scripts that are in the User Contributions subforum here. I was hoping that since that time Asobo had made things a bit easier. However, it has been a while since I wrote those scripts -- I need to go back and review the details. Many thanks, Al

Well John, that is very interesting. What I had found was the increment script worked fine if I repeatedly pushed and released the key that called the script. But if I held the key down, or repeatedly pushed and released it very fast, it only incremented once or twice and then "quit". I thought I had read that a repeated call to a running Lua script would kill it, and then restart the script, so I thought that was the problem. I just searched through both the FSUIPC7 User and Advanced User Guides and could not find anything to that effect -- so another age problem I guess! I will look further and try to figure out what is going on. Thanks very much for the help! Al

Guess I was not clear. I was not asking for anything to be modified for ALL users, but rather if there was technique I might use for my particular situation. I will look into the event.key function idea -- thanks! Thanks. Al

My understanding is if you recall a Lua script while it is running, the first instance of the script is immediately killed, and the script is restarted. Is there a way to modify this behavior, such that the running script will ignore any repeated calls until it has completed? What I'm trying to do is use a script to repeatedly increment a sim value while a key is held down until the current target value (which is displayed) is reached. The script is very simple, it just reads the existing Lvar value, adds 100 to it, and writes the new value back. Thanks, Al

John, A wnd.ask() function would sure be helpful, but I can appreciate your time constraints. Thanks, Al

Hi John, Do you happen to know if there has been any "advances" in the MSFS SDK that supports getting user input values via the keyboard? I'm thinking of something similar to the ipc.ask() function that we have available in FSX and P3D. Thanks, Al

Thanks John -- I apologize for not seeing this info in the manual. Al

My understanding is the max button number you can use for programming a button is 31. I'm asking because another user I'm trying to help pushed a button he was trying to program and what showed up in the FSUIPC7 button window was Joy# A with Btn# 146. I know you can have many joysticks, and I thought, a max button # of 31 with each joystick (ignoring the hat switch button #s). I was surprised to see FSUIPC7 report a button # of 146. So there is something I don't understand. Thanks, Al

Is that something you do in FSUIPC7, or in the sim? If in FSUIPC7 I don't understand how to do that. In contrast to the above, I find the Tiller axis too sensitive, even with a slope of 15 -- it is hard to keep a/c on the center line. If on the calibration tab for the Tiller axis I set the axis extremes at - 8192 and +8192, would that further desensitize the Tiller axis? Thx, Al

For anyone who might be interested, I went back an tried a flight test. In MSFS I set both aileron axis Sensitivities to -95, and set the Dead Zone to 95. I then took off and the plane flew normally -- the aileron response seemed unaffected by the MSFS Sensitivity and Dead Zone settings. So I conclude the FSUIPC7 axis control inputs bypass the MSFS controller axes settings which, in my opinion, is unfortunate. It would be useful I think to be able to use both FSUIPC7 and the MSFS controller settings to fine tune the response of axes. Al

It is the delta value - inly value changes greater or equal to this are sent to the FS. When I look at the Delta box value in the axes assignments tab, I see values like 256, not 16. And not all my axes in the FSUIPC7.ini file have a /n after them, but they all have a Delta value on the axes assignments tab when I do a rescan and move the axis. Do default delta values of 256 not show up in the ini file? After a rescan and the axis is moved, does the Delta box value reflect the currently assigned Delta value? Thanks, Al PS: Hope you had a good holiday!

Well, if seems that way if just looking at how the rudder moves while the a/c is on the ground is a valid test for the rudder axis. If you ever have time and a reason to look into it I'll be interested in what you find out. Thanks, Al

I calibrate all my controller axes through FSUIPC7, make use of the slope curves where it seems useful, etc. In some cases it also seems there might be some benefit from also using the controller sensitivity curves in MSFS. I originally thought the axes output from FSUIPC7 calibration would become the axes input to the MSFS sensitivity curve settings. So, for example, if you used a FSUIPC rudder axis slope of 4, and had a rudder sensitivity setting of -50 in MSFS, both of these "calibrations" would be applied to the final input to the sim aircraft -- or so I thought. But after some additional testing it does not seem to work that way. As an extreme experiment I set the rudder axis sensitivity curves in MSFS to -98, and a dead zone of 95%, and then looked at rudder movement while the a/c was sitting on the runway. Small rudder inputs still seemed to move the rudder despite the extreme sensitivity curve settings. 🤔 So it seems FSUIPC7 calibrated controller inputs bypass the MSFS sensitivity curves. If anyone has tried something similar I'd be very interested to learn what you found. Thanks, Al The above was edited after additional testing.

The calibration entries for my brakes in my FSUIPC7.ini file look like the below. What does the /16 indicate? I don't see anything like that on any other of my axes. Is that a setting I have control over? LeftBrake=-16384,16383/16 RightBrake=-16384,16383/16 EDIT: Also, my Steering Tiller axis is: SteeringTiller=-16380,-1024,1024,16380/8 My understanding is that the input range from -1024 to +1024 defines a dead zone centered on 0. Is my understanding correct? And again, similar to the above, I don't know where the /8 came from. Thanks very much, Al

John, Based on the above, my understanding now is that if a Profile specific a/c has a Calibration section, that rules in total and no General section calibrations settings apply to the profile a/c. And the same idea holds for Axes sections, which I don't think I realize before this either. So in summary, between the general and profile specific areas, axes and calibration section specifications work on a sectional existence basis, and key and button specifications work on an individual key or button basis. Thinking about all this a little further, I assume default values are used where necessary if the profile calibration section fails to mention a necessary setting. So for example, if the profile calibration section had no entry "UseAxisControlsForNRZ", a default value (e.g., UseAxisControlsForNRZ=No) would apply. Thanks very much for this info -- extremely important and helpful to say the least!! Al

I'd like to confirm that axes calibrations settings specified in the general (non-profile specific) area will apply to aircraft specific profiles if those settings are not explicitly specified in the aircraft specific profile areas. In other words, the axes calibration settings work like the keys and button assignments as far as the non-profile/profile specific relationship is concerned. So, for example, an axis slope value set in the general, aircraft non-specific area will apply to profile specific aircraft if there is no corresponding slope value set for a profile specific aircraft. Do I understand this correctly? Thanks, Al

BTW, similar to the above, the Saitek TQ has a switch (T7) at the bottom of the Prop axis, and the button assignment below works to move the Kodiak 100 Prop lever into the Feather range when the Saitek prop lever is pulled all the way back to activate the switch. Al