Pete Dowson

Okay, good. Thanks for letting me know. I'd never have thought that error would have had such serious consequences. I use GPSout a lot here and had no trouble -- I only found out about it when my COM port got changed and the result was the FSX crash on termination. 4.402 has some partially implemented future facilities so I don't want to make even an announced interim release yet. In fact I'm already up to 4.403. Please, do look out for an proper interim version in the Announcements above and replace your 4.402 when I've put one there. Maybe next week. Regards Pete

Two things there, to start with: 1. Why separate ALT and the A? It would probably work better if you did combine them. That's the way menus work anyway -- the alt then A method is merely a friendly alternative, because the ALT key brings up the menu. 2. To go further, with subselection in the menu, is actually quite difficult, as it is timing-related. Once the ALT key is actioned and the Menu takes the focus, more keypresses addressed to the normal FS window will not be seen. All the keypresses need to be in the "buffer" at the time the focus changes. Unless you are careful this can be a little bit of "pot luck". It seems to work reasonably well if all of the keys are pressed from one button operation (i.e. editing the FSUIPC INI file so that several keypresses are assigned in the correct sequence, to one button). A macro to do the same might also work. This is because FSUIPC is holding the processor whilst it is processing these things. Ah, you are trying to do it by program? Hmm. Let's see: static unsigned long result; int control =1070,code; code = 17; // FSUIPC_Write(0x3110, 4, &control, &result); FSUIPC_Write(0x3114, 2, &code, &result); Big error there! Please refer to the documentation for offset 3110. It clearly tells you that you must write all 8 bytes in one Write. But you have split it! It says "FSUIPC will fire the control when you write to 3110". Did you not see that? You might get away with writing 3114 first then 3110, but really you should declare the 8 bytes as an array of 2 ints or DWORDS, set both values, then write 8 bytes. FSUIPC_Process(&result); Ouch. You try to send just the ALT in one process call? So you cause Windows to switch between you and FS and then back to you? By then surely the focus will change and any more keys sent will be wasted (or worse, saved up and used when you exit the menu). Why are you interspersing each request with a Process call? ALWAYS bunch ALLL read and write requests you want to do in one Process call. it is EXTREMELY inefficient to have lots of little process switches like this. Finally, where do you get those numbers: code = 17; // code = 28;// code = 77; // What list are you finding such weird numbers in? In the lists I publish A is 65 (there's no 28 listed), and P is 80. Your 77 would be M. Please tell me where you are getting your numbers from. Are you simply inventing them yourself? :-( Keycodes are the codes Windows uses to identify the keys. For alphanumerics they tend to be partly equivalent to ASCII, but you should certainly not take that for granted. There are no ASCII definitions for many keys in any case. Take a look at your keyboard sometime! F1 to F12 don't figure in ASCII, nor do any of the cursor and editing keys, except maybe Return, Tab and Backspace. Regards Pete

Oh dear. You have Windows suppressing the filenames of known file types! Ugh! The "FSUIPC Install" file will be a Log file (real name "FSUIPC4 Install.log"). One of the "FSUIPC4" files will be "FSUIPC4.INI" -- the generated configuration settings, proving FSUIPC4 has been run, and the other will be "FSUIPC4.LOG". Paste both log files here, as I asked, and we will take it from there. So far it looks as if things are working, so you should get the Add-Ons menu, which is produced by SimConnect, but we shall see when there are details to check! Incidentally, it looks as if you are out of date with the version of FSUIPC4 you have installed. The current version (4.40) installs more files than that. Regards Pete

Hmm. In case it is that GPSout problem I fixed, please do try my as-yet unreleased interim version, 4.402, and let me know. Here's the link: http://fsuipc.simflight.com/beta/FSUIPC4402.zip Thanks, Pete

No, there's no such library. Someone may be able to help out, but i don't think you'll find your problems relate to FSUIPC in any case. Have you got no better identification other than "a program"? That's not actually been changed, though I have found a long-standing oddity with GPSout which I've fixed in an internal version since 4.40. It only occurs if you have set it to operate via a serial or USB port but for some reason it cannot open it. It still starts the GPSout thread, but doesn't flag this as running, so when you terminate FSX that thread is left running and then crashes. You don't get a tidy finish. It does no harm other than this, though of course it is annoying because FSX then doesn't get to save any CFG file changes (it only does so on correct termination), but, again, it only occurs when you tell GPSout to operate on a COM or USB port it cannot open. And it is a long-standing error. What GPSout problems, specifically? Regards Pete

