Pete Dowson

The name "mouse macro" refers to a way of getting a switch to work with a button or keypress when otherwise it can only be operated by Mouse clicks. It is done by FSUIPC actually hooking into the gauge code and simulating the effect of the mouse click by using a direct call into the code. There's no "performance" measure associated with it as it is a mechanism, not a process. Lua is the language used to write "plug-in" programs, ones which run in parallel with FS and which can do many different things, as needed, including, if you like executing mouse Macros. They are not alternatives. When you need to use a mouse macro, because that's the only way of operating a cockpit switch, then you need to use it because there's no other way. Whether you assign it directly, on its own, to a single button or keypress or use it withing a Lua program along with other things depends on the complexity of what you want to do, not on the particular switch(es) affected. The performance overhead of a plug-in depends entirely on what it does and how it is written, like any other program. Regards Pete

On FS9! So it isn't just a GFDevFSX.EXE problem? I don't seem to get any problems with the FS9 stuff. I have a GF46. I've asked Doyle, the author of both GFDev.DLL (which FSUIPC uses) and all the FS modules and drivers for GF modules, to help here, because it is looking very much like some interaction between GFDev and the other modules. The only additions in FSUIPC have been minor, a few extra calls to GFDev to ascertain howw many of each unit there are and to register an interest in seeing if any disappear or join later. I sduspect it might be, but I think I need the author of the GF stuff to help out here. There's nothing FSUIPC does by itself, only requests to GF software, and if you aren't using FSUIPc GF assignments, then after the initialisatioin, there's nothing happening at all between FSUIPC and the GF modules that hasn't always been happening for years now. And what is controlling the flaps? Pete

Well, by altitude "number" I take it you mean the altitude in the units used by FS's autopilot, because their software seems to have adopted the same. Evidently S-A needs hardware AND software attachments which can provide that sort of sophistication. I really don't see how you can achieve it with buttons alone. You could do it with an little Lua plug-in. Have you looked at that possibility? Have you asked S-A folks, or on whatever forum they have? I really don't see why it should be that way it appears -- there must be many others with a similar problem, surely? Regards Pete

What was wrong with what I gave you above? You only had to plug your code in where it says so! What don't you understand? The code you needed was in my message. That would get pretty complicated unless you can be sure that you'd never use any two such buttons so close that the timings overlap. If you wanted it completely general it would be far easier to have a separate little Lua module for each button. FSUIPC allows up to 255 altogether. There might be a way of doing it using a different method, but it would take me a while to think it through. how many buttons are you thinking of using it for? Pete

Okay. I've got that one too anyway. My problem at present is that I cannot get GFDevFSX to work at all, in the first place, with or without FSUIPC. I think my SimConnect SP1 installation is messed up and it needs SP1, not SP2. I can't repair SimConnect on Win7 at all, it seems to be 100% resistant to any attempts, and I am not willing to do a complete rollback and reinstall on my development PC. So I may have to install stuff on a separate PC altogether and try there. It is odd that no one else has reported this problem. You'd think it would be serious enough for quite a clamour! Regards Pete

I'll make a note, but it isn't that easy the way my code is at present. Regards Pete

I haven't got time today to write it for you, but it goes roughly like this: function checkmystuff(off, val) -- Here do what you want with the offset and value -- you don't need to read the offset, the value is provided as the second parameter, i.e. val here -- no need to loop at all, you'll be called when the offset changes again end event.offset(0x66D1, "SD", "checkmystuff") You'd start this running somehow, either by Macro call in an ipcReady.lua file or by adding it to the [Auto] section in the INI file. Whatever you are doing to run yours. BTW, In your program you should put that "ipc.sleep(10) call in the outside loop, just before the last "end", else its only sleeping on that last "if" condition. Regards Pete

When do they light up again? Are you sure that's not just because your default FSX flight is with the battery or avionics off? If it's to do with the battery switch it may be improved and intended behaviour? Regards Pete

