ark1320

I had not heard of the "TrustedInstaller" before, but a Google search on TrustedInstaller turned up this http://helpdeskgeek.com/windows-7/windows-7-how-to-delete-files-protected-by-trustedinstaller/ and a lot of other possible sources of info that may be of use to you. So it looks like you will have to change the ownership of SaiD0BAC.PRO file so you can rename it. When I said programming the FSUIPC.ini file, I meant setting up the compound or conditional button/switch actions as described in the FSUIPC Advanced User's Guide (that you quoted from above in post #6). As I recall there are examples in the Guide. I can also paste a few examples here from my FSUIPC.ini file when I get home tonight. Al

Yes, you should have three sets of buttons available as with the Saitek software -- suggest you try it. To start pick one button on the Saitek yoke and try programming it in FSUIPC.ini to do three different things depending on the mode switch position. Once you figure out how to do that, setting up the rest of the buttons should be easier. It has been quite a while since I set up my Saitek yoke, so I don't recall all the programming details at this point, but what you need to know is in the FSUIPC documentation. Al

For reasons I don't understand, to allow FSUIPC to see the Saitek Mode switch you have to go into the folder C:\Windows\System32 (assuming the C drive is where things are at, otherwise substitute the correct letter) where you should find a Saitek file called SaiD0BAC.PRO. Rename this file to deactivate it – 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. If subsequently you suddenly find the Mode Switch is not working again, it likely is because the SaiD0BAC.PRO file reappeared in the System32 folder for some reason. I've had this happen a few times. Al

Just FYI, I have the A2A Cherokee and was able to verify that if you set the control to repeat while held you can in fact control the amount of bank by just how long you hold down the related left or right bank control button, and you can also return the a/c to level flight the same way. That seems to mirror the situation in the real a/c where you have to turn the knob to either set the amount of bank or return the a/c to level flight. I do understand, however, you are trying to implement something a little different. Al

Since the control repeats while held, if you don't include a value in the FSUIPC paramater field, can you control the amount of bank by just how long you hold down the related left or right bank control button? If so, it would seem you could use this technique to set arbitrary degrees of bank, and also to return the a/c to level flight. Al

I have not looked into the details, but it seems to me you could use a Lua program that would be activated by a "return to center" keystroke or button. The Lua program would read the current turn knob value (apparently somewhere between -50 and 50). Based on the value found (positive , 0, or negative), the program would then enter a loop if the value was not 0. Each iteration of the loop would inc or dec the turn value (based on whether the value was neg or positive), and then compare the new turn value to 0. If the new value was not 0, the loop would repeat, etc, until a turn value of 0 was reached e.g., a while turnknob ~= 0 do type of loop ** . The loop could include a Lua ipc.sleep(n) function (where n is millisecs of delay) so the value of n would determine the rate at which the turn value of 0 was reached. This all assumes there are Lvars for reading, incrementing, and decrementing the turn knob value. Al ** If the turnknob values are not restricted to integers, then comparing to 0 becomes more involved since as I understand it, Lua uses a floating point format to represent all numbers. A Google search on this should help explain the issues.

Great -- glad you got it working. Al

