Pete Dowson

Start levers need to be programmed for Mitxture Lean 9cut) and Mixture Rich (idle). There's no A/T disconnect as such in FS, it's just the AT off. Ah, PMDG. That's not like other aircraft for FS. You don't need to be advanced. It isn't really FSUIPC you need to understand but the PMDG SDK. In FSUIPC all you need to do is assign to the "custom control" entry and provide the control number. But you have to work that out from the PMDG data you have to hand. Regards Pete

But surely you didn't want the view 45 degrees either side to be instantaneously cancelled to a view forward in any case? Why would you have two different view settings close together on one Lua plug-in in any case? I thought you'd be selecting a view and holding it whilst actually using your eyes on it. Else what's the point? I certainly don't understand "the setting of the view angle comes too early before the view is ready". that makes no sense to me. Sorry. You still haven't explained how you measured the originally reported 1/360th discrepancy in the view. Did you have some sort of massive micrometer scale in the scenery ahead of you? Regards Pete

I think there's some severe misunderstanding here. Why turn on FSX contorllers if you are assigning in FSUIPC, as you said (Remember? You said "Option 1 with no calibration"? -- that's assignment in FSUIPC, as ALL the options I gave were, but to the FS Axis controls). I dudn't itemise any option involving assignment in FSX. All 11 combinations were in FSUIPC. As for reversers, maybe you can't do it that way in the T7 (I dn't know), but with Profiles you can do it differently in each aircraft type in any case. Pete

Why exactly? Pete

Are you perhaps using winXP, or running FS in XP compatibility mode? Please see the thread entitled "I HAVE UPDATED MY FSUIPC TO VERSION 4.91 AND MY SAITEK HARDWARE IS NOT WORKING" where a fix was found and due to be included in version 4.92 on monday. There's a link to an interim updtate in that hread, near the end. Pete

Using FSUIPC to send directly to FSX, you mean, i.e. option 1 with no FSUIPC calibration? Or do you mean not using FSUIPC at all? Assignment direct, via option 3, is likely to be the worst for something which reads the axis controls itself because it would make FSUIPC read them and feed them into SimConnect at a lower priorty level Than they are likely trapping. In other words, FSUIPC is bypassing their traps. The most likely to work is assignment option 1 with no calibration. Pete

It may simply be the way you are assigning or calibrating in FSUIPC. Sometimes the calibration itself throws the A/T off because they may read the axis directly and then the calibrated value dsagrees. If you told me how you've assigned and calibrated the throttles i might be able to suggest something. Either way there are these choices, still using FSUIPC only: Assignment: 1. Assign to FS "Axis ThrottleN Set". 2. Assign to FS "ThrottleN Set" 3. Assign to FSUIPC Direct ThrottleN Only in the last case there is it vital to actually calibrate in FSUIPC. If you do calibrate in FSUIPC there are further options: 1. Normal, no options changed. 2. No Reverse Zone 3. No Reverse Zone with "UseAxisControlsForNRZ=Yes" set in the INI file (in the relevant JoystickCalibration profile if not wanted universally). That gives 11 combinations to try (4 each for assignment methods 1 and 2, including no FSUIPC calibration, and 3 for assignment method 3). One of those should work. Else there may be other ways yet to be determined, as was the case with the Aerosoft AirbusX (which needed L:Vars written to to control throttles!). No, but the symptoms sound familiar. Don't you have the PMDG 737NGX or the Aerosoft Airbus Extended? I think one or the other of those had similar problems and solutions were found. It might be worth browsing a bit. Regards Pete

I just found your question posted in the Download Links subforum for some reason. It won't get answered there so I've moved it to the proper place, the Support forum. They always suggest such drastic things. I suppose they just can't be afford time to investigate and advise of the proper methods. Very few add-on aircraft makers really pay attention to those who find more sophisticated ways of simulating, as I only know too well as a full hardware cockpit user. There are many ways to configure controls in FSUIPC and one of then is bound to work file. In any case when using assorted different add-on aircraft in FS you should create Profiles for different needs. Each Profile can have different assignments, different calibrations and so on. you can even have a profile where you remove your throttle assignments. But note that if this means you are then assigning them in FS, be aware that FS assignments will conflict with any still left in FSUIPC no matter which aircraft you use. The PMDG T7 is very new. I expect there will be postings here with the best solutions before long. It isn't something I'm going to be doing myself because PMDG aircraft just don't work with cockpit builds. Regards Pete

Okay, thanks for confirming. I'll go ahead and make a release of 4.92 for Monday. Please update to that when you can. Best Regards Pete

Yes. The only drawback is that FSUIPC won't see any device changes, for instance if you have just connected or reconnected a joystick. With FSX you'd have to reload FSX to get t to recongnise a device. I wanted FSUIPC to be better than that. Basically all the defaulted-on AutoScanDevices option does is exactly the same thing as FSUIPC does when first loaded -- i.e scans the registry to identify all devices, then acquires those which are joysticks and reads their details. It is most odd that Windows 8 doesn't like this. It does release all previously acquired ones first, so there really should be no problems at all. At present this process also happens if you press the reload buttons to reload settings from the INI file. So if that causes you to lose the controls it would preclude making changes like adding Lua plug-ins or multipe assignments to buttons by INI editing without reloading FSX, so i suppose it might be worth my adding another value to the option, like AutoScanDevices=Never I'll do that in the upcoming version 4.92 due for release on Monday. Regards Pete

Is this all controls, axes and buttons? Does it only affect axes and buttons assigned in FSUIPC, or in FSX too? Do the controls work when you are IN the dialogues, or do they stop when simply entering. It makes a difference. FSUIPC does nothing at all with joystick devices on exiting the dialogues -- it simply exits, nothing more. But on entering it does re-initialise and rescan all devices automatically, just as it does if you press the "Reload" button on some of the tabs. If it is this which causes Windows 8 the problem then you can stop the automatic scan by simply changing this parameter in the INI file: AutoScanDevices=Yes to say 'No'. Then the scan only occurs when FSUIPC is first loaded and when you press Reload in some of the tabs. Or have you tried this already? The outside way is to edit the INI file directly. If someone out there wants to write a utility to do that they are most welcome. A clean install!? It messes you installation up? Regards Pete

Me too! Thank you very much! Pete

Oh no! That's most unfortunate! In that case I am going to have to assume it works, because I am now pretty much committed to making a new release this weekend (4.92). i am away from the middle of next week for nearly two weeks and won't have time in any case to do further changes after Tuesday. Pete

I think that's the reason -- I've tracked down a very small change i must have made, presumably after 4.90, which can make it ignore devices not listed in "HKLM" (the Local Machine part of the Registry). In XP or XP Comparibility mode the data is in "HKCU" (Current User). Sometimes it is in both -- it all depends what happened and what choices are made during installation. Maybe BBQSteve was actually right on the button when he suggested installing the Saitek drivers, because doing that might have fixed the Registry entries. However, I think I might have fixed it now. Try FSUIPC4913d.zip, with the current logging (just in case). If it works remove the extra logging and just confirm. If not I need to see the log again please. Sorry for all the fuss. I'm getting senile. I certainly didn't remember the change I just found, and i still don't! And it can't have been many weeks ago! Regards Pete

Got them, thanks. This is more interesting. On the 4.90 log we see: 796 #### Initialising Dlrectinput Axis Scanning ... 796 Trying: "HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0BAC\Calibration\0" 796 Missing key on HKLM? Trying HKCU (Vista or W7 in XP compatibility mode?) ... 796 Assuming running on Vista or later in compatibility mode! 796 Found correct joystick Id 0 796 ... and a "GUID" value 796 ... okay, Acquired device! 796 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0B4D\Calibration\0" 796 Found correct joystick Id 1 796 ... and a "GUID" value 796 ... okay, Acquired device! In other words it is all to do with the Registry. Are you running FSX in some sort of Compatibnility mode? Please check Properties on the FSX.EXE. Despite the Registry prtoblem, version 4.90 does manage to find and acquire the devices using a work-around fiddle. However, none of the above appears in the 4.913c log, which is mighty strange because that are certainly shouldn't have changed. In the 4.913c log, because the devices 0 and 1 were not acquired, you get many of these when access is attempted: 59155 *** JOY ERROR: The LPDIRECTINPUTDEVICE8 handle for Joy #0 is zero! This is understandable, because unless the device is acquired there will be no handle. What I don't understand at present is how devices can not be acquired and yet the reason for that not be logged. In the recent log additions I though I added logging for all paths. Evidently there's a way passed that which I've not spotted. Anyway, it has narrowed the search down considerably. I may still need a further test, maybe with more logging, but at least this is progress at last! Regards Pete

Well the Lua function calls exactly the same routine in FSUIPC so it s guaranteed to do the same thing. Here is a log using two Lua plug-ins, one only containing: ipc.control(66504,-4096) and assigned to keypress 'V', and the other only containing ipc.control(66504,0) and assigned to Shift+V. Here is the log of them being used: 846087 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=0 846087 .. This key is programmed in FSUIPC4 'Keys' options 846087 LUA.0: beginning "E:\FSX\Modules\atest.lua" 846149 *** AXIS: Cntrl= 66504 (0x000103c8), Param= -4096 (0xfffff000) AXIS_PAN_HEADING 846149 FS Control Sent: Ctrl=66504, Param=-4096 846149 LUA.0: ended "E:\FSX\Modules\atest.lua" 846259 KEYUP: VK=86, Waiting=0 848318 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 848318 .. Key not programmed -- passed on to FS 848505 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=1 848505 .. This key is programmed in FSUIPC4 'Keys' options 848505 LUA.0: beginning "E:\FSX\Modules\atest0.lua" 848536 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING 848536 FS Control Sent: Ctrl=66504, Param=0 848536 LUA.0: ended "E:\FSX\Modules\atest0.lua" As you can see, it is sent to FS exactly the same. There can't in fact be any difference! How are you measuring this value '1' in any case if you aren't logging? Pete

Documentation and examples are provided in the FSUIPC Documents folder installed into your FS Modules folder. It isn't hard, it is barely programming. I'm willing to help and answer specific questions but I do not provide a plug-in programming service. Sorry. You need to at least have a look at what's there and check some examples. The example plug-in "gfdDisplay.lua" shows the use of Go Flight display functions, and there are lots of examples about of plug-ins reading and testing offset values. You could also browse through some of the many examples in the User Contributions subforum. Pete

Er .. where is the line showing the Layer number? If these are in the order you show them, then: is the default definition, which looks good, This one: seems to delete things correctly before redefining them ... ... but then this one does the same again: Area.242 "FTX_AA_65S" (Layer=242) Path(Local/Remote)=ORBX\FTX_NA\FTX_AA_65S except that looking at the parking places it defines: these certainly look like they match the ones you are seeing in SimLauncher, at least in numbers. The BGL its overriding defines parking places 1 - 8, not 1-5 like this and the default. Having two active AFD files doing the same thing is always going to cause you confusion. You must either move that third entry to a lower layer number than the second one 9counting the default as the first, or just remove it altogether if it does not more than undo the work of the second one. In other words this file ORBX\FTX_NA\FTX_NA_NRM05_SCENERY\scenery\ADE_FTX_NRM_65S_Boundary_Co.BGL looks to be the correct AFD you want, but it is being overridden by this file ORBX\FTX_NA\FTX_AA_65S\scenery\65S_ADEX_ORBX.BGL because the latter is at a higher priority (larger layer number). I reckon you could remove that last file and things would be right. Try renaming it from BGL to BGX. I don't know why P3D takes you to correct places. That makes no sense to me, but since you've not sent me these two relevant BGLs I can't really investigate further at present. Regards Pete

Well there's no way FSUIPC simply closes up and goes home. Have you checked the log file? Sounds like SimConnect is stalling. If so there'll be lots of log entries showing FSUIPC complaining about getting no data from SmConnect and trying to reconnect. Maybe when you disconnect from the IVAO network that somehow also causes SimConnect to stop communicating? Pete

Glad the solution was so simple. I must admit the stuff for the earlier Airbius X had me thinking on different lines altogether -- the solutions there were very different! Pete

Actually from the diagrams (not the French) it looks as if he's wired the throttle in reverse, as it shows TOGA at -16192 and reverse at +11953, so it seems the reversal is built into the Airbus (a deliberate attempt to stop folks using hardware controls??? You can reverse an axis at the assignment stage, without using calibrations, by editing the assignment entry in the [Axes...] section of the INI file, adding a multipler parameter at the end of the line. e.g ,*-1 multiplies the value by -1, so reversing it. Regards Pete

I'm using XP on all the Client PCs working the cockpit. I only use Win7-64 for FSX and on my main development system. And I have a Notebook running Vista 32-bit, mainly to check compatibility occasionally. I tried Win 8 on that and it was a disaster -- couldn't get decent video drivers for the mobo video chip and the default drivers were abysmally slow and couldn't give me the correct resolution. Regards Pete

There's realy no code to check. It doesn't touch the control number or the parameter, it just sends them on to FS. Not sure why you need a Lua script for this. I've just tested it using direct assignment in FSUIPC's "Keys" tab (would be the same in the Buttons tab). I assigned V to "Axis Pan Heading" with parameter 4096, and Shift+V to the same with Parameter 0. Testing it, V changed the view to 45 degrees left and Shift+V returned it to directly forward. If you log Axis controls (see logging tab) you can check what is actually being sent. Here's a section of my log doing the above (I'm also logging buttons and keys here): 170306 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=0 170306 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 4096 (0x00001000) AXIS_PAN_HEADING 170322 FS Control Sent: Ctrl=66504, Param=4096 170322 .. This key is programmed in FSUIPC4 'Keys' options 170509 KEYUP: VK=86, Waiting=0 176671 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 176671 .. Key not programmed -- passed on to FS ... 177576 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 177576 .. Key not programmed -- passed on to FS 177592 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=1 177592 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING 177592 FS Control Sent: Ctrl=66504, Param=0 177592 .. This key is programmed in FSUIPC4 'Keys' options 177685 KEYUP: VK=86, Waiting=0 178044 KEYUP: VK=16, Waiting=0 That worked fine. If the control with parameter 0 is being sent and your aircraft isn't responding then I can only think it's an add-on which for some odd reason is trappping and preventing a Pan of 0. Pete

You need to find out how that aircraft and software wants reverse thrust controlled first. Try ProSim support or their documentation. I do not know every single add-on and aircraft that can be used in FS. You need to say what you need to do. Pete

Yes. The GF DIO is catered for in the Lua gfd library. You have full control over all facilities of the DIO in that library. You just need a small Lua plug-in, driven by events for offset changes (event.offset function) which call specific functions to light or entiguish the LEDs. The Lua would be started by an [Auto ...] section for the relevant aircraft Profile. Regards Pete