Have you tried using the real time monitoring facility in FSUIPC -- Logging page, right-hand side. You can have it displayed on screen. You can also log the values you are actually reading. Please use all of the tools available to you. I cannot really check anything specific for you here as you fail to mention either the version of FS (FS98, FS2000, FS2002, FS2004, FSX, ESP?) or the version of FSUIPC. Please always do so when asking questions here. I just monitored it (to screen and log) in FSX and whilst the screen value (which is in notmal decimal notation) gives 0.0000000 al the time, the log shows the value as being very very small but varying all the time. e.g. 114812 Monitor IPC:282C (FLT64) = -0.00000000 114843 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.69647758605e-102 114875 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.34402134588e-102 114906 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.10479821217e-102 114922 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.89314449366e-102 114953 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.70078123536e-102 114953 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 114984 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.58928557659e-102 115000 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.36379377683e-102 115031 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.23159794733e-102 115062 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.10387645598e-102 115078 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -9.94076290263e-103 115109 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -8.93950702964e-103 115140 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -8.35347267992e-103 115156 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -7.24917770797e-103 115187 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -6.51670197912e-103 115218 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -5.84784386968e-103 115234 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -5.26991772166e-103 115265 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -4.7416958265e-103 115297 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -4.43085132232e-103 115312 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -3.84305829e-103 115343 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -3.41260452911e-103 115375 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -3.0611114593e-103 115406 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.74609930905e-103 115422 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.47336096495e-103 115453 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.22501687082e-103 115484 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.99796020294e-103 115500 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.79736713248e-103 115531 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.61911870096e-103 115562 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.45325340041e-103 115578 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.31040643191e-103 115609 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.17862867593e-103 115640 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.05788793008e-103 115656 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -9.52334060589e-104 115687 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -8.58523123058e-104 115718 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -7.69889999722e-104 115734 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -6.9499395826e-104 115765 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -6.27398575577e-104 115797 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -5.62191823723e-104 115812 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -5.07740886428e-104 115843 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -4.50003090349e-104 115875 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -4.01542790053e-104 115906 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -3.60286102156e-104 115922 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -3.2508564805e-104 115953 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.90968344922e-104 115984 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.71893753421e-104 116000 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.35926418884e-104 116031 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -2.11734951373e-104 116062 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.90439518452e-104 116078 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.7182838351e-104 116109 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.53830613345e-104 116140 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.38796724539e-104 116156 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.24476623282e-104 116187 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.11413917894e-104 116218 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -1.00182469058e-104 116234 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -9.36149516419e-105 116265 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -8.13882435848e-105 116297 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -7.33030966981e-105 116312 SimRead: 282C="ELECTRICAL BATTERY LOAD" FLT64: -6.59119230004e-105 116343 SimRead: 282C="ELECTRICAL BATTERY LOAD" Maybe you are getting these values, which because of the exponent of -100 or more sre EXTREMELY small, almost zero, but you are converting them into print or display incorrectly? Regards Pete

Right, but it will be for others. I will try to reproduce the problem here. Hmm. I have 1.93.0.13. Maybe mine is a pre-release. I'll go get the one from their website. I would have thought, if you've updated to their latest, it would be later than 1.90. Just in case it is relevant, could you tell me what version of Windows you are using please? Also, when you said: The labels are just the ones on the left-hand side or top of the GF-45 and 46 aren't they? none on the 166? Apart from the labels, did the units appear to operate correctly, numbers and dials-wise? Thanks, Pete

Those are all concerned with things like water depth, water speed, and waypoints at sea. The only one of those supported by GPSout is VTG for ground speed and track. None of those sentences provide latitude, longitude or altitude, so useless for use in aviation. I think they are only designed to connect to additional equipment on a boat (depth gauge, sonar, water-driven transducers), with the GPS still receiving satellite positions for Latitude and Longitude. I'm pretty sure the others use Aviation protocol. Maybe it is not 4800 (that's only the default speed for NMEA). I seem to recall the others use 9600. Have you checked? I found this link on Google: http://www.baron58.com/gps_garmin_296.htm Yes, they are similar to those sent out by GPSout if you select the right sentences, and should drive a moving map perfectly well. You have some setting incorrect, probably port speed. Regards Pete

