Pete Dowson

Not joysticks as a whole, no. FS normally does that itself for the FS autothrottle, so I assume you mean for some add-on which has its own autothrottle control? FSUIPC will only send throttle changes on to FS is they change, so the secret, with an otherwise jittery throttle axis, is to park it someplace where there are no input changes-- like in your null zone at idle, or beyond the top calibrated max thrust position. Anyway, have you tried the Throttles Off Throttles On Throttles toggle controls available in the FSUIPC assignment drop downs for buttons or keys? Regards Pete

Looks like your FSX installation is screwed up. Error 0x80004005 denotes "Access is denied". It looks like your FSX main installation is up to date at SP2 level but your SimConnect installation is screwed up with only the SP1 version visible and FSX not allowing access to that. The FSUIPC4 install log would show more information about what is going on. Try installing or reinstalling the SP2 or Acceleration update as Jim suggests. If that doesn't work I'm afraid it gets a whole lot more complicated and maybe a complete uninstall and reinstall job. Regards Pete

The installer installs it and runs it if it is needed, then deletes it. see the Install Log. Pete

No, not the wrong tree. It sounds like a plan. There are really only two ways with momentary buttons instead of a selector switch: 1. The way you suggest, using flags. You would need two flags: Button A: --- sets flag 1 --- clears flag 2 Button B --- sets flag 2 --- clears flag 1 Button C --- clears flag 1 --- clears flag 2 Then the rotary action would --- condition flag1 set .... do action A --- condition flag1 set .... do action B --- condition neither flag1 now flag2 set .... do action C You could of course use 3 flags, but that's probably more lines than the above. 2. You could have each momentary button write a value to a user offset, like 66C0 (66C0-66FF are freely available). Use the offset byte set control to write 1, 2 or 3 respectively, and then for the rotary make the condition based on Byte offset 66C0=1, 2 or 3 respectively. This is probably more efficient, and it is expandable to almost any number of functions. Regards Pete

As well as what Jim said, please tell me what you mean by " wont allow me to click the dialogue box within FS9". Do you mean there's no Modules - FSUIPC selection, or that the dialogue which appears then hangs, or what, exactly? Pete

SP2 of what? FSX? There's absolutely no difference in my PFC drivers for any version of FSX. The version of FSX makes no difference at all. I assume that somehow your COM port number has changed. Maybe you reconnected it or upgraded Windows? I can't help you with that. How did you determine the original COM port to use? Just find the right port and tell the driver. BTW, PFC do have their own support you know! I can't really support hardware at all. Regards Pete

What do you mean "second set of joysticks"? There appear to be 4 distinct joystick connections, and thast's all that are listed. The GUID's are Windows' way of identifying them uniquely. FSUIPC uses them to resolve identical devices -- for instance if you had two TQ6's connected, they'd both be called "GoFlight GF-TQ6 Throttle System" but they'd always have different assigned GUIDs. This ensures FSUIPC can track them if you plug them in differently so they get different IDs. Though it cannot auto-reassign unless you change to using joystick lettering. It is all explained in the section of the User Guide called Keeping track of multiple control devices ("Joy Letters") Regards Pete

Can you show some examples of the names, then, please? Because there's no way FSUIPC is going to actually understand names, all it does is compare characters. If the substring you choose in the INI file matches anywhere in the aircraft name, it will work. It cannot "not work", if you see what I mean, it is so simple. Oh, it might also be a good idea to paste in a typical [buttons. ...] section from the INI file that you've renamed to match the short name you've chosen. Pete

It's the [WideServer] section of the FSUIP4.INI file, as clearly stated just after the Heading in the wideFS technical document: Well, generally is is better to limit the frame rate in FSX to a reasonable level. Regards Pete

Sorry, I really know little about C++ ("thiscall"is associated with C++ classes I think?), and absolutely nothing at all about MFC. I am basically an Assembly or Machine language programmer by training and have studiously avoided getting so far from the machinery! ;-) You have all the source code for the interface so you should be able to work out what is wrong. Don't forget it is C, not C++, though i expect you could change that readily enough. You could even build in the equivalent code directly into your program, not using a LIB connection, if you wished. FS does not, however, and so neither does FSUIPC, so in all strings being passed through you need to convert to and from an ASCII based character system. Regards Pete

If it thinks you are still not registered it probably means the Installer has fallen foul of some recent changes in security in Windows. Download the latest FSUIPC.DLL update from Download Links subforum and put it into the FS Modules folder. That should do the trick. I'll be revising the Installer as soon as I've figured out what Microsoft's done. Regards Pete

