ark1320

I figured out what happened. Your statement above clued me in. All of my controllers are connected through a powered USB hub, and when I happened to be looking through FSUIPC.ini the power to the hub was off (I wasn't trying to fly at the time) -- so FSUIPC correctly reported there were no controllers connected! So now at least I better understand how naming the controllers provides static (permanent) information (the named controller entries) vs transient controller information (the numbered controller entries) that FSUIPC generates each time the sim is started. Thx very much, Al

Hello Pete, I am currently using FSUIPC ver 4.938f (and I see ver 4.939d is now available and will update) with FSX / FSX-SE on a win7/64 system. I'm am a bit confused on the appropriate entries in the FSUIPC.ini file when using names for controllers. At one time I had the following entires: [JoyNames] AutoAssignLetters=No L=<< MISSING JOYSTICK >> R=Saitek Pro Flight Rudder Pedals R.GUID={2578EE70-32D6-11E4-8002-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={2578EE70-32D6-11E4-8003-444553540000} J=Logitech Extreme 3D J.GUID={EC24C380-3676-11E3-8001-444553540000} 0=Saitek Pro Flight Yoke 0.GUID={2578EE70-32D6-11E4-8003-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={2578EE70-32D6-11E4-8002-444553540000} 2=Logitech Extreme 3D 2.GUID={EC24C380-3676-11E3-8001-444553540000} and just recently I noticed I now have: [JoyNames] AutoAssignLetters=No L=<< MISSING JOYSTICK >> R=Saitek Pro Flight Rudder Pedals R.GUID={D582AD30-48E1-11E4-8001-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={D5EB3300-48E1-11E4-8002-444553540000} J=Logitech Extreme 3D J.GUID={EC24C380-3676-11E3-8001-444553540000} My question is what happened to the other entries that began with a number (0, 1 and 2)? Did FSUIPC remove them because they are not needed, or did I do something wrong that led to their deletion? Should I replace the missing entries that begin with a number? Thx, Al

If you happen to have a Saitek yoke/throttle quadrant , I suggest you read the Calibration Fix info on the Saitek website at http://www.saitek.com/uk/supp/yokefsx3.html to see if what they suggest helps solve your problem. Al

If you are still having a calibration problem, perhaps the Calibration Fix information on the Satiek website at http://www.saitek.com/uk/supp/x65fsx3.html#b might help . Al

Unless you are doing something quite unique that I don't understand, you can certainly use a text editor, like Notepad++, or LuaEdit, to write a Lua program without FSX running and then save the program into the Modules folder. Al Edit: Sorry -- didn't see Pete's response as I was writing this.

Thank you Pete, much appreciated. Al

Reinhard, I'm not sure the event.key trigger will meet my needs, but will certainly look into it. In my application, once the user sends the "Off key" to the Lua app, all subsequent app control keys need to be simply passed onto FSX for normal processing until the app receives the "On key". This is complicated by the fact that each user defines what set of keys they want to use for app control (although they currently do have to use appropriate keypress parameters associated with each control function). In any case, thanks very much for the suggestion. Al

Hi Pete, I'm trying to find a way to make FSUIPC keypress trapping conditional, or "seem" conditional. I use FSUIPC key assignments to control a Lua application, and thus these keys are trapped by FSUIPC. But based on a condition within the application, I would like the associated keypress (key code) passed onto FSX for normal processing, thus in effect implementing what looks like conditional keypress trapping by FSUIPC. The keypress parameter could be used to identify the key to the Lua application, so I guess the critical question is whether or not there's a way to have the Lua program pass a key code to FSX. Does this seem feasible, or am I way off base here in my thinking? Thx, Al

The 10 or so Lua scripts in question are the only ones on his system, and they have been used successfully by other FSUIPC users, so quantity of scripts and script names are not the reason they do not show up in the keypresses drop down list even though they are (I’m told) in the Modules folder as required. I will have to look elsewhere for what is causing that problem, and hopefully he will update FSUIPC. As I know you well appreciate, tracking down problems on another computer by email can be challenging at times! :) Thanks again for your time. Happy holidays, Al Edit: Upgrading FSUIPC from ver 4.3/Jul 2008 has solved the problem -- the Lua scripts now appear in the Controls sent when key pressed drop down list under the Key Presses tab.

