Pete Dowson

If clicking on a button or switch or dial does not bring up the macro naming and testing window, then mouse macros are not supported for that button or switch. In fact very few new add-on aircraft support mouse macros. To do so they must be written strictly to the original FS9 C/C++ gauge SDK issued by Microsoft. A lot of FS9 aircraft did so (but sadly few parts of FS's own default aircraft!) I don't know which aircraft you mean by PMDG V3 (I've never heard of a V3), but if it's one of 737NGX, 777X, 747QOTS II, then all those come with a complete set of custom controls you can use, assigned in FSUIPC using <custom control> and the number of the control derived from the documentation PMDG provide in th SDK folder of their aircraft (in the .h file, near then end). If it is none of those aircraft, then maybe it uses L:Vars (local panel variables) which can be written using normal (not mouse) macros. You might want to seek help in the PMDG support forums. I don't have any of their aircraft. Pete

Sorry, no I can't see. The picture is too small and it's not the right way to ask questions. Why not just say what it is you need to do and what you actually tried? Pete

Er, exactly what keystrokes do you think "0" and "0,1" send? 0 is nothing, no key, 'null'. You need to look up the number rerpresenting the key you want to send. And the second number is a set of shift values added together. You omitted a second number in the first and gave an invalid one in the second. The documentation lists all the valid keycode numbers AND the shift codes -- the former in the Appendix on page 20 of the Technical guide, and the shift codes on the page before. What's KeySend1 defined in WideClient for then? Not sure having the key repeat whilst pressed is a good idea. Won't that keep toggling PTT on and off all the time? As documented, ScrollLock is code 145. Did you not look? An unshifted Scroll Lock would be 145,8. If you want it to be pressed with one keysend and released on another, so you can program that on your button press and release, you need different shift codes. Why didn't you just take the TeamSpeak example in the documentation and change the F12 keycode (123) to the ScrollLock keycode, instead of somehow deciding on 0 and 0,1? Please do use the documentation provided. It would be much more efficient and easier for you than composing messages here and waiting for answers. That's why documentation is produced, so users can look these things up! Pete

Really? What is not clear. Regarding the IN and OUT values I really cannot be clearer than explained in the paragraph I pointed yo to. And if you'd followed the numbered steps when calibrating you would have certainly undertstood why there are two central values. How can a zone be described by one value? Sorry, but I'm not going to repeat here what is already written clearly and has been now for about 18 years without any real misunderstandings, even by those whose first language is not English. Pete

They are exactly as described in the User Guide, page 45, the whole of the 2nd paragraph after the picture of that screen. Did you not look? They affect nothing as displays because they are just informative displays. For a properly calibrated centre zone neither will usually be zero and with proper calibration they would certainly be different unless you have a most unusual control which always centres EXACTLY same each time, no matter what pressures were applied to the springs. Why not simply read the user guide, which has a whole chapter on calibration, with both pictures and numbered steps to good calibration? it would be much faster for you, and more efficient, than posting questions here for basic things already covered quite thoroughly! Pete

I assume you mean "FSUIPC"? I don't know of an SFUIPC. Sorry, I am not following you. After you name the macro FILE you exit from the Options screen. Are you doing that? The macros themselves then need naming. You create one macro file containing all your macros for that aircraft or aircraft type. Pop up where? The macro facilities in FSUIPC have not changed ever since they were first added, so perhaps you gave forgotten? Please refer to the User Guide. Pete

No, the fact that it is 16 bit is in the "UW" parameter which means "Unsigned Word" (WORD = 16 bits). Since the event.offsetmask function is checking whether specified bits in the value have changed, it obviously needs those bits provided else it doesn't know what to test. When just reading a value you use event.offset. That will be triggered on any change in the offset. Pete

Sorry, though I appreciate the thought you put into your idea it is really way beyond the simple deletion option I currently have, wildly different from the simple "an aircraft has been added -- if we are above the limit now or below the target frame rate -- delete furthest or xxx (choices very limited dictated by the options)". The current code is simple and efficient, only a little complicated to read because f the different options (which can interact) and the deliberate method of randomising the choices. The important thing to note here is that action is ONLY taken at present if the addition of an aircraft pushes the total over the limit, or a drop below the target frame rate is current whilst an aircraft update is going on. There's no continuous computation or examinations of aircraft positions going on at all. To impose that much more processing I would really say that having it as a separate Process, not running within FS's process as FSUIPC does, is preferable. May I point you to existing add-on programs which do just this sort of thing -- AISeparation, AISmooth, both of which do work okay but are not perfect, and of course the much more ambitious and more competent and complete AI Controller -- which also makes them follow correct SIDs and STARs when properly configured to do so (a bit of work involved to get that sorted, but there are some good examples to try). For that last one look here for the open Beta of Version 2: http://www.avsim.com/forums/topic/498931-ai-controller-20-gate-to-gate-control-open-beta/ Well, it may be easier for the user, but overloading a process rather than separating such jobs into separate ones, is often just not the best way. Also separate programs can often be run on a Networked PC, saving even more of the load on the FS PC. I think all the current examples are networkable. Ah, yes, the one who provided the voice wave files I found I couldn't interpret too well! ;-) Pete

Two things: 1. It won't work with buttons set as Toggle buttons in the ButtonScreen definition. 2. Offset 0892 with never have the '16' bit set, as it only has the starter switch positions 0-2 for jets, 0-4 for props. Therefore the value with a mask of 16 is always zero. Pete

You are very welcome! Thank YOU for testing it for me. I'm still hoping for a tester to volunteer who is using Windows 10! Last time, with 4.963, it was all tested out fine on Win7 but fell apart with the first Win10 user. I'm pretty confident that won't happen this time, as I'm only using things I was previous using okay, but it needs testing. I might have to just release it as an interim version and see what happens ... Pete

You most certainly have controllers also enabled and assigned in FSX as well as in FSUIPC. Disable controllers in FSX, as we keep telling you!! You don't listen to us! The only way you get double assignments is by having control and FSX. Use one or the other. I notice you don't have any axes assigned in FSUIPC for aircraft generally, only for your "Majestic Q400" profile which is used for these two aircraft only: 1=Cessna Skyhawk 172SP Paint1 2=MJC8Q400_ANZ You've also not calibrated at all, only enabled calibration without actually doing it! There are numbered steps to good calibration in the User Guide. You also have no buttons on your devices assigned in FSUIPC, so either you are not using buttons at all or you are still using FSX assignments, again showing you have duplicate controller assignments for the axes! BTW, why did you purchase FSUIPC? What is your intended use? You currently seem to be making very little use of it. Did you refer to the User Guide at all? Pete

Please try FSUIPC4964c_TEST.zip. Third time lucky, maybe? Pete

And for the same reason, exactly! Hmm. I don't understand this. I'm going to have to think about it ... back tomorrow, maybe. Pete

Those log entries, " ***** HID USB device reconnected ..." are NOT records of FSUIPC "attempting" anything at all. they are notifications sent to FSUIPC by Windows when a USB device connects -- the same signal that also gives rise to its sounding of such connections being made, like if you pull a USB plug out and plug it in again. The 4 reconnections will be your 4 devices denig detected as reconnecting by Windows, bit 4 attempts to connect by FSUIPC. The joystick device scan in FSUIPC is automatically re-run when it is told of a connection. It is the same scan as at initialisation. I see from the log that the reconnection is very short-lived indeed and in fact the devices are still disconnected when the scan occurs. Hence the empty list. The only times I EVER get the symptoms you are seeing are when either I disconnect a device, or the power fails on one of my USB hubs. The fact that all 4 of your devices are doing this together means they are all either on the same faulty hub or if all connected directly to the PC they will be a sign that the USB hardware on your motherboard is failing. Both FSUIPC and FS/P3D use standard DirectInput, a part of DirectX. FSUIPC and FS/P3D are dependent upon Windows for the data regarding these devices. There is no direct connection by any program using DirectInput, it all goes through the same Windows functions and motherboard drivers no matter what sort of data is handled, raw or processed. Those are simply slightly different calls. It may be that for Windows to operate devices correctly it needs to see certain signals which your evidently much cleverer program does not, but I find that quite hard to believe! Maybe you can find its secrets from the author so that Microsoft can do a better job. ;-) Check hubs, connections, and wiring. Try different USB cables. Try different PC sockets. Maybe get a separate USB card for the PC so the on-borad USB can be bypassed. Check the power supplies for any powered hub. Pete

Please download FSUIPC4964c_TEST.zip for the test DLL, version 4.964b and let me know. Thanks, Pete

Okay. I think I've fixed it. Could you try FSUIPC4964b_TEST.zip please? Pete

I now realize I didn't really understand what you were getting at here. When throttle sync is engaged, all 4 axes are immediately set to the current Engine 1 setting. That works fine here in all assignment modes I've tried, including both FS control assignment and Direct to FSUIPC assignment, with combinations of REVersed axes, and "NRZ" set axes. It certainly doesn't wait before setting those other 3 axes. It is done immediately and internally by writing the current value for throttle 1 to the other three throttle offsets. However, I have been experimenting here, and have found that when disengaging Throttle Sync, nothing happens visibly until you move one of the levers. With throttles 2-4 they will jump to their last actual axis position. I can't do much about that as I can't actually tell the axis what to send me. You'd need to approximate the sync'ed position manually before disengaging. However, the throttle 1 axis was changing on disengaging sync too. That shouldn't happen, so I checked and found the calibrated value used for synchronised throttles is actually different that the one used when they are not synchronised. Very odd. I've corrected this in version 4.964b which I will upload soon for you to try. I'll post a link in this thread. Pete

Yes, so make sure Controllers are deactivated, as Thomas said! Pete

Whilst a keyboard is usually a USB device, it is not a joystick device. Assignment in FSUIPC to keys is not related to any device or joystick scanning. You just assign to keys. I don't know of any keyboard which is not "external" in any case. ;-) Multiple keyboards all look like the one keyboard. There is very little non-specialist software which can be set to treat different keyboards differently. You don't gain any extra keys over a standard extended keyboard. The topic for multiple joystick devices is the one pinned at the top of the forum. Pete

I couldn't resist having a quick look. The problem appears to be that it seems to get the same GUIOS for both of the pair, from the registry. I'm evidently not searching quite correctly. I think I know why, but do you thing you could find the registry entries for me and export them please? To do this, run Regedit (from the START button), and, in the explorer window part on the left, drill down to select the entry Computer\HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_16C0&PID_27CB then, with that selected, go to the File menu, select Export, set a filename, eg DTArotary and press Save. It will save as a .reg file. Then just close Regedit (you won't have changed anything), rename the .reg file as a .txt file instead, and paste it here -- it won't be too long. I can then copy it, rename it back to .reg, and import that data into my registry and use it to work things out. Thanks! Pete

Yes! Excellent test of my changes! Thank you. It is late here now, so i'll analyse these results tomorrow. i'm sure there must be enough information there for me to work out what is wrong! Pete

Well, I'll take another look and let you know. If I see a way I'd need you to test it for me. Pete

After the previous attempt proved to be a failure on Windows 10, though running perfectly and efficiently on Windows 7, I have worked out a different method of checking on Joystick Devices, GUIDs and Joystick IDs. This one uses nothing in Windows that wasn't used before, so it should be fine. It involves doing two passes through the DirectInput entries in the Registry, once to locate and record known devices (i.e. those already identified in the FSUIPC4 settings) and a second pass to add any new ones. In both cases, omitted Joystick IDs, or IDs differing from the last time FSUIPC was run, are corrected. This is safe because the device is uniquely identified by its GUID, not its ID. This corrective action would mean that even users who are not using JoyLetters should still have all the correct assignments after joystick IDs somehow become changed. I would appreciate this being tested on systems with more than just the two joystick devices I can muster, and also on Windows 10 or even 8. Before testing please add LogExtras=x200000 Debug=Please to the [General] section of the FSUIPC4.INI file, and supply both Log and INI files for me to check through after a test run, whether successful or not. Save your current FSUIPC4.DLL and FSUIPC4.INI to restore shoud you run into a problem. Please download FSUIPC4964f TEST for the test DLL, version 4.964f. Thank you! Pete Dowson

The settings in the [General] section are all related to initialisation of things done all the time in FSUIPC, and can only be changed when FSUIPC (and therefore FS) is not running. All assignments, profiles and so on, can be modified in the INI file whilst FS is running, but you need to get them re-read, by using the Reload buttons -- there's one for each assignments type -- Buttons, Axes, Keys and Calibrations. For Profile changes you'd need to change aircraft to make it re-read the profile lists. Lua plug-ins can also be added into the Modules list and recognised on the next Reload press. The plug-ins themselves can be edited but if already running they would need "killing" and restarting before such changes took effect. The only other part re-read whilst FS is running is the Traffic Limiter parameters section, which simply needs an entry into and an OK out of, the options dialogue. Pete

Well, FSUIPC would change them itself, so they must have been ones you changed to suit the helicopter. Maybe at the time you hadn't defined or enabled the profile separately for it? Well, in that case, they weren't FSUIPC settings at all, because the INI file contains ALL of your settings -- unless you have st "UseProfiles=Files" so your profile settings are in separate files in the Profiles subfolder -- but I see you have not done that in any case. Therefore ALL of your settings are held in that one file, no where else, and unless you changed them nothing else should. It sounds more likely that you have controllers still also enabled in P3D and these are interfering. Either that, or something is being loaded by your Helicopter add-on which is still running and interfering even after you change aircarft. Is that possible? Does it install its own DLL or have some EXE or Lua plug-in running as well as the normal aircraft Gauges etc? The fact you fixed things by uninstalling it does suggest as much. Yes, they are ALL there, no where else. There is absolutely no way FSUIPC would know any different from what it sees in that when it loads. Since you don't say anything specific about what actually changed I cannot advise any further. Incidentally, you should always check that you are using an up to date and supported version of FSUIPC before coming here for support. You are on 4.961. the current supported version is 4.964. Please update before returning. Pete