The options dialogue is a standard windows dialogue. The phenomenon of the screen blanking is always a video driver problem, where it isn't correctly handling FS's full screen mode. It it likely that the dialogue is in fact drawn behind the black FS screen, on the Windows desktop. When you installed Windows 7 did you accept the drivers it installed, or did you go to nVidia or AMD and download the proper Win7 drivers for your video card? If you did'nt do the latter I'd strongly suggest you do so now. Otherwise, your only option is to switch FS to windowed mode first -- ALT + ENTER. i can't support Saitek goods. I suggest you ask them. Regards Pete

"Beeping" only occurs when you try to set lower numbers above higher ones, or vice versa. The numbers in calibration must go from low to high, left to right -- also bearing in mind that negative numbers are lower than positive ones. You are probably getting confused by your left/right turning action on the aileron, which is not the same thing. FSUIPC's calibration is always numerical -- that's why it is also precise. Pete

Okay. Two WP-6's arrived here, courtesy of GoFlight (thanks GF!), and I've got everything working correctly now, according to all my tests. The working gfd library is included in the new versions just released -- FSUIPC 4.719, FSUIPC 3.997k and WideClient 6.899. Please visit the Download Links subforum for these. The Lua plug-ins package with documentation is also updated (see its own thread in that subforum). You'll find a little demo/test in the example plug-ins called WP6test.lua. Regards Pete

No, it does not matter. FSUIPC knows where FSX is because it is itself loaded from withing the Modules folder in that path. The parameters look okay. The option won't delete previously saved ones, from before you added these lines, and of course those lines won't be read until you next re-load FSX. So, start off by deleting all your unwanted files, then run FSX. If you've done this, can you show me the complete filename of one or two of the accumulating files, please? Pete

This is because AutoSave does not know that the Concorde add-on is also saving such files. You have to tell it. Yes, of course. It seems you missed this paragraph at the end of the Autosave section of the FSUIPC4 User Guide: Regards Pete

It's "ShortAircraftNameOk=substring", and it is not at all related to WHAT you assign buttons, keys and axes to do, but simply places those assignments in the INI file section relevant to the current aircraft. Buttons assigned to operate a macro are no different to any other button assignments in that regard, they are just represented by a line in the INI file, in a [buttons ...] section with the appropriate Profile or short Aircraft name appended. Since you can assign Buttons, Axes or Keypresses to macros, just as to FS controls and FSUIPC added controls and Lua plug-ins, it would not be explicitly stated. It is the assignment which is aircraft or profile specific, not the sort of action it carries out. As with all assignments, no matter what to do, if you make those assignments with the appropriate aircraft loaded and with the "Aircraft Specific" or "Profile" mode enabled (the aircraft short name will be shown in the dialogue title), then, as with all other assignments, they will be profile specific. It makes no difference whatsoever whether you assign to macros, Lua plug-ins or controls. Pete

They both either don't loop at all because the condition is not true, or they loop forever because nothing inside the loops changes anything you are testing. When there's no code in a loop, nothing happens. You'd have to reread the offset on every loop execution to see if it had changed. Once you copied a value into a variable, like RTF and MENUPAUSE, it stays in that variable until you put some other value into it. If it changed on its own, spontaneously, it would be no good if you needed to do computations on it, would it? Think about it as if you were reading the airspeed, say, or the aircraft position? How would you ever be able to use it more than once if it changed without you re-reading it? Also, having a loop within a loop just to test two conditions is very wasteful. You should test them both together. So you could do something like: while (ipc.readUB("3364") ~= 0) or (ipc.readUB("3365") ~= 0) do end As in English, "or" means one or the other. The other condition joiner is "and" meand both one and the other. Notice I've changed the tests to ~= 0 (not equal zero) rather than greater than zero, because it is more logical when that is what you really mean. I know it males no difference here, but one day it will. However, because this is going round the loop reading those offsets as fast as possible (at least 1000 times per second), you will be clobbering performance and virtually killing FSUIPC with such a loop. So, in any such loops, always include a "sleep": while (ipc.readUB("3364") ~= 0) or (ipc.readUB("3365") ~= 0) do ipc.sleep(500) end That sleep will make it check every half second = (500 milliseconds), which should be fast enough? The other thing you should notice is that the two bytes you are testing ate next to each other -- 3364 and 3365, so you would be better reading them as one 2-byte (16-bit) Word, ending up with: while ipc.readUW("3364") ~= 0 do ipc.sleep(500) end I can't help with this because there's no information provided. Sorry. Pete