Neither. Virtual buttons aren't real buttons, that's the point. It is a PROGRAM which must set or clear the bits, pretending to be a button. Surely a real MCP has real buttons, not virtual ones? Why are you interested in imaginary buttons? Real joystick buttons should be detectable via Windows joystick system. If you've made your own MCP and added buttons to it, how are you connecting them to the PC? Isn't this via some interface board which in turn produces Windows-recognisable button or keypress values? Please explain what it is you really want to do and I'll try to help. Regards Pete

The antivirus section won't be doing anything to WideFS, but you need to check the firewall. If your router supplies decent firewall protection from the outside world I don't see why you need firewalls enabled BETWEEN your PCs in any case. I hate my systems stopping me doing what I want with them -- it isn't as if anyone else has access to them. Normally your router won't have anything to do with your local connection. For them it is only acting as a switch or hub, surely? If it is doing some IP address translation even on the local network that could certainly mess things up, but it doesn't look like it from the logs. The logs simply show that, whilst the Server can see stuff coming from the Client, nothing it sends is getting though. It is all being stopped. Since the Server is running XP and the client Vista it does look very much like a Vista safeguard, a firewall setting. Regards Pete

No, it is never okay. No data ever reaches the client from WideFS. Your client PC is blocking everything the Server tries to send. Probably the firewall. Have you checked? Don't forget Vista's firewall is active against all incoming data by default. You have to either disable it or allow Port 8002 to operate. Regards Pete

Probably, but I need more information. Is there a Modules folder in the FSX main folder? If so, find the Log files, which will tell us what is going on. There should be at least an Install log, and maybe also an FSUIPC4.Log -- the latter file is only produced if FSUIPC4 is actually loaded and run by FSX. Paste both of these files in a message here. If there's no Modules folder then the install failed. Please run the Installer again and save the log file (use the File menu on the displayed log, behind the message box you might get). Then paste that here. If you are getting an error message when running the Installer, tell me what it says. Regards Pete

Not easily. You could consider doing it using a Lua plugin, assigning the axis not to a throttle but to a Lua control (with the axis value as the parameter), then, in the Lua plugin manipulating the value and sending out the appropriate controls. However, to avoid having FSUIPC reload and reinterpret the Lua source each time the axis changes (which could affect the responsiveness or latency) you might need to look at using the Lua Event library instead. Maybe program the axis to change a user FSUIPC offset and have an offset change event process the value. FSUIPC will load the plugin automatically if you name it "ipcReady.lua". Regards Pete

I expect your controls are plugged into different USB ports, or Windows has simply decided to renumber them for some other reason. No. Unfortunately the way in which Windows assigns ID numbers to different USB-connected devices is, er, rather obscure. If you reinstall Windows or change your machine it is quite likely that the joystick numbers (not the button or axis identities themselves) change. I have exactly the same problem with the COMx port number for my USB-to-Serial adapter on my PFC controls. If I make a change somewhere to the hardware, Windows decides to reassign the COM port numbers. Had me puzzled for a while. I know it happens if you move your devices around to different USB sockets, but I really expected them to stay the same when they weren't even disconnected! You have some choices here, one of these three: !. Probably the best if you can do it, try to find the plug-in arrangement for your devices which gives the same joystick numbers as before. Then everything should work, as before. 2. Find the new joystick numbers, compared to the old, and edit them all in the FSUIPC INI file. This affects all of the Axes and Buttons sections. 3. Delete the whole set of Axes and Buttons sections in FSUIPC INI and start assigning again. (Ugh?) For the first two, if you want me to identify the original joystick numbers for different axes please paste the [Axes] section of your INI file here. For the current joystick numbers just go into Axes or Button assignments and see what numbers you get for Joy# for each device. If this sort of thing happened a lot I would consider adding a translation table section to the INI file, so, once you found which was what you could say "joystick 1 is really 3", etc, and have FSUIPC simply automatically convert internally. However, this only solves the editing problem, not the real one, that of identifying what is where. FS itself uses DirectInput and identifies devices by name and a strange concoction of digits representing manufacturers and models. It is complex and involves a load of stuff in the Registry. Before FS used DirectInput it had similar problems with assignments when you moved stuff about (or Windows did it for you). The original joystick interface which FSUIPC still uses is remarkably simple and efficient and I'd really rather not change to DirectInput for those reasons. Regards Pete

