Pete Dowson

Thanks. If you look at the [JoyNames] section you will see 4 labels "missing joystick", devices A, B, C, D. And the samed named joysticks have been added as E, F, G and H. This is because, as expected, the GUIDs have changed -- Windows has generated new ones. So all that was needed was to rename the E F G and H lines as A, B, C and D, to correspond to their original labels. I've done this for you. Just replace the entire [Joynames] section with the one below. [JoyNames] AutoAssignLetters=Yes 0=CH PRO PEDALS USB 0.GUID={115B0EA0-557B-11EA-8003-444553540000} 1=CH ECLIPSE YOKE 1.GUID={115B0EA0-557B-11EA-8001-444553540000} 2=T.16000M 2.GUID={115B0EA0-557B-11EA-8005-444553540000} 3=TWCS Throttle 3.GUID={115B0EA0-557B-11EA-8002-444553540000} A=CH PRO PEDALS USB A.GUID={115B0EA0-557B-11EA-8003-444553540000} B=CH ECLIPSE YOKE B.GUID={115B0EA0-557B-11EA-8001-444553540000} C=T.16000M C.GUID={115B0EA0-557B-11EA-8005-444553540000} D=TWCS Throttle D.GUID={115B0EA0-557B-11EA-8002-444553540000} Then all of your existing assignments should work as before. Test it all, and only then remove FSUIPC etc on your old PC. Now you'll know what to do next time! 😉 Pete

Same here. And as you know, I don't have an operational "main FS PC" at present. Also, my debugging tools (VS etc) are only on my development PC, so I put the Beta there -- except for those which must have Win10, in which case they are currently on my VFR PC (55" 4K screen). Pete

No, leave it be for now. Register FSUIPC on the new PC then run FSX once. Close it down then copy the old PC's INI file over to the FSX Modules folder in the new PC, replacing the one which is there. Then run FSX again on the new PC, then close it down, and paste the FSUIPC4.LOG and FSUIPC4.INI files here so I can see how to edit your new JoyNames section. Only then delete the Modules folder on the old PC. There's nothing else to do on the PC. Pete

That looks like the log for a connected ASP4. My total btstrp.txt is: 02/22/20 14:37:57 SHOW: Incompatible P3D version. This version of as_connect is designed to be used with P3D versions 4.0.23.21468 up to 4.5.13.32097 02/22/20 14:37:57 SimVersion=-1 02/22/20 14:37:57 p3dBuild=1432669 02/22/20 14:49:43 Dll stop called but you are not running the latest P3D4.5, which may also explain it. Looks like I'll have to uninstall the Client and go back to the current release. I know all that. It was the remote ASP4 connection to as_connect which I was thinking might have been using a different socket, as i said. I don't need to sort out the true network connection if i am trying to repro your problem which occurs when ASP4 is NOT running. In fact I'm testing with no client PCs switched on in any case. Okay, that's fine then. I'll try going back to 4.5.13. I should really have noticed you weren't using the Beta from the FSUIPC log files you've posted. Pete

Hmmm. I just enabled the ASP4 DLL for installation into P3D4.5 on my test PC, so I cauld run a debug session on it. ASP4 itself isn't running anywhere. Though WideFS is enabled, and FSUIPC is definitely linking to the ASP4 DLL (I have the log entries ASN active function link set Ready for ActiveSky WX radar with additional data as in your logs), it closes fine. My version of as_connect.dll is 17.1.1.126 dating from 26/09/2019. Can you check your please? The other difference is that I am using Win7 still on this PC. Looking in the as_srv folder, where as_connect is kept, I see the file "bstrp.txt" has this entry in it: 02/22/20 14:37:57 SHOW: Incompatible P3D version. This version of as_connect is designed to be used with P3D versions 4.0.23.21468 up to 4.5.13.32097 I am on the last 4.5 Beta, so maybe this means as_connect isn't doing much, though it is responding to FSUIPC's connection requests. Maybe there's something different in the as_connect.dll setup when set for using ASP4 on a different PC, though I don't see any configuration file? Pete

Aha! Thanks. You decided to start a new thread. I already answered your post on the old thread, and all I can do here is repeat more or less what I said there. In that earlier post you said: Now that tells me that your A320 is running on FSX or P3D1-3. Correct? I'm not sure how you get the "1:" part of that encoding. It should be more like RX10db120*X55cc. The value after the X is a code address in whatever gauge file is used (shown in the .mcro file), and the X55cc is a check value which stops the macro jumping into the wrong place if the aircraft has been changed (updated). Whatever gauge or DLL it is seems to be very large -- nearly 18 Mbytes! Are you sure that that aircraft add-on will support mouse macros? The mouse macro facility in FSUIPC4 was implemented by hacking directly into FSX or P3D code, and this process certainly doesn't work for everything. It wasn't until P3D4.1 that facilities were provided by L-M to allow them to be used for all aircraft. By all means show me the .mcro file you made, for me to check, but please also check how other users of the same aircraft are managing. Check in User Contributions, above, and also in the FSLabs forums. Maybe FSLabs provides another way (eg additional custom controls) to do things? Pete