Just to correct what must be a typo, 0x30 = 3 x 16 = 48, not 42 (4*8 + 16 = 32 + 16 = 48). Regards Pete

The error in line 24 is that your are definining a function, CHKPWRSWT, with constants (the numbers GFT8 and 1) instead of parameter names to be replaced by the real values when it is called. The values of the parameters to a function are provided by the CALLER., you cannot pre-define them as fixed amounts in the definition. The normal purpose of a function is to operate on values it is called with. Your subsequent message said: Yes, the model and unit parameter names represent values which will be supplied to the function by whatever calls it -- in this case event.gfd(GFT8, 1,"CHKPWRSWT") -- Check All Power Switches which will obviously supply it with GFT8 and 1 as values "model" and "unit" respectively. It will do because you are only calling it with that one event, and you are explicitly using GFT8 and 1 internally to the function, ignoring any possibly supplied parameters. If you wanted to use the same function for multiple GoFlight units you'd need to replace all the explicit references in it by the parameter values, "model" and "unit". Then you could call it for any GFD event. It is better really to keep functions generalised so you can reuse them, but if it's a one-off throwaway it doesn't matter so much. However, bear it in mind for the future as you may want to expand your Lua usage one day! ;-) Regards Pete

You won't find the "spoofing" so easily. It isn't specifically a Lua facility, it's a programming facility documented only for FSUIPC4 in the FSUIPC SDK. You'll need to download that in any case, but just to get the details of the offsets which are only documented there. There is an example of this spoofing facility in the Lua plugins examples installed in a ZIP in your FSUIPC documents folder, in the FSX Modules folder. It is called "liar.lua". When that is run it fakes the readouts for a lot of FSX values. An example just for heading would be much simpler. You'd need to read the normal True heading, adjust it for magnetic variation (another offset), then send it back to FSUIPC using the "spoofing" offset, as seen near the end of that liar.lua program. I can help with the details when you get further. Note also that if you do use this method, EVERY program reading the true heading offset from FSUIPC will get the magnetic heading instead. Only the Lua program doing the spoofing can read the original. So before you begin you need to think whether there are any other FSUIPC-interfacing applications you are using which use the heading value. It's okay if they use SimConnect instead, FSUIPC doesn't alter the FS values, only its own offsets. Regards Pete

If the Flight Illusion driver is reading the offset for the True heading, that's what it gets. Can the driver be configured to read a different FSUIPC offset instead? If so it would be easy to make a little Lua plug-in which computes the magnetic heading and provides it via a spare user offset. Really, the driver is the place you need to address this problem. Don't the FI authors know this is a bug in their handling? Shouldn't they be asked to correct it? FSUIPC4 does actually provide a "spoofing" facility to make one offset look like another., which might do the job. It would need a rather complicated trick played via a Lua plug-in. But check the driver's facilities first, see if the offsets it reads from are configurable. Regards Pete

The usual reason the key is rejected is that you are making a mistake. All three parts -- name, email and key, MUST be entered EXACTLY. Use cut and paste to avoid mistakes. It is easy with the key to mix 2's and Z's, 0's and O's, and so on. With cut and paste you can't make such mistakes. This is why it is recommended in the installation guide. The second most popular reason from this problem is that you've ordered a key for FSUIPC4 but are using FSUIPC3, or vice versa. However I don't think this applies to you because I see your purchase for an FSUIPC4 key. I see there are plenty of chances for errors in the key entry though, between S's and 5's, O's and 0's and 1's and I's. I count 16 possible combinations if you are guessing! Oh, please also ensure you are using a current version -- 4.70 is the earliest supported version of FSUIPC4. Regards Pete

Still, it would be a darn sight shorter to just test each button separately using the gfd.TestButton function as I suggested. gfd.GetValues(GFT8,1) -- Get values of GFT8 Unit 1 if gfd.TestButton(7) then -- Switch 8 is ON ipc.writeSB("0bc8",1) else ipc.writeSB("0bc8",0) end -- et cetera for TestButton(6) down to (0). The TestButton function is surely made for doing exactly what you are doing? Regards Pete

Obviously that Lvar simply means the button is pressed. No, there is no way. Even with FS you can only tell if Mach or IAS is being used if FS autothrottle speed control is engaged. You cannot tell what the display shows -- that is local to the display and controlled by the C/O button only, not a switch. With aytothrottle engaged, use Mach hold or Speed hold variables to see which to display. Otherwise all you can do is swap them then you see the button pressed. Pete