Polaris, I don't have the TM WartHog, but here's an idea you might try that Pete gave me some time ago: Since in the Flight 1 KA B200 the last (lower) 25% of the normal throttle axis range has been reserved for the Beta range, idle thrust is at the 25% throttle position point. My experience (with the Saitek throttle) has been that when FSUIPC detects the lower limit of the throttle axis range has been reached (-16384 in your case), it assumes this is the idle point. As a result, the throttle jumps to the idle (25%) position unless specifially prevented from doing so by artificially preventing FSUIPC from ever detecting what it thinks is the lower throttle limit (set a lower limit in the FSUIPC.ini file that can't be reached, e.g., -16400). Al

The below is from my post on the Flgiht1 KA B200 Forum in Aug 2014. Perhaps it will help, it works fine for me. (Flight1 forum thread is here http://www.simforums.com/forums/moving-power-levers-into-reverse_topic49963_post327524.html?KW=reverse#327524) If using FSUIPC for axis control and calibration, the trick (provided by Pete Dowson) is to edit the low end throttle axis calibration number in the FSUIPC.ini file to a value a little below the lowest the axis can achieve, eg use -16400 if the lowest the axis can achieve is the typical -16384. FSUIPC treats the low end of lever travel as Idle, which was why the animated power level was jumping up to the Idle mark in the VC just before reverse was entered. With the fictitious lower limit, FSUIPC never thinks Idle is reached. Then under the FSUIPC Buttons and Switches tab use the [throttle lever activated] switch below the Saitek throttle axis to enter Reverse thrust with the F2 Throttle Decr command (with repeat), but DO NOT use the F1 Throttle Cut command when coming out of Reverse thrust (use nothing), because the Throttle Cut command makes the power lever in the VC jump over the beta range to Idle. Al

Hello Josse, I am very happy to hear you find NpC useful. I do not have the FSX Flight 1 ATR72-500 so I can't really say if NpCv2.2 will be an improvement. My guess is the only change would be on how NpC looks on the screen. However, NpCv2.2 works with the Flight 1 King Air B200, so there might be some simulation code common to both aircraft. NpCv2.2 has a selection menu (see the manual included in the download or the NpC YouTube video at NpC Features Overview ) so you could try selecting the KA B200 to see how that would work with the ATR72-500. NpCv2.2 does also provide some improvements in how the NpC messages are displayed, so I think it would be worth trying NpCv2.2. All you would have to do is copy the NpCv2.2 scripts into the Modules folder to replace the existing NpCv1.1 scripts. There is nothing else you would have to do, all your existing key assignments should still work so it should be easy for you to try NpCv2.2. Make sure you have the latest version of FSUIPC. If you try NpCv2.2 please let me know how it works. Thanks again for letting me know you like NpC. Congratulations on being a RW ATR pilot. Al

Ah -- don't know how I missed seeing that offset. Thanks very much, Al

Hi Pete, Couple of things….. Is there a way to determine with a Lua script what aircraft has been loaded into FSX? For example, I’m trying to find a way to detect if the currently loaded a/c in FSX is an A2A Cessna 172, or not. I would like to be able to do this even if the a/c is not powered up. The atc_type entry in the aircraft.cfg file only returns Cessna, which could also indicate the default Cessna. The only thing I can seem to find in the aircraft.cfg file that would help is the ui_manufacturer=”A2A Cessna” entry but there is no offset for the ui_manufacturer field. I tried reading the A2A 172 Mastery Battery Lvar hoping it would return a nil value if some other a/c was loaded, but this does not seem to be the case as a 0 was returned (same as battery off). Any ideas appreciated. Also... While working on some Lua scripts I was a bit surprised to see the offsets for the Nav/GPS switch (0x132C) and Avionics Switch (0x2E80) are 4 bytes each even though they are just on and off (0 and 1) type variables, while the master battery switch offset (0x3102) is a single byte as I would have expected. So I assume I should use ipc.readUD() and ipc.writeUD() to manipulate the Nav/GPS and Avionics switches? Is there something special about these "4 byte" switches that I need to take into account? Thx, Al

NpCv2.2 Update NumPad Control (NpC) is a program for entering Com, Nav and ADF radio frequencies, Transponder codes, VOR OBS/CRS settings, Auto-throttle airspeed, and Autopilot altitude, vertical speed, and heading values in FSX using the keyboard numberpad instead of mouse click spots. NpC is programmed primarily for aircraft with default FSX avionics (radios, transponders, and autopilots that were developed within standard FSX programming guidelines, so it does work with many freeware add-on aircraft). In addition, this updated version of NpC also supports third party add-on aircraft such as the PMDG 737NGX / B777, Flight1 King Air B200 and the A2A Cherokee 180. NpC is a set of Lua scripts and thus requires a registered copy of FSUIPC4 to work. Installation and configuration manual included. An NpC overview video is available at https://www.youtube.com/watch?v=P2p6CHxMOl8 . NpCv2.2.zip

OK, I understand now what you are saying. I didn't realize the Dynamic Friction script made a "permanent" change to the FSX friction values. Nice clever solution on your part to overcome that problem. Glad you got it all figured out. Al

I don't know what you mean by a restore function. According to the FSUIPC manual, once you switch a/c, the Dynamic Friction Lua script should terminate. So if you load the MD80 after, say the King Air, the Dynamic Friction script should not be a factor. If that is not happening, maybe you need to put the MD80 into its own profile that does not call the Dynamic Friction script. Al

If you are using a/c profiles, you can activate the Dynamic Friction script just for those profiles or aircraft you want to use it with. The below is from the FSUIPC Advanced User manual: Automatic running of Macros and Lua plugins By some editing in the INI file, you can arrange for one or more Macros or Lua plugins to be executed, in order, automatically whenever the current aircraft is changed (or, indeed, first loaded), or a specific named aircraft (or Profile) is loaded. This allows switches, offsets, and other things to be set specifically for an aircraft (or aircraft type, for Profiles) when it is first loaded. This is done by adding new sections to the INI file with the title{ [Auto] or [Auto.xxxx...] where the xxxx part is the aircraft name, or part-name (as in Aircraft Specific sections), or a profile name when profiles are being used. These Auto sections thus parallel the Keys and Buttons sections -- the naming and selection follows the same system. The generic [Auto] section is carried out for all aircraft changes whilst the specific ones are only applied to matching aircraft or profile.. Each Auto section contains a series of numbered lines (1=..., 2=... etc) each of which is either a Lua command, or a Macro call. For example: [Auto.737] 1=Lua SetMyOffsets 2=737 OHD:Air Allbleeds When Lua calls run a plug-in which doesn't self-terminate, the plug-in thread still running is killed automatically on an aircraft/profile change. Note the last line above means if you switch from a plane using Dynamic Friction to one the doesn't, the script is automatically stopped as you would want. If you use Dynamic Friction most of the time, instead of turning it on in selected profiles, it may be more convenient to turn it on in general as you do now ( I assume ), and then use a command in specific profiles to turn it off. Exactly what command to use to do that I don't know (maybe something like Dynamic Friction =0), but if it is possible to do Pete will certainly be able to tell you how to it. Al

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.