Pete, Thanks very much. I should have explained why I asked. I have been trying to help someone (via email) get some Lua scripts running (without success so far) and just found out today he is using FSUIPC ver 4.3 fronm July 2008! He has put the scripts in the Module folder, but they apparently do not show up in the Controls sent when key pressed drop down list under the FSUIPC Keypresses tab. So I thought maybe it was because he is using such a very, very old version of FSUIPC. It looks like his FSUIPC version is not pre-Lua, at least, so the problem is likely elsewhere. In any case, I'm trying to encourage him to finally update. I think he is not very expereinced with computers and is afraid to mess up his system by updating. Thanks again for the response, Al

Would appreciate knowing what was the first version (and approximate publication year) of FSUIPC that supported Lua scripts. Thx, Al

OK Pete, thanks for the reply. Al

Is there a way to force the string in ipc.ask("string"), and the keyboard response, to be displayed in white instead of red letters against the green background? The non-scrolling FS messages to be white checkbox in the Miscellaneous tab of FSUIPC does not seem to effect the ipc.ask function. Thx, Al

Thanks for the response, interesting approach you use. I don't use any of the Saitek supplied software. To make FSUIPC see the Saitek Mode switch, go into the folder C:\Windows\System32 (assuming the C drive is where things are at, otherwise substitute the correct letter) – you should find a file called SaiD0BAC.PRO. Rename this file – I simply renamed mine SaiD0BACmodeswitch.PR0 and left it in the original System32 folder. Then restart Windows, and the next time you start FSX pull up FSUIPC and go to the Buttons + Switches section and flip the mode switch – FSUIPC should register the switch when it moves. Al

Teamspeak3 "sees" the Print Screen key as PRNT SCRN + 255. This is what it shows as the key value when setting up the hot key for push to talk. So I tried using K299 in the conditional button code CR(+Y,8)Y,1,K299,8 where the 299 comes from 44 +255, but that didn't work either. FSUIPC changed the value to K43, probably because keycodes are typically represented in 8 bits, and 299 requires 9 bits. I also tried changing the parameter that follows K299 to something other than 8 without success (tried 9 and 10 as a shot in the dark -- I don't know how FSUIPC makes use of that last parameter). Thx, Al

Thanks for your input, I was not aware of the direct joystick assignment capability of Teamspeak3. The problem remians, however, because I need the Teamspeak push to talk function on the Saitek yoke to be conditional on the position of what Saitek calls the Mode switch. So while Teamspeak3 does directly see the push to talk button, it does not seem to be sensitive to the mode switch position. Al

The current Teamspeak setup works fine when in FSX. However, when using Teamspeak when NOT in FSX, using a printable (and repeating) keyboard key to activate Teamspeak often interfers with what else I'm doing on the computer. Thx, Al

Hi Pete, I have been successfully using the following FSUIPC.ini code (with FSUIPC ver 4.937, FSX & Win7) for a Teamspeak push to talk function using a button on my Saitek yoke: 36=CR(+Y,8)Y,1,K192,8 ;TeamSpeak voice capture start, mode sw=1, K192 for ` key 37=CU(+Y,8)Y,1,K192,8 ;TeamSpeak voice capture stop, mode sw=1 I would like to change the key (keycode) used to activate Teamspeak from the ` key ( the left-most key above the Tab key on my keyboard) to just the Right Ctrl key. If that is not possible, my second choice would be to use just the Print Screen key. I have tried using K163 for the Right Ctrl key option, and K44 for the Print Screen option in the above code, but can't get either to work. When Teamspeak is setup to use one or the other of these keys, I can activate Teamspeak when using the respective keyboard key. Thanks for any suggestions . Al

