Pete Dowson

First, please don't deactivate "Exclude THROTTLEn_SET". Very few aircraft implementations need this allowed, and allowing them may mess things up. Second, just to check that it isn't something strange with the PMDG add-on, can you try with another 4 engined aircraft, preferably a default if one exists. Third and last, please park both throttles somewhere that they don't jitter (eg one extreme or the other) then enable Axis logging in the FSUIPC logging tab, and (brieflyl) operate just one of your two throttles. Turn off axis logging soon afterwards to stop the log getting really big, wait a little (to separate well the entries in the log, by time), then do the same for the other throttle lever with the first parked. The log will show which controls are sent when you move the throttle. I think you will find they are correct. Pete

It is only the ASSIGNMENT of buttons and axes which should be in FS or in FSUIPC, but FSUIPC can CALIBRATE axes no matter which you use to assign them, as it detects the actual control being issued inside FS itself, not the joystick input. If you assign in FSUIPC you should actually disable controllers in FS as the latter has a habit of doing automatic assignment without you noticing. Pete

One other good news item. Whilst browsing my code (and this area of it dates back to forgotten times for me. That's the trouble with old age!), I see two things: 1. I keep a register not only of all the devices open and their handles (real and Lua), but also their full path names. And 2. The notifications for devices connecting and disconnecting does provide their full path names. So, for any device, it looks a fairly easy matter for me to add either events for device connection and disconnection (though the former may not be useful if the device handle isn't valid in any case for a disconnected device -- but that's something I can check later), or a "com.testconnected" function, or possibly both ways. I can certainly either make the Lua handle invalid when the device isn't connected, or at least set a flag so that a suitable error return can be made when an attempt is made to use it. All this needs a little more research. Thus, not "messy" at all, really, but probably quite tidy! Sorry about my earlier pessimism. I probably won't be doing any of that in WideClient though. And I can't say when I can get to it in FSUIPC at present. BTW, I'm away from this afternoon until Monday morning. Pete

Okay. Big omission from the Lua com lbrary documentation. I was looking into adding "com.readfeature", so I looked at the code. It is already implemented! It was included at the same time as all the other HID functions. I don't know how it missed out in the documentation. There's also "com.readreport" omitted! I think they were omitted because I had no way of testing them, no way of determiniing whether the results were correct even if I had appropriate devices. I've now found that the GoFlight T8, P8 and RP48 devices have feature bytes, as do the Leo Bodnar BU0836 boards, so I could actually test that they do something. But whether what you get is right is another matter. If you'd be so good as to test them on devices you know and let me know. If okay I'll add them to the documentation. Meanwhile here is what the entries would read: str, n = com.readfeature(handle, repno) Reads the feature bytes from the HID device via the “GetFeature” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error. str, n = com.readreport(handle, repno) Reads the input report bytes from the HID device via the “ReadInputReport” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.

MOVED FROM THE SUBFORUMS! PLEASE ALWAYS POST SUPPORT QUESTIONS TO THE MAIN SUPPORT FORUM, i.e. HERE. Otherwise they may not be seen and answered. The subforums are for reference information not on-going exchanges which eventually scroll off into history. Yes. There is a section, with examples, in the Advanced User's guide, a large part of the section on Button Programming. You can have conditions based on buttons or switches, or on offset values, or a combination. There are button flags which you can turn on and off. and test. Well, you posted a list of your button assignments, but I don't see any attempt made to do any conditional programming, so I can't really comment on what you are doing wrong! If you post what you've tried and explain what you want it to do then maybe I can help more specifically. Unfortunately, I am away visiting my brother for a long weekend and after this morning I won't be back till Monday 2nd. Pete P.S. Additional, forgotten above. The first appendix to the Advanced guide gives examples from a user.

Ah, that explains why I couldn't reproduce it here! ;-) Pete

Sophisticated add-on aircraft like the Aerosoft Airbus Extended do implement many of the sunsystems their own way, without using or obeying the standard FS controls. That is very unlikely. If the Landing Lights toggle control is being sent then the default aircraft do take note. Try the default keyboard assignment for it: L or Ctrl+L or something like thiat (sorry, you'll need to check). You can also check that your assignments are doing what you think yuo assigned them to do by using Logging. In the Logging tab in FSUIPC options enable Event logging. Maybe also Button/Key logging so you can check the button(s) too. Event logging will log any control events occurring whether you use FSUIPC assignment or not. You can also enable the Console Log option there, and temporarily run FS in Windowed mode (ALT + ENTER) to show the log on screen in real time. If the Airbus is different then you'll need to find out how to operate its lights (and autopilot) using whatever means Aerosoft provided. Pete

As I said a few messages back, it is possible, yes, but it is messy. Something maybe to look at one day, but the demand is very small (i.e. only you). Sorry to be so blunt. Easy things I add easily, messy things need a lot more thought before potentially making things worse instead of better. Most folks using HID devices either don't remove them during a session, or if they do, understand they will need to restart anything using them. Even FS doesn't cope with losing a joystick midsession -- you have to restart it. At least FSUIPC does cope -- that was one of the earlier improvements over FS behavious I added. It will be much easier to add the readfeature function, which I will do. But it will be in FSUIPC5 first because that is under more active development. Pete

Which very clearly shows those axes must be assigned in FS, not in FSUIPC. When uncalibrated, as in your case, you expect the value OUT to be equal to the value IN, because there's no calibration -- and you have NO calibration at all. You've not yet bothered it seems! Looking in your INI file you only have 3 assignments: 0=0X,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 1=3X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 2=3Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- So you DO have Left Brake assigned. Nothing to throttle. You have left brake and the yoke assigned "direct to FS calibration", but you haven't done ANY calibration whatsoever. None at all! How do you expect that to work? You apparently have never looked or followed the instructions for Calibration in FSUIPC, so there's no point whatsoever in assigning "direct". You need to ask youself why you are using FSUIPC. What is your purpose in doing so? If you want to use it, think before doing things, read about them If you just want to calibrate better, you do NOT have to assign in FSUIPC at all, but keep controllers enabled in FS and just use the calibration tab in FSUIPC. But whichever way, you should follow the numbered steps to get things calibrated. Pete

For all controllers you can tell F simply not to use them. That is the only safe way to prevent occasional automatic reassignment. I'm just checking where that is in FSX ... ... Settings - Controls - Calibration - "Enable Controller(s)". Make sure that isn't checked. You found the LOG file ! he INI file is next to FSUIPC4. DLL, the FSUIPC4.LOG, and the Subfolder called FSUIPC Documents. I really cannot help you unless you show me that file so I can see how you got into this mess. Have you ever looked at the User Guide at all? It advises you to change the Explorer folder options, to prevent Windows hiding filenames from you. INI files are probably labelled "configuration settings", but anyway it is best to find the folder options and turn OFF the option to hid known extensions for you. It will save you a lot of hassle with many programs. Pete

Oops! I made a silly error in the logging I'm afraid, so it isn't as informative as it should be. This log line is correct: 631016 Autosave: deleting "C:\Users\James\Documents\Prepar3D v4 Files\AutoSave Sun 203950" The .FXML and .WX parts aren't included in the log line, but this log line is certainly wrong: 631016 Autosave: deleting "C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 747 QOTS II\PanelState\" It should have the the full filename. I'll fix that now so we get proper logging. I'll also fix it so that it doesn't log an error line for the 5 x 747 deletions, plus 5 x 777 deletions, when those files won't exist in any case when using the 737. However, though I can't tell precisely from the log which files were deleted okay and which not, in your INI you have 5 files referenced for the 737. The log (which because of my error is showing error 1 for good deletions and no error for deletion failed or file not present) seems to indicate that those I've highlighted here in RED were, in fact, deleted okay: AlsoManage11=C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 737 NGX\PanelState\*.fxml.0.rteAlsoManage12=C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 737 NGX\PanelState\*.fxml.1.rteAlsoManage13=C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 737 NGX\PanelState\*.fxml.2.rteAlsoManage14=C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 737 NGX\PanelState\*.fxml.fmcAlsoManage15=C:\Lockheed Martin\Prepar3D v4\PMDG\PMDG 737 NGX\PanelState\*.fxml.sav Are they ALL actually generated each time, or only those three of them? Please clarify. What files are NOT being deleted? If those were the only three generated, and they are NOT being deleted, then I can only think it is because FSUIPC cannot access that folder for deletions. But in that case it should get an error saying access denied. Anyway, for clarity in the logging, fixing my stupod (hurried) mods, please download this and replace the DLL and run the test again. I've not changed the version number or date in the file, so please destroy the previous one to avoid any confusion. FSUIPC5121b2.zip Regards Pete

I already register for notifications, that's how FSUIPC decides to do a joystick rescan when a device connects -- in case it is a joystick type and the user then wants to make assignments to it. I don't think those API's are device specific. I can't see how to use them in the way you seem to wish. Maybe I'm missing something? Pete

Quite honestly I think your system must be in a bit of a mess. I take it you've removed all FSUIPC settings, by deleting the INI file, so it then does nothing? If you still have problems then you are at the re-install P3D stage I think. Pete

Sorry, this facility is still awaiting action by L-M. Please post your request on their P3D support site to help emphasise this. I've already done so on the developers Beta feedback site, to no avail so far. I think they really assume this area is not of any consequence, or maybe that it is up to the aircraft makers to get their aircraft right in the first place. Yes, folks are patching the sim to achieve these changes. That is how it started with Microsoft's FS, but by then FS was no longer being developed, so there was no alternative. Pete

Instead of deleting FSUIPC just delete your settings, the FSUIPC INI file. There is really no way FSUIPC has any adverse affect on any of those aircraft. There are large numbers of folks happily using FSUIPC with those. And FSUIPC, merely installed and not configured, does almost nothing. All it is doing then is obtaining and supplying data to any client programs which may need this. This applies whether it is registered or not. FSUIPC does whatever you asked it to do, so just delete your settings and think before configuring it again. In any case, FSUIPC has no influence whatsoever on graphics on screen no matter what settings you make or use. Pete

No, that is a LOG file, not your settings file, the INI. That is NOT "disabling", you are just de-assigning. The problem is that if FSX ever thinks you've attached the device again, or differently (which can happen any time), it will autmatically re-assign things, causing conflivcts. The only sensible ways are either ONLY use FS assignments, or use FSUIPC ones. for that, disable controllers in FS, not just de-assign. There is a hat switch assignment for PAN VIEW in FSUIPC which operates the same as in FS assignments. Pete

That's now out of date. The currently supported version is 5.121a, released 0n the 15th. Pete

Duplicated post! Other one deleted. Hey to you too! (We don't address people like that where I come from). :-( Sounds like you haven't installed the PMDG updates. That was a problem a while back which was solved in PMDG code. Sorry, FSUIPC doesn't change or interfere with anything related to screen images. You need to check on the IVAP support site. Anyway, you don't state whether you are talking about FS2004, FSX, P3D3 or P3D4. Also saying "the latest version of FSUIPC" really is not useful. State the version number please. Folks say the "latest" meaning "the last they saw", and in many cases that has turned out to be a pretty old version. Pete

That never helps. All of your settings are held in the file "FSUIPC4.INI" in the Modules folder. Deleting that alone will remove all of your settings and allow you to start again and do it properly. You probably need to reverse that axis in the calibration tab. Either that or your calibration values are allwrong. Just press Reset and start again. Follow the numberewd steps in the Calibration chapter of the User guide. You are in the right place, and I am he, but why post Log files when its your settings I need to see? Show me the FSUIPC4.INI file. Have you disabled controllers completely in FSX? Pete

I did take a look at what is involved in adding a com.readfeature function, and in fact it would be a lot less hassle for me if I went that way. In view of what you say about handles, I could, rather than trying to relate the disconnect and newly connected notifications to the handles which are/were opened (which is rather messy), I think I'd rather do something like saving the last error return I got (read by something like GetLastError in C) whist issuing commands for the device, and providing them on a request such as n = com.geterror(dev) The handles in the 32-bit FSUIPC4 are the 'real' ones. In FSUIPC5, the handles are references to an internal table of handles internally, because for the 64-bit Windows API the handles (theoretically) occupy 64-bit integers, and the current Lua interpreter I'm using still uses 32-bits. Pete

Yes, it would be. But I tried without quotes and it did work here. Can you double check that the pathname is exactly right too? I've added some extra AutoSave logging. Download this: FSUIPC5.121b. Copy the DLL into the Modules folder, and edit the FSUIPC5.INI file, adding: Debug=Please LogExtras=4 to the [General] section. This will make FSUIPC log each autosave and the deletions, with an error number if the latter fail. Pete

But even so, even if you are airborne before the default cutoff of 60 knots GS (possible I suppose with a strong enough headwind), the use of tiller on the rudder ceases once FSUIPC detects that you are airborne (it uses the "on ground" flag from SimConnect). Seems more likely to be due to another assignment. Maybe joysticks aren't disabled properly in P3D. Pete

Please see previous answers. This is not an FSUIPC problem, but something else in your system. Pete

Sorry, are you saying one button does two things and you only programmed one of them? Does the Log show this? Is it supposed to or not? Sorry, you do need to give more details, and use the logging to see what is happening, as I suggested. It will show what button presses are seen and what controls are being sent. Same here. I don't know what you've actually programmed nor exactly what you are seeing. That's why logging is useful. It sohws exactly what you do and wghat is programmed and what the result is, in terms of commands to the sim. According to the previous INI file you posted, the only buttons you programmed for the King Air are: [Buttons.King Air 350] 0=P0,0,C66297,0 -{TOGGLE_AUTOFEATHER_ARM}- 1=P0,2,C66288,0 -{TOGGLE_FLIGHT_DIRECTOR}- 2=P0,3,C66287,0 -{TOGGLE_PROPELLER_SYNC}- 3=P0,4,C66304,0 -{TOGGLE_ALL_STARTERS}- 4=P0,5,C66069,0 -{YAW_DAMPER_ON}- 5=P0,6,C66718,0 -{CABIN_NO_SMOKING_ALERT_SWITCH_TOGGLE}- 6=P0,7,C67094,0 -{CAMERA_RELATIVE_EYEPOINT_BACK}- All those on the Quadrant. So, the flight was saved with the FD on. Pete

I've tested this here with FSUIPC 5.121a, and i cannot make it go wrong. It deletes the files it is supposed to every time. Pete