Apart from the exact little changes in wind speeds and directions, and wind layering at different levels, which will never be exactly the same as real world even with real weather downloads, the biggest variable is your routing and speed and climb/cruise/descent/approach legs compared to the real world flights. Not to mention what air traffic control might do to it all! I doubt if any two real world flights have exactly the same real flight time due to all these small and large variations. No. All it does is correct for FS's tendency to allow its clock to run at a different speed to your PC's system clock. I think it's normally only a matter of some seconds per hour. Negligible compared to all the other variables I mentioned. Regards Pete

You are!! :D :D :D I mean, your FSUIPC is No, it can't. There are no facilities in FSUIPC to write to any external displays. It has to be done by another program. Maybe you are using my little GFdisplay program? Regards Pete

Who or what is updating the values in the GoFlight display? Have you perhaps only programmed the "press" of the respective buttons and not also the "release"? Most of those types of rotary controller click for every change, but what is actually happening is that each click either makes the contact (like pressing a button) or disconnects the contact (like releasing the button), alternately. If you've only programmed the "press" action, the updates in FS will be half of those the unit itself presumably ses (assuming it is maintaining its own values?). Regards Pete

Sounds like one of the video driver problems I've seen reported. You really need to get the driver replaced. Maybe an older one or a later one. Make sure it is Vista compatible of course. You may be able to get around it by switching to normal Windowed mode instead of full screen. Most of these problems with video drivers only happen in full screen mode. Regards Pete

You must be using an out-of-date version of FSUIPC, or at least you missed the changes recently. There's an INI file option to lock the TCAS settings the way you like or need them. No, I'm afraid there's no way to do that. Sorry. you just have to choose, then lock. Regards Pete

It's okay, you haven't. After the requests recently I added it to my list in any case. But you can already accomplish the same thing in the way I said. I'll simply making it more obvious (less confusing perhaps) with a specific option. Yes, but I always thought homebuilt ones would use two pots, in series, one for the thruster the other for the reverser, and the calibration then works really well -- FS sees one axis, but you calibrate max reverse to idle on the reverser and idle to max thrust on the thruster. Regards Pete

Odd, this. The whole reason FSUIPC ever offered the separate throttle axis calibrations was because most folks wanted to be able to put a reverse zone on the levers. That has lasted nearly 10 years. Now all of a sudden folks want to use this facility without that option. I assume this is down to the two or three throttle quadrant manufacturers who have decided, in their wisdom, to put a switch at the base of the lever? Anyway, because several folks have asked this same thing, all in the space of the last two or three weeks, I am adding such an option. I suppose i should do it for Prop Pitch and mixture too:-( At present the way to do it is to make the lower end of your Idle zone the same as the minimum/reverse thrust position. That works. A lot of folks are using that method. It simply isn't intuitive because the facility is not designed (or documented) that way. Else wait for the next interim update, which will be made available in the Downloads announcements above. Regards Pete

Similar to my arrangements. I use Vists64 on the FSX PC with all the clients running XP32. WideFs needs no shared folders itself. Maybe some of the applications using it do. Er, there's a contradiction there. Simconnect is working okay, but it isn't? Did you mean WideFS for the second? PM filecheck reports are no use to me. they are for PM support. I only need to see WideServer and WideClient logs. ;-) Not that it affects this, by FSUIPC 4.333 was the last interim Beta version. FSUIPC 4.40 was released last week. The Server log file is okay. Looking at the Client log: I assume the Server's IP address it received from Windows (10.0.0.2) is correct? You've not assigned Port 8002 for use by SimConnect at all, have you? Check the SimConnect.XML file on the Server. Are you using any SimConnect clients on the XP machine? If not, then maybe it is your firewall preventing things. Have you tried disabling it, temporarily, to check? It might need doing both ends. Isn't Avast just a virus protection program? If so that should be irrelevant. It's the firewall protection which is more likely to be blocking things. You would need to enable Port 8002 on the Server -- the broadcasts on port 9002 seem to be okay going the other way (to the client). Regards Pete