Why not just call the names macro using the existing form of ipc.macro? Seems more complicated for both you and us to have extra work to do, reading .mcro files for you and more complex code for us. The existing facility is surely adequate and clearer, and in fact more flexible in case of updates to the add-on aircraft causing the macro rectangle numbers to be changed. You'd only have the macros to re-make, note the Lua files to be edited too. Pete

I'm not sure what ASP4 does when running on a client PC. There's an AS DLL which runs internally in P3D4, and the main AS program talks to it. I'm not sure how it does this -- via TCP/IP or UDP on its own socket I suppose. But certainly, if that DLL is running then FSUIPC will connect to functions within it in order to receive assorted weather data and in particular the data for the weather radar file it produces for other add-ons (like ProSim). Anyway, it's a good clue, so thanks. Pete

Are you sure that whatever aircraft add-on it is that it will support mouse macros? The mouse macro facility in FSUIPC4 was implemented by hacking directly into FSX or P3D code, and this process certainly doesn't work for everything. It wasn't until P3D4.1 that facilities were provided by L-M to allow them to be used for all aircraft. By all means show me the .mcro file you made, for me to check, but please also check how other users of the same aircraft are managing. Check in User Contributions, above, and also in the FSLabs forums. Maybe FSLabs provides another way (eg additional custom controls) to do things. Incidentally, you added your question to a seven month old thread. Not a good idea if you want others to help. best to start another rather than add to an old one. Pete

NO! As instructed in the user guide, you only need to set Yes for AutoAssignLetters. Leave the other lines as they were — they are needed to allow FSUIPC to replace the numbers by letters in your assignments. You’ll need to undo your changes! After setting the Yes, run the sim. The letters will be assigned automatically. That’s the point. Editing Joynames will come later, on the other PC after you run FS once there. The GUIDs will be different, that’s why. Pete

So, is P3D4 closin okay, but leaving some part of LINDA still running? Or does P3D4 not close properly? Why do the LINDA folks think it's to do with FSUIPC? Have they information or evidence for that? It sounds rather like some incompatibility between LINDA and the new NGXu then. Is there anything on the PMDG website? Does it occur with the NGXu if you don't run LINDA? Did you use the NGX with LINDA before? I don't know if reviewing logs will give any clues, but we cannot help without them in any case. Find the FSUIPC5.LOG in the Modules folder and show it here -- after tring to close P3D4. Pete

How are you trying to "map" an event, and to what? FSUIPC logs events but it has no facilities as it stands to change them. It logs them en route to the Sim. FSUIPC itself causes such events to occur when you assign to them. If you need to make an event do something other than what it is designed to do you woud need to use a Lua plug-in, which can intercept them. See event.control in the Lua library PDF. FLCH isn't a built-in function, that's why. It's specific to particular cockpits with Autopilots equipped with such, so it will have to be handled specifically per cockpit using whatever means are provided for it. Well, it sounds like you can program it to do what you like then. I don't know what add-on aircraft you intend to use, but if it's one of the PMDG Boeings then they use added control numbers (events) for most of their switches, dials, axes and knobs, so you could map directly for those. For others you could choose a control / event number outside of the assignable FS /P3D range (see the lists provided) and use a lua plug-in to perform whatever action you need, as already mentioned. Pete

First make sure you are using "Joy Letters" (see the Chapter in the User Guide), as it will make it a lot easier to keep your assignments, just editing the JoyNames section on the new PC. Then, after installing FSUIPC on the new PC, copy in the FSUIPC INI file from the old one. It probably won't get the assignments correct initially, but we can sort out that provided you've used Joy Letters, not left it to the ID numbers. Pete

Ah, that's more understandable. So, unless you've only recently enabled WideFS, something else in your system has changed or been corrupted. I still feel it must be a lower level Network function. Just because the network appears to be okay otherwise doesn't mean it isn't. Not all programs have the same sequences or timings. I'd still like to try to resolve it, so I'll look to se where extra logging might help during the closing process. Pete

You don't actually activate wideClient, just WideServer, which is done in the FSUIPC Installer. You can have as many Clients attached as you like with one licence. Yes, just Install FSUIPC on your new PC and register both FSUIPC and WideFs using your existing registrations. where you put WideClient is up to do, it isn't registered. It'ds the access to FSUIPC + WideServer which is registered. Pete

I feel it is still a low level problem. What was that GoFlight entry doing in the Stack trace for the hung thread? Have you tested without that drive at all? Without being able to reproduce it it seems a rather intractable problem. I don't know if there's some other logging John or I can add. I'll try taking a look when I get time. Pete

