Pete Dowson

Both WideClient and WideServer create a Log file on their respective PCs so that they can log what is going on. Neither waits for any connection to be made before creating such a file -- otherwise how would they be able to log any errors, as in fact they do in your case? What makes you think WideFS on the server is receiving anything at all? There's no evidence of that. Since the Client cannot even get the Server name recognised by Windows, it has zero chance of sending anything whatsoever! WideClient does not need any access on the Client. It is not being allowed to connect to the Server, so it is permission on the Server which is needed. Please just try disabling that. I'm sure that must be where the problem lies. I suppose you have your firewalls set to be very protective. I have never had such a message, but, in any case, it will be the Server stopping WideClient I think. File and folder sharing is absolutely nothing whatsoever to do with WideFS or communication between one TCP/IP program and another. The sharing system is to do with Explorer and file access. There is no cross-Network filesharing needed or used by WideFS. This tells me that Wideclient received a Broadcast from WideServer telling it that WideServer is running on the PC called SERVERPC, and also that Windows will not let WideClient see the PC called "SERVERPC". It seems that it must be a firewall block, as I keep saying. The second one: merely says that no Boadcast was received from WideServer in the 16 seconds you allowed WideClient to run. It looks like, by then, you had stopped FS on the Server, or had it suspended in some way (e.g. in a menu). I don't blame you, but I do wish you would first just at least try disabling your firewalls. I don't see how it could be down to anything else. If it then works you will at least know that you need to somehow set your firewall options correctly. I really don't know of anyone else at all who has had such problems, but perhaps no one else has set such fierce protection. I don't know. Sorry. It just seems mighty odd that even after several years of Windows XP and its automatic default protection (at least since SP2), yours is the first firewall problem that appears to be intractable. Regards Pete

The should only be on FS Modules folder, and this should occur in the FS you are using and have installed. Any other such folder, sitting outside of FS, is not going to be used at all, at least not by FS or anything of mine. Nothing of mine creates such folders or places random copies of FSUIPC.DLL. It sounds very much like you have installed assorted add-ons which do install their own (outdated) copies of FSUIPC, and you have somehow pointed them to the incorrect place for FS. Regards Pete

That error in within FSX's WEATHER.DLL. This cannot be related to FSUIPC4 directly. It may be that, during initialisation FSX downloaded real weather which was corrupted, or possibly the weather saved in one of your Flights (the WX files) is corrupt. However, also check that you have not enabled the option in FSUIPC4 to affect FSX's own weather (it is on the Miscellaneous option tab), as this can rarely lead to a similar crash -- one which Microsoft is aware of and which will hopefully be fixed in the upcoming SP1 uipdate. Unless it happens again I wouldn't worry about itjust be sure to update your FSX when the Microsoft update becomes available. If it does occur again and become more consistent, you may need to look deleting some of your saved flight or weather files -- possibly change the default one. As a last resort, deleting all saved FLT and WX files and the FS9.CFG file so it builds a new one may solve it. Regards Pete

This is only just discovered in 3.71, a day or two after I released 3.73? You skipped 3.72? The facilities seem okay here, and they haven't been changed for some time (version 3.70 last July, in fact). I really need more information, please. What is the "ShortAircraftNameOk" parameter set to in the INI file, for example. Perhaps you could show me the FSUIPC.INI file in case there's something else specific in your settings? Regards Pete

How come you have an FS2004 folder as well as a Flight Simulator 9 folder? FS2004 *is* FS9! You only need FSUIPC.DLL in the Modules folder of the Flight simulators you actually use. Check the shortcut you use to run FS -- right-click on it and select Properties. See which copy of FS you are using. In the Modules folder there should also be an FSUIPC.INI file and an FSUIPC.LOG file (maybe also an FSUIPC.KEY file). See which copy has the most recent date. That will be the Flight Simulator you ran last. Regards Pete

See the Sticky thread above called READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. Please do peruse the Announcements and Sticky Threads at the top of the Forum from time to time. They are designed to help and keep you informed. Regards Pete

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