Yes. FSUIPC4 is a rewritten version, a different product. If your FSUIPC3 purchase was recent you might still get a discount from SimMarket. Regards Pete

What version is your GFDev.DLL module? You should find that in the same folder as your GFConfig program. Right click on it and check Properties-Version. Then check the Updates Announcement at the top of this Forum. There's a recent version there which certainly works fine here. But please first save your original, because if changing it does make a difference I'd like you to send me your old one to test here, as I'm not aware of any incompatibility I've introduced and would need to check it. If you are not assigning any GoFlight switches and things in FSUIPC you might also want to try the latest 4.58x version with the GFDev.DLL temporarily renamed or removed, so FSUIPC will not even try to access those modules. Finally, it might be worthwhile going to the GoFlight website and downloading and installing the latest possible release of drivers, in case it's some sort of GFDev / GFDevFSX incompatibility. I do hope you won't just give up on this as it is serious and I do need to resolve it. Thanks, Pete

Well it might not be the problem, but it certainly is a problem. Is the joystick number of your button connection the same on both PCs? It seems rather unlikely if there's also a Saitek device on the other. The joystick numbers are assigned by Windows and could be anything from 0 to 15, but generally the first seen will be 0, not 1 as you have there, presumably because on the other PC the Saitek is number 0? There are facilities in FSUIPC for using names rather than numbers, with letters inside FSUIPC instead of numbers, and that might work better for you, but you have to enable that facility -- it is covered quite comprehensively in the documentation. Have you bothered to compare the Joystick Number and Button Numbers at the top of that screen with those in your INI file and those on the other PC? Please ALWAYS state the exact version number of FSUIPC you are using when asking questions. If you are not using the latest you should look at the Updates Announcement above. Regards Pete

Yes. Several ways. The easiest is probably simply to assign the axis to the Lua program, like assigning any other "FS" control (the Lua controls are listed in the "Send to FS" drop down). The axis value is passed over as the "ipcPARAM" variable for use in that plug-in, as described in the short document "FSUIPC Lua Plug-Ins". That way is a little inefficient if the axis is frequently changing, as each time a new value is detected the same Lua plug-in is loaded, compiled and executed. For a parking brake axis this shouldn't be a real problem, though. Note that you can still get the control sent too (via dual assignment in the same place for an Axis or "Set" control, or via the right-hand assignments by range). Another way is to assign to one of the Offset controls (a separate option in the Axis Assignments tab), getting the axis value written to a user offset, one of those free for users in the range 66C0 to 66FF. You'd have a Lua plug-in already running, probably loaded via the [Auto] options, or by an ipc.macro call in ipcReady.lua. That plug-in could either sit forever in a loop, checking on the value in the chosen offset (and sleeping a lot), and taking the appropriate action, or you could instead be a bit more sophisticated and use the event.offset function to have any change to the chosen offset automatically call a Lua function in the same plug-in. No loops then -- FSUIPC keeps the plug-in in memory ready to call the listed event function.. If you use that latter way then the actual parking brake function itself would also best be performed by the plug-in. There are several other ways, variations on the above. Regards Pete

This is a contribution from user "ronzie". It may help if you try to install FSUIPC (or probably any other Add-On) and it says it cannot find your copy of FS. Thanks Ron! ------------------------------------ Free FS registry checker and repair utility Download from here: http://www.flight1.com/view.asp?page=library This file: FSX/FS9 Registry Repair Tool (36KB) to check and modify if needed. Be sure in VISTA and Win 7 to run it as an administrator. (right-click and "run as administrator") --------------------------------------