Also, with WideFS enabled, add this line to the [WideServer] section in FSUIPC5.INI Log=Debug That will log quite a lot, but since you have no Clients connecting, not so much as it will sit waiting until you close down. Please then show us the WideServer.Log file. This is all I have in mine, with FSUIPC 5.153 and with no clients: ********* WideServer.DLL Log [version 7.076] ********* Blocksize guide = 8192 (double allowed) Date (dmy): 25/01/20, Time 15:02:39.246: Server name is LEFT 531 WM_MYTIMER2 still okay 15148 Starting service in 'MYTIMER' call 15148 Initialising TCP/IP server 15148 Serving socket obtained okay 15148 Socket bound to address+port okay 15148 Listening on socket now ... 15148 Set to receive Accept message upon connection 15148 Initialising UDP/IP server 15148 Serving socket obtained okay 15148 Socket bound to address+port okay 15694 WM_MYTIMER2 still okay 16131 Broadcasting service every 1000 mSecs 20748 WM_MYTIMER2 still okay 5312240 Closing down now ... Memory managed: Offset records: 2357 alloc, 2355 free Read buffer usage: 0 alloc, 0 free, max in session: 0 Write buffer usage: 0 alloc, 0 free, max in session: 0 Throughput maximum achieved: 0 frames/sec, 0 bytes/sec Throughput average achieved for complete session: 0 frames/sec, 0 bytes/sec ********* Log file closed ********* That's with this in the FSUIPC5.INI file: [WideServer] WideFSenabled=Yes AdvertiseService=1 Port=8002 Port2=9002 Log=Debug There's not a lot shown for the shutdown sequence as there isn't much to it. But I do need to know if your problem is truly just a 5.152 to 5.153 difference, because the source code for WideServer isn't changed. I'd need to check with John about whether the Visual Studio version and maybe libraries used were changed (I'm still on vS2017 but I think John moved on to VS2019). Pete

And what if you never start FSXWX? Just test without, and with NoWeatherAtAll first. It is still all pointing to a couupt Weather file, a .WX or that wxstationslist.bin file. Are you sure you removed them all? Pete

The log ends at the point where WideFS threads are being closed, which includes efforts to shut down any open listener sockets and outstanding transmissions, AND you earlier reported that it seemed stuck in a network operation. The only thing it can be is a hanging network driver or API. I’ve only ever seen this rarely and it’s always been bad network drivers or corruption at lower levels, where it is out of our code’s control. Check your drivers and maybe Windows updates or other things which may have changed recently. ALSO I see a GoFlight driver in your stack list. What's that doing there? Have you tried without this? Note that considering the numbers of WideFS users, have been very few — maybe a handful over the 20 years of WideFS (which hasn’t changed really in all that time -- except dropping support for the old Novell IPX protocol (which was much faster) and adding UDP instead, when MS removed Novell stuff from Windows). If you are using TCP try UDP, or vice versa, just to see. And don’t forget to check drivers etc at the Client ends. And check Intel drivers, not just the higher level Windows stuff. Pete

If you mean FSUIPC error 12, then that simply means the program you are using cannot contact FSUIPC. Either FSUIPC is not running (or the sim -- FS9, FSX or P3D?) is not running, OR you are running the Sim "as administrator" but not the failing program, or vice versa. Both need to be at the same privilege level or they cannot talk. Really you should contact the support for the program you are using, whatver that it. And if you again request support here please at least supply some essential minimum information such as FSUIPC version, FS version, and the proper name of the application you are using. Pete

If FSXWX doesn't need FSUIPC, and you have no other add-ons needing weather from FSUIPC, then add this line to the [General] section of FSUIPC4.INI: NoWeatherAtAll=Yes That stops FSUIPC having anything to do with weather. Pete

Back last weekend. That's why I suggested turning off WideFS as a test. Really annoying when you get problems like that. When running the debug build of FSUIPC with Visual Studio we can usually identify the last call made to a Windows API and that might help work out why. One thing worth trying is checking that the Network drivers are fully up to date. Keep us posted. Pete

FSUIPC is not getting as far as closing down completely. But where is P3D hung? Is it actually in an FSUIPC thread? I'm certain that there are no recent changes in FSUIPC which would affect the closing sequence. Are you sure it is FSUIPC causing the process to hang and not another module? The only way we can tell is attaching to the process with Visual Studio and seeing what thread it is stuck in at the time. In the past this has usually been due to some device driver hanging, maybe the local network. Is it consistent? Can you try a process of elimination please? For example, try disabling WideServer (on the About tab in FSUIPC Options). And what is your ipcInit.lua trying to do where you need an unavailable Socket support package? Note that ipcInit.lua is run early on in FSUIPC's starting sequence, and some things won't be ready at that time. ipcReady.lua is generally the safer way to start off plug-ins. Pete

The crash details show that FSX is crashing when trying to establish the WEATHER. It occurs when FSUIPC is running because FSUIPC continually reads the weather through SimConnect. I really don't think it can be anything to do with which aircraft you are using, unless you are also at a different location -- the weather being read would depend on where you are. These crashes occur when SimConnect tries to read a corrupt weather file (which are binary files with no checking). Try deleting the wxstationlist.bin file from your sim's AppData\Roaming folder, and all of the .wx files saved in your sim's Documents folder. Pete

Sorry, it appears you still do not understand! Value 1 is bit 0 and value 2 is bit 1. The values of the bits are as i said: bit value 0 1 1 2 2 4 3 8 4 16 5 32 6 64 7 128 The setbits and clrbits functions use the values, not the bit numbers, because they are designed to allow multiple bits to be set or cleared. Pete