Pete Dowson

Okay, thanksI think I can fix it now. It seems the joystick identity Registry Entries in Vista ARE the same as those in WinXP, except instead of being in HKEY_LOCAL_MACHINE they are in HKEY_CURRENT_USER. Here are the three from your Registry: [HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_045E&PID_003C\Calibration\0] "GUID"=hex:90,af,4f,0f,77,c6,db,11,80,01,44,45,53,54,00,00 "Joystick Id"=hex:00,00,00,00 [HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_0583&PID_2032\Calibration\0] "GUID"=hex:a0,7c,5e,0f,77,c6,db,11,80,04,44,45,53,54,00,00 "Joystick Id"=hex:01,00,00,00 [HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0107\Calibration\0] "GUID"=hex:e0,18,5f,0f,77,c6,db,11,80,05,44,45,53,54,00,00 "Joystick Id"=hex:02,00,00,00 Seems that Vista treats joystick connections as personal to the user, not as part of the PC's configuration. Understandable I suppose now that folks often disconnect and reconnect them. I will make the changes to FSUIPC4 and test them here. Look out for FSUIPC4 version 4.08 which I should be able to release either later today, or certainly before the weekend is out. Thanks for your help, Pete

The Registry extract you sent does contain the exact information I need -- seems there are 3 known joystick connections listed, IDs 0, 1 and 2, with your sideWinder at #0. My present problem looks to be that the HKEY_USERS section is user-dependent (surely the joysticks aren't?), and there's that weird semi-numerical string to find. In my WinXP Registry there are such weird strings in the HKEY_USERS section, but certainly nothing in the CurrentControlSet inside those relating to joysticks. It's very odd. I can see me poring over a hot registry all day tomorrow! :-( Regards Pete

What about WinXP's firewall? Is that enabled on the Server? This is simply saying that Wideclient is not allowed, by Windows, to see "SERVERPC". That PC is simply not visible to it. If the Network is otherwise working, it simply MUST be a firewall. I really cannot see any other alternative explanation. All the program can do is to try to connect to the Server. If Windows refuses to connect it, then all it can do is tell you what Windows says -- and that is "host not found". Sorryit MUST be a firewall as I cannot think of anything else it can be. If you are sure it isn't, I can only advise seeking help from a Windows Networking expert -- Try Katy Pluta over on the FS2004 Forum. Regards Pete

Is this with a Registered copy of FSUIPC4 still? There's a parameter in the INI file to disable FSUIPC4 axis interception, in case SimConnect isn't working correctly. For unregistered installs that is defaulted. If FSX doesn't work with its axis assignments (not FSUIPC4 axis assignments) then it is likely to be a Simconnect problem. We may need a Log. I need to find the entries giving the "GUID", as this is needed to actually select the device in DirectInput. I'll be able to check myself (but in the 32-bit version) tomorrow. See above about Simconnect. I'll check here in 32-bit first. Thanks. Okay, I'll look there. But I'm out tonight so I'll be looking at this in more detail tomorrow. Regards Pete

Do the axes respond in FSX? FSUIPC4 now uses the standard DirectInput facilities, same as FSX and FS2004, to read the axes. I have no idea why that should be different in a 64-bit system compared to a 32-bit one, unless the drivers are wrong -- but that should affect FSX as well. FSUIPC4 still uses the old Windows joystick API for the buttons. If that's working but the axes are not then it seems like the DirectInput (HID) driver for the joystick isn't correct. [LATER] On checking my code, I identify DirectInput joysticks by reading certain parts of the Registry. Perhaps you could look for me? First I look under this Key: HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_xxxx&PID_xxxx\Calibration\ where the two batches of 'xxxx' are values I get from the older Windows joystick API. Within this key I need the 'Joystick Id" 1 value for the GUID. The GUID uniquely identifies the device and then I can read its axes. I'm suspecting that the Registry structure has been changed. I'll finish installing my Vista 32-bit Ultimate and see if I can find out. Otherwise all I can think of doing it to revert back to the old Windows interface for Vista, losing two axes. Regards Pete

Thanks for this report. It isn't working correctly at all, but here it does affect latitude and longitude, except that West longitudes and South latitudes go wrong. I've fixed that for FSUIPC 4.08. The freeze facilities built into FSX should work okay. You can use those via the FSX controls provided (see list as well as FSUIPC4 drop downs). I'm changing my code to use these with effect from 4.08. Look out for the release this weekend or before. Regards Pete