Actually that's a common issue with many USB devices, because to save on traffic they only send position data when it changes. It was different with the old Game Port devices because they had to be explicitly polled. It was such a common problem that in one update last year I dealt with it in FSUIPC assignments by deliberately discarding the first few readings I got from an axis, both at the startup and after changing anything or reloading settings in the FSUIPC options, and then waiting for a changed value. Unfortunately I cannot do that for axes assigned outside FSUIPC because it isn't my code reading them. And in any case all that means is nothing happens on an axis until you move it, so it isn't quite so different as what you now have to do, except it may avoid things zooming off in Slew mode if your FS is initialising into that mode. I didn't associate your problem with that common problem because you said it was only wonky after powering the PC down and up again. The usual problem occurs every time a fresh connection is made to a USB HID device. But maybe the drivers for yours are different. Maybe they keep a memory of things as long as power is available. Regards Pete

No. All the NMEA sentences it produces are fine, but Aviation 400 protocol does NOT use NMEA sentences at all. It is a completely separate aviation protocol, and selected separately in GPSout. We know from feedback here that it works fine with the Garmin 296 and others in the x96 range. I've not heard of or seen any feedback so far about a 495. If it says it supports Aviation protocol and is set to receive that, then the only things you need to get right in GPSout are COM port (or USB port), Speed ("baud rate") and the protocol selection. Do NOT select anything else with Aviation -- it is a free-standing protocol. I do not know of any Garmin units which accept NMEA input for GPS operation. They only use that for routing data. The reference you have for NMEA sentences is probably referring to the NMEA output you can get from the 495 -- it feeds moving map programs in the same way as GPSout does. Regards Pete

