Pete Dowson

WideServer.dll is not used in P3D or FSX, it is for FS9 and before only! For FSX and P3D WideServer is build into FSUIPC, as clearly stated in documentation. You have to install and register FSUIPC. WideClient, on a separate PC, does not support axis assignments, only buttons, which would then be seen in the FSUIPC options on the connected server running FSX or P3D plus FSUIPC. Pete

It did do, but I'll re-check here. Pete

Any hang or freeze which can only be overcome with Task Manager is almost certainly down to a bad or corrupted driver, maybe one for a device you no longer have. Seeing as it happened whilst dealing with joystick axes, I'd carefully check through your joystick connections and drivers. You can use Windows Device Manager to remove them, including drivers, so on a system re-boot they get re-installed automatically. Please, in future, supply the FSUIPC4.LOG file, if one is produced. That is always important. Your FSUIPC4.INI file would also be of use since it would show detected devices and assignments so far. Pete

Not without a very big error prone revision. The only way I could consider doing it without makeing a mess would be to treat the second batch of 32 as a separate joystick. Still very messy but possibly viable. (And what about 128 buttons? That's the limit I think in DirectInput now! 4 joysticks?). There's also still a limit of 16 "real" joysticks, so to avoid that becoming a problem the extra ones might need to be assigned rather higher numbers. Maybe 50+real number. It would be a project to undertake in more settled times. Too much else to so at present I'm afraid. Meanwhile it can be done using the HID facilities in the Lua COM library. Pete

PMDG's implementation needs throttle axes assigned normally (whether in P3D or FSUIPC), to the normal Axis controls (Axis throttleN set in FSUIPC), and not calibrated. The problem is that they intercepts the axes at the same level as FSUIPC does, whereas calibrated values have to be fed into FS at a lower level to avoid an infinite loop. Pete

As well as what Thomas suggests, use the Traffic Explorer from the SDK to check the actual total number of aircraft and their distributions. Depending where you are and the numbr of nearby airports the parked traffic could vary a lot. The difference in 0-2 and 6-8 in a limit of 100 is not significant when the elmination performed by the Traffic Limiter algoithm is randomised in any case. The numbers for the parameters are only biassing the random selection, so it would need larger numbers or a long period of changing traffic (comings and goings) for that to amount to those exact relationships. Pete

The sleep function simply calls the Windows Sleep API. Can you post your script? Do yo have a log showing the problems? Pete

It needs a fix in P3D4 itself, which will be in the next update from L-M. I should have mentioned that in my release notes. Yes, the PMDG fix was actually released before 5.102 so I thought it wouldn't be a problem to do things right in FSUIPC code. No, that actually affects the link between the PMDG code and Squawkbox, linking the PTT and Ident functions. Pete

I'll check into this. Could you post the script, please? Pete

Is that using the on-screen radio switches, or some hardware attachment? Without actually using FSUIPC for something it doesn't really do anything by itself just because it is installed and registered. You don't show your settings (FSUIPC5.INI) file, so I can't check. The log shows an "Logitech Extreme 3D" device connected. Is that involved? Pete

See other thread on this please. I'm trying to use my phone for replies whilst on holiday and it isn't easy.

Is the program 4.801 or 4.80? If not 4.801 try refreshing your cache and downloading again. Otherwise just run it twice. in 4.80 it wasn't always allowing enough time for AddonOrganizer to make the file, but it still gets made, so running it again works anyway. Pete

Okay. I may look again and possible relent on this and implement via offsets, but there will be a limit on how many times I do this. I expect P3D4 to keep developing and I doubt that these offsets will stay the same. That's the main problem. And it would still be better if folks would apply pressure to L-M for such things to be accessible either via functions or simple exported pointers (the latter only if they never expect the structure to change). This wll wait till I return though, after the 20th. Pete

The currently supported version for FSX and P3D1-3 is 4.968. Please always check for updates before asking for help. All download places for FSUIPC list this version. To check for currently supported versions please see the List of Supported Version thread in the Announcements subforum. Also you will usually find updates and other useful bits of information and programs in the Download Links subforum. Sunforums are provided for a reason. They are a repository for useful things. The forum itself (here) is too large and things eventually scroll off. Please do make use of the provisions made to help. Pete

The read structure includes a pointer which tells the Process where to store the data it receives. That will be 64-bit unless you change it to a DWORD and avoid using it as a pointer, but some sort of offset to your program instead. It is the FSUIPC end which doesn't know about all this -- it doesn't use the pointer at all in any case. Howeverm if it is 8 bytes instead of 4, none of the following parts will be right, so the read will fail, probably just returning an error. Whilst you can convert the existing SDK source to suit 64-bit, it is messy. I will provide a 64-bit version of the stuff in the SDK, but I am away until 20th June now, so it will be later that week. Pete

Neither of those will owrk in FSUIPC5. The facility to change the friction tables is not implemented, as stated. I use the Prosim 738 and have no problems with friction in P3D3 or FSX-SE. it seems perfect, and others who've flown my cockpit agree, including those with experience in "real" simulators. Do you have Prosim working well in P3D4? Is that the A320 version? Pete

Well, I certainly wouldn't agree with that. The only good reason for moving anything to 64-bit is for more virtual memory space Otherwise there is no advantage. The SimConnect libraries from FSX, FSX-SE still work if you need to use SimConnect. For FSUIPC5 there will be an update to the SDK with a 64-bit LIB and so on. I've completed the ModuleUser part of it for the few add-on aircraft which use it, and supplied it to those who've asked. It won't take long to update the SDK for eexternal applications, but I have now run out of time until Tuesday 20th June, when I return fom a short break with my good wife. Please check the dowmloads available later that week. Pete

By "close" you mean reverts to "waiting for connection" I assume. Unless you disable WideServer in the FSUIPC Options it is open for connections all the time you are running the sim. The "Connected" shown on the client will change when it times out -- unless it is hung. Is WideClient responsive to things like the buttons for minimizing or maximizing etc? From what you say I strongly suspect the your TRC programs, whatever they are, are crippling the Client system, and causing the exchange of data between the PCs to slow down so much it is timing out at the Server. The times allowed are quite generous, and if exceeded would certainly make any program you are trying to run pretty useless. Are you sure these TRC programs are suitable for use on a Network? are there any instreuctions with them? And why three of them? The logs you appended did not show any disconnections or other errors. You didn't let either finish but they show nothing useful about what happened. There are many WideFs users with well running networks, but I don't know he programs you are using. Instead of those, just to see if yor Network and WideFS are running okay apart from those programs, try other FSUIPC client applications on your client PC, like my free "TrafficLook" and "Weatherset2" programs (see the Useful Additional Programs thread in the Download Links subforum. I'm afraid I'm out this afternoon, then off until Tuesday 20th June. I expect Thomas will be able to help more whilr I'm away, but he has a full time job too so don't expect the sort of response times I normally provide. Pete

Really? It all looks very different to me. Maybe I got too easily frightened! ;-) Pete

Yes,

With a default aircraft? That is very strange. If the throttle is calibrated in FSUIPC, the latter uses the value that provides to calibrate the lowest axis input (up to -16383) to only achieve the maximum negative value that allows (eg -4096 for -0.25). If you've not calibrated in FSUIPC then I can only assume FS or the aircraft mofdel is doing something strange if you allow siuch negative numbers through. No, certainly not. I'm afraid I'll need to let the author of the methods you are using try to sort it out for you. I have no more time today, and I'm not back till Tuesday 20th. Pete

WHICH version of FSUIPC4 were you using? 4.968 is current. WHICH version of FSUIPC5 are you using? The current version is 5.102 and there are NO outstanding problems with Joystick scnning. I don't support old versions, so ALWAYS check before asking for help, and ALWAYS state version numbers. It is all meaningless without. Additionally, the Log files are needed, AND in all recent versions, for any sort of Joystick question, the file called FSUIPCx.JoyScan.csv (x = 4 or 5). That gives and analysis of every stage of FSUIPC discovering and assigning Joystick devices. Pete

For 64-bit I don't really understand the code -- it looks very different from the assembly code I know (and can actually code reasonably fluently as it was my original langiage, "rising" to BCPL (the predecessor to C, invented in Cambridge, England), and C quite late in life). Therefore I've not disassembled any of the modules. I've only looked at the exports so I could still call some of the functions (e.g. to delete AI, get and set traffic settings and display on screen). It surprises me enormously that tables would be in the same place, or even look the same, because SIM1.DLL is not just data, there's a lot of code there, and that most certainly won't be the same size. In most of the versions of P3D (every release and most Betas) things like the locations of those tables changed each time. I really don't want to start having to search each time. I would prefer folks apply pressure on L-M to get these things made accessible instead, in whatever way is appropriate to their methods. Even exporting the address of the tables would be sufficient, something which would not be any effort for them. Pete Pete

There's no such thing as "FSWide". FSUIPC contains the server part of WideFs, or "WideServer". And I really don't know what you mean by "transfers three TRC programs"? WideFS does not move programs. Perhaps you mean allows them to talks to FSX? There again, the same thing. WideFS does not transfer programs. If you are hoping that these programs will run on the Main Computer, you must install them there. You are very confused! There is NO communication between WideClient and WideServer until both ends confirm the connection. The "connect" signal means they are connected, that's why that wors is used. Before that they are NOT connected! And the commuynication is not "cut", it times out. Something is stopping the free flow of data between them. Maybe those three programs, when running on the Client PC, are not allowing WideClient sufficient processor time, forcing the communications to time out? Try not loading them at at. See if WideClient stays connected without them. Did n't you try my other idea, of using UDP and Broadcast mode? Pete

Have you located the tables in the 64-bit module? Pete