Jump to content
The simFlight Network Forums

Pete Dowson

  • Content Count

  • Joined

  • Last visited

  • Days Won


Pete Dowson last won the day on August 3

Pete Dowson had the most liked content!

Community Reputation

258 Excellent

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Travelling, Real / Craft Ale,, worldwide

Recent Profile Visitors

35,995 profile views
  1. That's a bit odd. How does a client crash cause the sim on the other PC to crash? The logs don't show anything useful I'm afraid. Apart from Windows updates, are you aware of any other changes made to your long-working setup? Can you take a look in the 'Event Viewer' (a standard Microsoft utility, should be installed)). Look under Windows Logs -> Applications, and see if there is an error report there for WideClient. If so, please post the details. In case it is related to some specific exchange between the client and server could you also change the Wideclient INI to have Log=Yes instead of Log=Errors+. Pete
  2. Good. Yes, that seems to be a common problem. You wouldn't have thought that in developing a faster interface they'd lose some compatibility with the previous incarnation. Pete
  3. I'm pretty sure that the USB yoke they make is a standard joystick device and doesn't need FSUIPC. It should be recognised by Windows Game Controllers as a normal joystick and by P3D. If Windows doesn't see it then FSUIPC cannot either. But you're saying that Windows complains that it needs a driver? In Windows Device manager is it listed as a COM device or only a USB device? And how listed in Windows Settings? By name? Pete
  4. Save the following in a text file named "FixMyJoys.reg". Windows Registry Editor Version 5.00 [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_294B&PID_1900] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_294B&PID_1900] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_16D0&PID_0A38] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_16D0&PID_0A38] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_10C4&PID_82C0] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_10C4&PID_82C0] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_8807&PID_8807] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_8807&PID_8807] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_294B&PID_1900] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_294B&PID_1900] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_16D0&PID_0A38] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_16D0&PID_0A38] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_10C4&PID_82C0] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_10C4&PID_82C0] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_8807&PID_8807] [-HKLM\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_8807&PID_8807] Now this should in no way do harm to your system -- it is just deleting your joystick device entries from the Registry. however, before editing the registry at all i always play safe and do a Windows backup (the Window backup and restore facility in Windows Settings or Control Panel). Unplug your devices. Then run the .reg file you just created by right-click and selecting "run as administrator". Now power off. Plug your devices back in, and start the PC again. This should give you a clean registry with your devices properly registered. Pete
  5. It looks like it crashed whilst reading the complete ground and air traffic data in one go. Does one of your programs do that? It's a long time since I delved into the nitty-gritty of WideFS, so it might take me a while to work out what is happening. But there are two more steps you could do, please, to narrow it down more conclusively (after all this is only one crash and it might just be coincidental that it is doing this particular thing). First do the same sort of test but with Log=Yes instead of DebugAll. Second, see if the crash still happens if you don't run the program which is reading traffic. Pete
  6. Okay, yes. I see the registry details. I'll work out what you need to do ... Pete
  7. You tried "(L:klid) = 1703010" where, exactly? and what do you mean by "the fsuipc list"? I really don't know what you are talking about there. To set an L:var from a Lua plug in you need to use the ipc.writeLvar function. Please do refer to the Lua library documentation. Pete
  8. So the actual devices you have are: 1 x Alpha Flight Controls 2 x UnoJoy_Throttle 1 x B737 1 x MFG Crosswind V2 Right? And in the last set of files you submitted these were recognised and assigned: 2 x Alpha Flight Controls 2 x UnoJoy Throttle which means on that occasion you lost both the B737 and the Crosswind and gained a "ghost" Alpha Flight Control! All because of Windows apparently repetitively assigning new GUIDs which copy existing ones. I think there must be a load of entries in the Registry for each of those devices and which entry gets assigned is almost pot luck. Not sure what the "more details" were intended to be in the Log, but there's nothing useful there. For some reason you are running a plugin called "comtest.lua" and have Lua log/trace enabled. Next step would be to get the log with that extra logging i mentioned so I can give you instructions on cleaning this stuff in the Registry. Pete
  9. Well, it might be easier to eliminate each of them, one at a time -- or maybe by halves. after all, in the end i have to get the logging operating for those offsets to see which causes the crash (assuming it is due to one of the values being written). Another way of tackling it would be to log them all in any case and see if there's any consistency over the last thing written before the crash. It's just that the log could get very large. To make this happen please set Log=Yes (replacing Log=Errors+ probably) in the [User] section of WideClient.INI. There are much more detailed logging options which we'd use if that proves futile -- Log=All, and Log=DebugAll. One of these methods should show us what is causing the problem. Pete
  10. We didn't need the FSUIPC log. If anything the WideServer log would be the one relating to WideFS. You give only one client log. Please confirm that there are no lua files in the WideClient folder. I see there are quite a few applications being loaded: 5016 New Client Application: "FsATG" (Id=1720)5422 New Client Application: "FD_Sounds" (Id=10480)21922 New Client Application: "FlightDeck320" (Id=7212)282110 New Client Application: "FSATG" (Id=5492)287516 New Client Application: "FD_PUSHBACKEDITOR" (Id=1444) Is it possible for you to run with less of these? Or even one at a time? I'm trying to see which might be causing WideClient to crash. I know it shouldn't happen, but perhaps one of them is writing some values to an FSUIPC offset which Wideclient chokes on. Once we can narrow it down I can tell you how to enable logging so we can find out exactly which. To do this logging without first narrowing it down a bit would produce far to much to wade through i fear. Pete
  11. There is an update to 7.157 which fixes a problem which could conceivably cause a crash if ipc.Get's and ipc.set's are used a lot to transfer data between clients. The problem with a crash in NTDLL is that it could be almost anything. That Windows module is a collection of many of the little functions used by most programs. Before we go further, assuming it still occurs with 7.157, we need to see your WideClient.INI and WideClient.Log for each PC (after each crashes). Also, if you have any Lua plug-ins on the Clients, list those, and finally, whether you have joystick devices on the client with buttons/switches assigned in FSUIPC. Pete
  12. I use several Bodnar BU0836 cards without problem, but not as many on one PC. I have read of problems with more than a few (can't remember number -- something like 50 such cards connected to ProSim. I don't recall if those problems were ever solved. If neither FSUIPC nor P3D can read the buttons on this card I can only think its a problem with Windows itself. Not sure how you can work around that -- unless you have a Networked PC and can connect it there and use WideFS to connect buttons to FSUIPC. Pete
  13. It would be interesting to see the files before the re-boot so we can see exactly which one changed its GUID. In the new files you provided things are slightly different -- the second pair with identical GUIDs is with "B737" instead of the Crosswind: MFG Crosswind V2 ID=4 {9EEBEF20-B521-11E7-8001-444553540000} Alpha Flight Controls ID=4 {9EEBEF20-B521-11E7-8001-444553540000}, B737 ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} Alpha Flight Controls ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} The common factor in this is, then, "Alpha Flight Controls". Very odd that Windows keep re-assigning it AND gives it the same GUID as something else. I can provide detailed instructions, or even a little .REG file to remove them automatically, if you get me a log with more details. To do this add these lines to the [General] section of the INI file: Debug=Please LogExtras=x200000 The log will then give me the full pathnames in the registry. Pete
  14. Thank you. And please also try those alternative assignments I provided earlier for the PMDG 777. Pete
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.