I don't understand why you could have such difficulties. Try first looking at the List of Contents on page 2 of the User Guide. About 2/3rds of the way down you wil see a section named "Joystick Calibration", which you'd surely find relevant (?), and it also gives the page number. Start there, on that specified page. After the introductory chat (which does contain important information, such as that which I've advised you here), there's a series of numbered steps. Follow them. It really isn't intended to be so obscure that you cannot find it. I thought by having page numbers and explicit section titles any one should be able to find things, at least if they've ever looked anything up in a book before. Can you explain why you found it so hard, please, and I'll see whether I can do better? Pete

I'm not aware of any problems with GoFlight operation in 4.57, but please try the current update, 4.583, available in the Updates announcement above. The GoFlight units I have work fine with that. Let me know, please. Regards Pete

It sounds like you have the sensitivity slider in FS set incorrectly. Go into the FS Options-Settings-Controls menu, seelct "simple controls" and adjust the two sliders. The null zone should normally be at minimum (left-most) and the sensitivity at maximum (right-most). The latter is especially important if you want to use the full range. A lower than full sensitivity actually reduces the values coming in from your joystick. The documentation for FSUIPC also advises the above FS settings first (unless you are assigning in FSUIPC instead of FS, which it doesn't sound like you are). Notwithstanding that, if you had calibrated the throttles in FSUIPC as documented then you would certainly have achieved the full FS range. The actual end effect then of a lower sensitivity is that you would have less positions on your throttle axis giving unique throttle settings, so even with FSUIPC you should use maximum FS sensitivity unless you assign in FSUIPC so bypassing those sliders. Regards Pete

If you mean the FSUIPC.INI file, then all you needed to do was to remove the lines in the [Programs] section which you had added. That is not actually possible -- maybe you are looking for a CFG file instead of an INI file? FSUIPC doesn't use a CFG file. Furthermore, if you delete it it will simply make another one, and if you delete it whilst FS is running then the one it creates will be the same as the one you deleted. In other words you must delete it after closing FS. It is quite likely that you have allowed FS9 to be installed in the "Program Files (x86)" folder, which is generally protected from users. Because FS9 is not "Vista aware", and Vista knows it, the installation process actually gets FS9 installed into aliassed folders. The ones you think you see in Explorer are not those being used. What you need to do to access those folders is to run Windows Explorer "as administrator". That is, find the explorer program, and right click on it as select "run as administrator". That will give it the elevated privileges it needs for you to see and access the real FS folders. FSUIPC.INI is always in the real FS modules folder, along with FSUIPC.DLL itself and the LOG file it always creates. If you used the FSUIPC installer you will also see the FSUIPC documentation and of course all of the other FS Modules. Regards Pete

Okay. What is happening here is that, because I calibrated the slew axis but not the equivalent elevator axis, and my null "centre" zone is actually well into the +ve side of the axis values (the device sits on the desk in a pitch up angle), a value FS has for the elevator is being seen initially when changing to Slew mode, and this is then calibrated into a -ve value, so it slews backwards. It does this every time I change into Slew mode with the device sitting on the desk. It is a direct result of the same axis being used for two different controls with two effectively different calibrations, and can be fixed by calibrating both the same. The reason that FS itself, without FSUIPC, doesn't have the same problem is exactly because it doesn't calibrate, it just uses the Windows calibrated values from the driver which are naturally the same no matter which FS control is assigned. I would certainly conclude that what I am seeing is not at all related to what you are seeing. So, sorry, I have no solution. It seems to be something outside of both FS and FSUIPC control. Regards Pete

The symptom of only having the two values, full on or full off, or full up and full down, or whatever, is usually one created by an axis operating in "digital" mode (on/off only) rather than analogue mode. Many toe brake setups are like this, for instance, and I think it is configurable on several makes of joystick and pedals. I haven't yet tried the heading slew here on FS9 (no normal joystick pedals), but I could try assigning the little throttle wheel to it I suppose. One other thought. If powering the PC off and on does it, but doesn't change the GUID and therefore FS's assignments and settings, the only other thing it could be down to is surely the power off and on of the joystick and/or its USB connection? So, does the same problem occur if, instead of powering the PC down and back, you simply power down your joystick and disconnect its USB connection, then connect it all back up again? If so it would be some sort of initialisation bug in the device or its driver. If it only occurs with the PC power cycling then there must be something odd happening in either the driver or the Logitech software which only occurs once. [LATER] Tested heading slew, and that's okay. But it isn't the FS control that has the problem, at least in my case. It is the axis input from the joystick. Only one of the two axes sends a spurious initial value. I logged the Axis controls (an FSUIPC logging facility -- see Logging tab) and got this: 31015 *** AXIS: Cntrl= 65869 (0x0001014d), Param= -2938 (0xfffff486) AXIS_SLEW_HEADING_SET 34312 *** AXIS: Cntrl= 65869 (0x0001014d), Param= 0 (0x00000000) AXIS_SLEW_HEADING_SET That's with my Elevator axis assigned to the heading slew. It settles to zero immediately I touch it. And if I assign the same axis to the Forward/Backward slew, the exact same incorrect value arrives for that. However, if I don't calibrate via FSUIPC, or remove FSUIPC altogether, that spurious value doesn't arrive. Which is puzzling me, so I am now going to delve into that. Perhaps you could try the same and let me know if your problem is the same thing. Regards Pete

You last post crossed with mine ... Yes, but if you are calibrating in FSUIPC, that's the whole purpose of the centre zone, the two values between which the output value is zero. By forcing that in FS you remove part of the original range of values available to you from the joystick. Likewise, an FS sensitivity of 50% merely causes FS to divide the value coming from the joystick by 2. Then FSUIPC calibration spreads the result back over the full range. In the end you are removing probably 75% of the stick's range of values and simply spreading the rest over the needed -16k to +16k range. With many modern digital joysticks you might just get 500 or even 1000 values, if you are lucky. If they are based on ordinary potentiometers you'd be very lucky to get 200, and most only give about 40-100 values. Remove 75% of those and there might be only 10-20 different positions on the joystick which are effective. Regards Pete