They must be referring to the "Mouse Macro" facility. Read about it in the section by that name in the latest documentation (for FSUIPC 4.40 or 3.85). Pete

Those add-on aircraft which use FSUIPC often have their own offsets which I assign to them on request, but how they then use them is their business. Project Magenta openly publish their offset usage so every user can interface stuff to it. So does FlightDeckSoftware. The FS9 Level-D 767 usage is published in an SDK I think, and Nico Kaan has written interface software for them. The FS9 PMDG range uses FSUIPC offsets but they are kept confidential and you have to negotiate with them for support of specific hardware. I don't think it comes cheap. As for all of the others, some may use FSUIPC, some not. On FSX not many do as they can interface to FS using SimConnect. Of course, most add-on aircraft do not extend the subsystems beyond what FS offers in any case, so for those the existing FSUIPC offsets, and, in fact, the FS and FSUIPC assignable controls, normally do everything you might need. I think you misunderstand. "Mapping" is the job FSUIPC does in relating older (FS98) GLOBALS.DLL internal FS values ("offsets") to the same values in later versions of FS, to provide compatibility for add-ons. That's been added to with more data as FS develops, but there's no way I am going to buy every add-on aircraft there is, and hack into it with disassemblers and debuggers to see if I can ferret out where they keep things and find ways of fiddling them. In fact it isn't feasible nor right for me to do it even for one. For any add-on aircraft you are considering using when building a cockpit you will have to investigate the possibilities specifically for that aircraft, via the makers or their documents. Personally I tend to use only the visual models and air files I like, and have all of the subsystems and controls added by the likes of Project Magenta or FlightDeckSoftware. i.e. No FS panels nor gauges. Regards Pete

Yes, several ways. For up to 4 values you can use the Monitor option, on the right-hand side of the Logging page. That is fully described in the Advanced User's document. You can display it in real-time on screen. For any and all values you can use FSInterrogate2, supplied with full documentation as part of the FSUIPC SDK. Finally, you can use the Lua plug-in facility to monitor values in real time to the screen, save to a file, send over a link, whatever. There are examples of values displayed on screen ("display vals.lua") and recording to a file supplied in the Lua package with FSUIPC. Well the Logging and FSInterrogate options work anyway. The Lua plug-ins, which are extremely useful for trying out ideas as well as making little solutions, need a registered copy. Regards Pete

It's actually on the Saitek support forum, where Steve posted the same question. Check here: http://www.saitekforum.com/showthread.php?t=15568 Regards Pete

Yes, that is what i suggested. WideFS is way over the top in any case for merely communicating button presses. Regards Pete

Okay, thanks. Let's put it behind us. I'd still like to get to the bottom of the problems you've been having, though. They aren't common. As far as I understand, and assuming there's no problems with the actual Saitek driver installation (which is a worry because I have seen it be wrong), the only slightly peculiar thing here compared with the way FSUIPC was designed to handle separate throttles is the fact that you don't want the reverers operating from them. Whilst that shouldn't be a problem, by making one end of the idle zone the same as the Max reverse position, I can see that if this is likely to be a common requirement (which it really hasn't in the past) it might be easier for everyone to either have another complete set of 4 throttles which don't have reverse, or (and probably less work for me) another of those horrible button or checkbox options to set "no reverse zone". I am looking at doing this in the near future. This, however, still doesn't explain the problems you seem to have got into, and I'd like to understand those. Maybe, if you still have the FSUIPC.INI file which is giving you the headache I can take a look. I don't have Saitek gear, but I can certainly try things with your settings on the el cheapo game pad i normally do testing with. Please, ZIP your FSUIPC.INI (assuming it isn't already gone) and send to petedowson@btconnect.com. I'd also apprecate, with it please, a few notes about what you see going wrong with it. Regards Pete