ark1320

Yes, all remians visible until the Enter key is hit. Yes, all fixed. I repeated all the tests above and now everything works as expected -- red stays red and white stays white. Thank you very much for your expertise and time on this. Al

Hi Pete, I use the ipc.ask() function to display a 5 line menu and ask the user to input a choice (a number from 1 to 5). I tried the following tests after installing the new FSUIPC4.dll into the Modules folder: num_select=ipc.ask("menu string") -- default color option, the menu and user response was red as expected. num_select=ipc.ask("menu string",0) -- 0 color option, and again the menu and user response was red as expected. num_select=ipc.ask("menu string",1) -- 1 color option, the menu was white as expected, but as soon as the user entered a response (a number), the menu itself and the response all turned red. This was unexpected. I would prefer it to all stay white, but can make do with this if the stay all white option is difficult to make happen. Thanks very much for modifying the ipc.ask() function so quickly! Al

The "registry editing documented somewhere on the Saitek support forum" can be found here under Calibration FIX: http://www.saitek.com/uk/supp/yokefsx3.html#b I have used it in the past and found it to be helpful. Al

Pete, Thanks very much for the outstanding support! Al

Yes, an option for white text with ipc.ask() is exactly what I need -- that would be wonderful! I do make extensive use of the Miscellaneous tab option for "all non-scrolling messages to be white" with the ipc.writeSTR() function, but for some reason it does not seem to carry over to the ipc.ask() function. I use ipc.ask() to display a multiline menu, and have tried reformating it to a single line hoping that might make a difference since all my applications of the ipc.writeSTR() functioin are confined to a single line, but unfortunately even then the text with ipc.ask() remained red. The multiline red menu on the green background is difficult to read, white on green would certainly be a big improvement. I have found many posts on the web having to do with FSXers looking to change some aspect or other of FSX red text to white, so I think if you could include an option for white text with ipc.ask() in some future update of FSUIPC, many others would find that very useful as well. Thank you, Al

Pete, I am back to trying to find a way to change the ipc.ask( ) red text color. Could you briefly describe the facility you found in FS that ipc.ask( ) uses? That will point me in a direction to start looking, and if I find something useful I'll report back. Thx, Al

Pete, When under the FSUIPC Misc Tab one or more of the provide menu entry options is selected, is there any way to manage where in the FSX Add-ons drop down list the entries appear? This is a minor issue, but if possible I'd like to group all the FSUIPC related entries together in a particular order. Thx, Al

Pete, You are correct wrt programming multiple actions for a Saitek yoke button/switch using the MODE switch (3 position wheel switch). I just want to pass on that, for reasons I don't understand, in order for FSUIPC to "see" (respond to) the Saitek Mode switch, you have to go into the folder C:\Windows\System32 (assuming the C drive is where Windows is), and find a file called SaiD0BAC.PRO, and either rename this file, or if you prefer back it up somewhere and then delete it from the System32 folder. I simply renamed mine SaiD0BACmodeswitch.PR0 and left it in the original System32 folder. Then restart Windows and FSX, open FSUIPC and go to the Buttons + Switches section and flip the mode switch – FSUIPC should now register the switch when it moves. I do everything through FSUIPC and don't use any of the Saitek software or create Saitek profiles, so whatever the SaiDOBAC.PRO file does (besides hiding the Mode switch from FSUIPC), I don't need it. Once in a while, again for a reason I don't understand, a new copy of the SaiD0BAC.PRO file turns up in the Systems32 folder and my Mode switch no longer works, so I have to go through the above procedure again. This info was passed on to me by another FSUIPC/Saitek yoke user, so I'm doing the same. Sometimes we just have to settle for whatever works, even if we don't know why! :razz: Hope this helps someone, Al

Pete, Where is the current aircraft title available to be read by a Lua script? I can see how access to the aircraft title might be very useful especailly if you have more than one aircraft under a particular Profile. Thx, Al Edit: Ignore above, found it (x3D00). Somehow I never noticed that before. Sorry to have bothered you.

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