Szab, In the User Contributions subforum there is a set of Lua scripts called NpC (Numpad Control) that let you set radio frequiences, headings, courses, autopilot settings, etc by entering digits directly with the keyboard numberpad. NpC works for a/c that use the default FSX Offsets for such parameters. Perhaps NpC might meet your needs, at least temporarily until you get your mouse system working. Al

To make FSUIPC "see" the Saitek Mode switch, go into the folder C:\Windows\System32 (assuming the C drive is where things are at, otherwise substitute the correct letter) – you should find a file SaiD0BAC.pro. Rename this file (as an alternative to deleting it) – I simply renamed mine SaiD0BACmodeswitch.pr0 to help remind me why I had done this, and left it in the original System32 folder (of course, you can also place a backup of the file in a "safe" place and then delete the original). Then restart Windows, and the next time you start FSX pull up FSUIPC and go to the Buttons + Switches section and flip the mode switch – FSUIPC should register the switch when it moves. From time to time, for reasons I'm not sure of, the original SaiD0BAC.pro file reappears ( and the mode switch doesn't work) and I have to delete it so just my renamed file remains in the C:\Windows\System32 folder. Please note: I don't use any of the Saitek software, drivers, etc, but instead run everything through FSUIPC, and have not seen any impact of "eliminating" the SaiD0BAC.pro file since I first did this over a year ago. I do not know what the purpose of the SaiD0BAC file is, and what the impact of the above might be if you use the Saitek software. If it does cause you a problem, you can simply rename it back to its original name. Al

Thank you. As you can see, I'm not an expereinced programmer. I now understand my mistake. I thought the initial value of n had to be passed to the function, I see that it does not. The 80ms is my guess at about how long it will take for the function to execute. I'd like the value to be as small as possible while still getting reliabale results. I will determine that by experimentation. Thanks again, Al

I appoligize Pete, but I just don't follow what you are patiently trying to tell me. For my example above, how do I define the "function"? Is it something like function Alt_inc(k) ipc.control(65823, 77) ipc.control(65823) k=k-1 end and then use event.timer(80, “Alt_inc(n)") where I have taken a guess at the msecs value? How do you cancel the event when n reaches 0? If this is "way off" and only a very few lines of code are involved, can you show me what replaces my original loop above? Thx, Al

I looked at event.timer(msecs, “functionname") but I'm afraid I just don't see how to make good use of it in the loop below the purpose of which is to execute the two control functions n times, where the value of n is a function of the preceding code. Thx, Al ... while n > 0 do ipc.control(65823, 77) ipc.control(65823) ipc.sleep (80) n = n-1 end ...

No, it cannot. It is just a message sent to the Windows message queue for FS to pick up and obey. FSUIPC has no idea what the control does, so obviously it cannot check for completion. OK, so that means if the control process takes FSX long enough to exeucute, the loop could "loop" around and issue another control call before the first one had completed. I can see how this could lead to unreliable results. I'll look up the event timer. Thx much, Pete. Al

In some Lua code I am writing I use a loop like the below: ... while n > 0 do ipc.control(65823, 77) ipc.control(65823) ipc.sleep (80) n = n-1 end ... I find to get the loop to execute reliably I need the delay of 80 ms. If I reduce the delay the loop sometimes seems to execute the wrong number of times (i.e., the control functions don't execute the correct number of times) . The initial value of n can be from 0 to over 40. The loop updates information in a G1000 display on an addon aircraft. I use FSUIPC ver 4.936. Does the need for this magnitude of delay seem reasonable? I am also trying to understand why the loop seems to execute the wrong number of times if the delay is to small. When an ipc.control function call is executed, does the system automatically wait for the control function to be completed (and return) before the next loop instruction is executed, or not? Thx, Al