but that unfortunatly not the case But it is the case, when the payload is changed in FS2004 dialogues. As documented for the payloads in the FSUIPC Offsets list, and quoted above, this is not so by directly writing to the internal values. In Fs2002 and before there was no payload facilities, hence the comments. In those days folks had to adjust payload by adjusting fuel load! Regards Pete

Where are the logs, please? I cannot help without information. Ah. If you are using a Router, then when you stop the automatic assignment of IP Addresses you also need to be sure that the router is assigned a compatible IP address and is defined in the "Gateway" section of the dialogue where you enter the IP addresses in Windows. How you reconfigure the router itself varies from make to make. Hardware and driver-wise, yes, but Explorer is not blocked by firewalls when you implement file sharing. It is sounding very much as if you have a firewall blocking WideFS, though I've never seen such a case reported as a "host not found" problem when trying to "GetHostByName". This is why information from the log is important. Did the reported error change when you implemented nicer and shorter PC names? Ouch! You are running McAfee? Have you disabled its firewall, or at least told it to allow FS and WideClient access? Regards Pete

Good! Thanks for letting me know! Regards Pete

It doesn't matter what they are providing they are not the same. Haven't you tried simply renaming the PCs yet? I'm amazed that you want to do complicated things before trying something simple. And why on Earth did you name them such weird compicated long names in the first place? As I already said (and reproduced part of the documentation), the ServerIPAddr parameter replaces the ServerName parameter, which you already tried. But 99.99% of users never have to read that far, and if they do it would be better first to learn a little about Networks. I cannot teach Networks, all I know about them is from Windows Help and so on. As I said right at the beginning, your problem seems to stem from the very weird names you gave to your PCs. No one else in the 9 or so years of WideFS has ever reported such problems, but then no one has ever reported using such names. I really have no other explanation to offer. If you'd please read all of my replies not just select the more complex possibile solutions automatically, maybe it would resolve itself quicker? For most, the overwhelming majority, installing WideFS is a matter of inserting files and runing FS. For many releases now everything else has been automatic. Yours is the ONLY and FIRST case of an apparently nonsense PC name messing things up, and for reasons totally unknown to me. If you want to get to the bottom of it I would suggest contacting Microsoft Support, who ultimately must be the source of solutions to such problems. But first I would advise simply trying the tihngs I suggest, starting with a simple re-name, as I gave step-by-step instructions for!!! There's no part of it to cover your unique case, and none you would have needed to read if you had been among the 99.99% of trouble-free users. I am sorry, but I cannot anticipate every eventuality, nor can I predict what Windows will do in such strange circumstances as those you seem to have created. I am very sorry. I do try hard, but I am neither perfect nor precognisant however much I'd like to be. :-( Regards Pete

Please see the "Sticky" nearer the top of this Forum, after the announcements and download threads, entitled READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. Regards Pete

I'm afraid WideFS documentation isn't the place to look to learn about Networking. I have to refer to Windows help and so on myself to find out what I need to do. However, I just looked at the WideFS documentation, and it all seems to be pretty clear there. did you miss this part (within the Configure your Network section, early on). As it says, it replaces the ServerName parameter. I've no idea what you are talking about there, sorry. Haven't you just tried to change the Computer name to something more sensible? Why did you use such complex and long names in any case? To rename the computer simply right-click on "My Computer", select Properties, then the Computer Name tab, and the "Change" button. Pete

You can assign any controls to different zones of a joystick axis, and with direction dependence, on the right-hand side of FSUIPC's Axis Assignment option tab. You'll find Gear Up and Gear Down separately assignable in the drop-down list, but I'm afraid there's only a toggle for the Parking Brake, though you could make an "on" and "off" by using the Offset Word Set control with offset x0BC8 and parameter 0 for "off" and "32767 (or x7FFF) for "on". Regards Pete

Why use a name like "X-5AA63C3ED7614"? It doesn't exactly roll off the tongue, does it? Mine are called things like "Upstairs1" and "Centre" and "Flying". I'm not sure whether the Windows interface is case sensitive, but maybe you should try entering it exactly as it is shown in your My Computer properties window -- i.e. with lower case letters where appropriate. If all else fails, trying naming the PC something shorter and more easily spelled, like "MAINPC". Well, the problem is not WideFS but simply that the client PC cannot find the server PC with that name. So either the network isn't working at all, or the name is suspect. Judging by the second log, though, the Network is okay. You could try using ServerIPAddr to give the fixed IP address of the Server instead. You did set fixed IP addresses for each of your PCs didn't you? Check Network properties, TCP/IP Protocol. You can do it there. The PCs should also be both in the same WorkGroup -- but I see the broadcasting did work in any case, as this occurred in one of your examples: ... so it certainly looks as if the problem is all to do with that name. Note that I always thought computer names, like drive names, were limited in length to 11 characters or something like that, so this could be another reason. The only information Windows is giving me is in that message "Host not found" when I ask it to find "X-5AA63C3ED7614", so it simply has to be that (awful!) name. Regards Pete

I don't understand that either. Sorry. Is FS recognising the correct make/model? See if it has it listed with that name in one of its "devices.CFG" files, in the main FS folder. No, it shouldn't have now -- FS2000 and before would have, but they changed to using DirectInput in FS2002. FS supports multiple devices -- were you ensuring that was being selected? You may have to scroll the device list to see it. I think you have to select the correct device before seeing any action. Regards Pete

Either the brtoadcast from wideServer is not being seen on the Client, or the client cannot see the Server or is denied access. The log files (wideClient.Log in the wideclient folder, or WideServer.Log in the FS Modules folder) will help showe what is happening. They are not needed at all with WinXp on both PCs, provided both PCs are in the same workgroup. What is "the alpha-numeric name from within the square brackets"? there is only one computer name -- right click on My Computer and select properties. Or look at the widseServer log, where it tells you. Ah, you have the firewall enabled? If it is blocking WideClient I think you you will either get an error logged saying "connection refused", or often simply nothing at all. WinXP seems rather inconsistent depending, presumably, on the update state. Mostly it seems to simply hide the server completely from the client. Try disabling the firewall on the Server. If it then works, that is the problem. Regards Pete

Okay, but unfortunately the original windows joystick interface (as used by FSUIPC until very recently) only supports 6 axes, not 8. For FSX (FSUIPC4) I have changed the Axis Assignments to use DirectInput, so it does now recognise the original 6 axes plus the two "slider" axes added by the newer interface. But I'm afraid the changes are too severe to undertake at this late stage for FSUIPC3. Why are you assigning axes in FSUIPC in any case? What is wrong with assigning them in FS itself? If you assign the throttles in FS, then you can still use the Calibration in FSUIPC. The axis assignment facilities were a much later addition, and primarily intended for those who wish to assign different joysticks for different aircraft types - e.g. joystick for Airbus, Yoke for Boeing, G-stick for Helo. If you only want to calibrate throttles for the Airbus why aren't you using the straight-forward FS assignments? Incidentally, FSUIPC version 3.71 is no longer supported. 3.72 is current. Regards Pete

Ahit is only supposed to be there for a fleeting moment. The keypresses to select it are sent at the same time it is added. If you are seeing it for long it means FS is so busy then that the keypresses sent are still queued. Yesthat is quite likely. Though it shouldn't simply be related to the installation of a new version of FSUIPC -- I still cannot make sense of that. I'll have a look to see if I can delay the menu addition from PFC.DLL until things look less busy, though that's rather difficult to judge programmatically. It may seem an odd way to do things, but I found going via the Menu the only way to get the Check dialogue reliably displayed on top of the FS Window when it is in Full Screen mode. If I try to just display it directly, then whether is shows above or below the FS full-screen seems uncontrollable, depending on timing, video drivers, and so on. This is even using "bring window to top" and other Windows facilities. I think it's to do with the use of DirectX painting since FS2004. Okaybest not to, please. It isn't intended to be used manually. Maybe I should just display "." or something rather than the name. By clicking it it seems you are somehow selecting it before FSUIPC is ready. I'm not sure how that is possible -- but it will be related to Windows Message queues I think. Thanks for the clarification. I'll try to make it less likely to happen. Regards Pete

I'm afraid it isn't attached. But I still don't understand. "When it happens" = only when updating FSUIPC versions? Never any other time? So you are saying it happened twice only so far? It sounds like it is down to the order of files in the folder. This is very strange. But only twice so far? I simply cannot imagine what is going on there, then, except possibly the fact of no INI or KEY file changes the start-up timing as FSUIPC and PFC are kloading and initialising. However, after the first run, when you have the files re-established, you should be in exactly the same boat as when you first tried the updated DLL -- it seems to me that there cannot be any difference then as all the files are then exactly as they were when it 'failed'! Well, so far it certainly seems to be, and I'm afraid I cannot even hazard a guess as to what is happening. Okay. Thank you! Regards Pete

No, it only comes with the DeLuxe Edition of FSX. Regards Pete

I'm afraid we've never discovered how to set the airspeed directly. The offsets for this are *results* of computation, and will simply get overwritten on the next cycle. There are some velocities, accelerations, etc, in the 3000 + area which do certainly have an effect, but not precise and not maintained unless you keep writing fast enough. Even in FSX, where the facilities are already a little more comprehensive in this area, the only sure way of setting the airspeed is by an effective "restart", where the position and attitude are also needed and it it nearly as slow as loading a new flight. Regards Pete

You should please ask questions about my programs in my Support Forum, as I don't visit here so often, and answers to such questions can be found over there quite easily. [ADDED NOTE: This was posted in reply to the original posting which occurred in the FS2004 Forum]. I am told that Administrator privileges don't actually give you any rights to access the Registry, or even, oddly to write to some file areas. It seems you need "elevated Administrator" privileges. So far every one who has reported this problem has reported success when using "Run As" to run FSX to register FSUIPC4, specifying the Administator there I think. There may be other problems. If you allowed FS to install into the default place (Program Filesetc), then Vista may actually prevent FSUIPC4 (and any other program) actually writing to its own files, the INI, KEY and LOG files for example. So settings won't be saved. The answer at present seems to be to manually change the Access Permissions on the FSX Modules folder to allow you, as the user, to access those files for writing. Ugh. Vista seems to be rather over-protective. I have just purchased Vista for installation on one of my PCs in order to carry out some tests so I can document all this thoroughly. I'll be working on this in the coming week. I am looking at moving the LOG, INI and KEY files over to the My Documents FS files folder (where Flights etc are saved) to get around the access privileges problem. When I have a version which does this it will be released on my Forum, and it will automatically move those files from the modules folder if they already exist there. Please use my Support Forum for any future queries on my programs. Regards Pete

Okay, I cannot make that happen here. It is as I said. To make it clear I set the FileMon filter to "FSUIPC4.INI;FSUIPC.INI" not just "FSX" because the latter gets thousands of FSX file accesses too. The FSUIPC4.INI file (never FSUIPC.INI) is accessed initially, during FSX loading, quite a bit (naturally), then when a flight or aircraft is loaded, again when you explicitly reload values in the Options, and when you close the options (to save changes), and finally when FSX is closed. If something different is happening on your system, can you please show me the FSUIPC4.LOG -- maybe some aircraft or flight is being constantly reloaded? -- and perhaps save the FileMon log so I can see what you see. ZIP them and send to petedowson@btconnect.com. Regards Pete

Really? There's certainly no explicit code in it which does this -- the parameters are read initially (a module which is never called again), and when requested in some of the Options pages (a module only used when the Options dialogue is showing), and finally when a flight or aircraft is loaded (to check for aircraft-specific keys, buttons, axes or calibrations. I'll check it here and get back to you. Regards Pete

It sounds like the DLL's signature verification for FSUIPC 3.72 isn't working. Can you show me the FSUIPC log please? And I also need to know the version number of the PFC.DLL. Erwhat do you mean? Everytime you've moved from, say, 3.00 to 3.01 then to 3.02 etc etc? How many times have you upgraded? I need to understand. And if this has been happening for myears, why not mention it before? Hmmm. I certainly don't understand that. Neither FSUIPC nor PFC have any "memory" other than what's in those files, so if the files are made the same as they were, then the same problem, exactly, should ensue. If it isn't due to the verification checks (the main change in 3.72), which will be obvious from the Log file, then it may be a timing problem, with the PFC.DLL trying to start before FSUIPC is ready. That may just change slightly with a different order of files, but it seems unlikely. I need more information, please. Yes, it should, and it does here and always has. I am not sure why it has ALWAYS been different on your system -- every time you've replaced an older FSUIPC with a newer one? It makes little sense to me at present, but please clarify these things and we'll get to the bottom of it. Regards Pete