Pete Dowson

Hm. Using the mouse or keyboard? Couldn't he use the menus then, without your program's assistance? One way of allowing him to use your program without leaving FS (or its focus) would be to use the FSUIPC application hot key or hot button facility. SetFocus API? Regards Pete

I did send an answer straight away. I don't know what happened to it! :-( For USB don't you have to write a HID program, interfacing to Windows HID API to access the USB device? And don't you need licensed device and manufacture IDs from Microsoft? If you can do all that, how come you don't understand how to change a bit in an FSUIPC offset? I'm really puzzled. You seem to be tackling a really complex job! Yes, and there are examples for the FSUIPC interface for Visual Basic in the FSUIPC SDK. Sorry if I am misunderstanding you again, but what have macros to do with it? Surely your first job is to manage to get information from your device, via USB, to your Visual Basic program. I wouldn't even know how to start doing that. Once you've done that hard part, interfacing to FSUIPC is easy. Haven't you downloaded the FSUIPC SDK yet? Macros are nothing to do with any of this. Regards Pete

No. They don't use FSUIPC at all and are therefore not candidates for interfacing to WideFS either. In fact I'm reasonably sure that the RealityXP panel products are effectively FS gauges and must be run as part of FS just like any other parts of FS panels. If you want it on a separate monitor you would have to have another monitor on the same PC as FS, then undock the gauge and drag it over. Pete

You've got something wrong, then if nothing at all happens. It should at least call up the Menu bar. Hmmm. Don't know. Maybe. FSUIPC certainly expects FS to have focus. Why has your application got the focus? Try letting FS have the focus. There's no sound from FS if you take its focus away in any case. Focus only affects keypresses in any case (and sound, but that's only because FS deliberately cuts off the sound on loss of focus). Pete

I very much doubt that it is "too fast", because all that will happen is that the keypresses will go into the queue. I've certainly had consistent success getting the FSUIPC dialogue displayed by having a button defined with ALT m f (or ALT d f for FSX), but possibly going any deeper than one level from the main menu may be impossible. What exactly happens with your sequence? Does it get no where at all? Pete

Er, sorry. You've lost me. I think you are still misunderstanding some fundamentals. NOTHING is sent to FSUIPC until you do the "Process" call. All the Read and Write calls do is queue up your requests inside your own program, ready to be sent. When the Process call is issued, all of your queued requests are sent to FSUIPC. There they are processed strictly in the order you made them! So, in your program the Write to 3114 gets done BEFORE the write to 3110. Don't you see it would make a mockery of things if FSUIPC jumbled up everything and wrote stuff in any old order? It has to do it as you ask! Oh, you mean the SCAN codes? Why would you use those? Why not simply use the lists I provide in the documentation -- in the very same document you found the "1070" control number, for instance? It is only coincidence that those are ASCII. Do not rely on it. Always look the codes up in the list provided. If you are using a Windows compiler for your program, the key codes will all be defined for you with names, in any case. In C/C++ they are defined with "VK_" prefixes, for "Virtual Key". That looks more likely to work, though I'm still a little worried that the focus will switch to the Menu before the whole sequence is done. You'll just have to try it. Yes, of course. But as I said, and as the documentation clearly says, "FSUIPC will fire the control when you write to 3110". Since it does your Writes strictly in the order you list them, it doesn't matter that the values are then overwritten again, does it? Regards Pete

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