Pete Dowson

Thanks. I've fixed it I think, and tested briefly with my own script. I'll make an interim release, probably 5.102a, on Thursday all being well. Pete

Fair enough. Goodbye. Pete

You still have not shown us the FSUIPC4.LOG file!!! You have only attached an abbreviated part of the INI file WITH NO DEVICES SHOWN detected at all!! Sorry, but i don't understand that part. CSV files do NOT "kill" anything. Please add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 Then run P3D again. Show me the FSUIPC5.LOG file and the CSV file again, please. Pete

Are you saying you had controllers enabled in P3D, yet were asdsigning in FSUIPC? That is a complete no-no and will likely give all sorts of problems. Either use FSUIPC for assignment OR P3D, do NOT mix them! Whay has "Profile Specific" got to do with it. dod you only have throttles assigned in a specific profile for the PMDG aircraft? Sorry, where are you talking about assigning now? I'm confused altogether by your message i'm afraid. I don't know where you started from now where you are going to. Just a clarification. Assigning in FSUIPC to "Axis ... Set" contorls, for ANY axis, with Controllers DISABLED in P3D, is exactly the same as not assigning anything in FSUIPC, enabling controllers in P3D, and assigning the same axes there. Pete

Thanks for all the info. My colleague Thomas has been doing some testing and experimenting on this and has confirmed that there's something very off going on just with the SWAP control. FSUIPC does intercept all controls, just so it can log them, but t doesn't stop them going through. Something odd is happening with that one. It seems to be something odd with P3D4, just with that one control, when it receives it from FSUIPC instead of directly. I'll be investigating in the morning. I may have to get L-M to look at it, because FSUIPC is certainly not doing anything different than it has always done, with FSX, FSX-SE and all P3D versions. And there are hundreds of other controls all teated the same way, such as those actually used to set the radio frequencies in the first place. in fact every single thing you can assign in P3D or FSUIPC. Pete

Only one FSUIPC5.LOG file, which I identified by name.That's the run-time log, and if there's a crash, where it finishes is informative. The Install log is a record of what transpired during Installation (hence the name!) and not relevant once it is installed correctly. It would have been in the MODULES folder, where all FSUIPC files are. You just said yourself that's where is is! Yes, but I said "if a log is produced" if you look back! And if one isn't then whatever log was there would have shown how the previous session ended, which would have been very relevant. Do NOT delete FSUIPC files. There is never any need. You said FSX crashed when you closed it. If you refer back, that was when you provided the Windows crash data and another copy of the INI, but not LOG again. The FSUIPC4.LOG file is ALWAYS important, on ANY support request for FSUIPC4 in this Foum. It has a lot of essential information and saves a lot of time and multiple subsequent questions trying to find things out. That is why it is produced! Pete

Yes, as I said. It appears to not even discover the airport AFD BGLs, so there's more changes than just the 3 IDs you mentioned. Those only come in once an airport file is recognised. Pete

Thanks! Pete

Where do I get that, please? The Scruffy Duck website doesn't see to lead to it under any category. Pete

Ah, okay. Thanks. Someone did tell me about Aprons, but MakeRunways doesn't process those. But even with such ID changes, the Runways.txt log file should still identify the airports, not just the file path it gets from the CFG file. Pete

It's that sort of crash at the end which sometimes misleads Windows into identifying FSUIPC as the culprit, and so come up with the error next time. This is often because the last threads of FSX running tend to be FSUIPC, whilst it is waiting for plug-ins and WideFS clients to be notified. However, the crash data does not identify FSUIPC at all this time, but part of the PMDG product: PMDG_737NGX.dll So, as you say, you need to visit their Forum. You maybe need to send them this crash log and see if they have a solution. It still may be that your PMDG aircraft is out of date, that a fix has been released. BTW you STILL have not supplied an FSUIPC4.LOG file, which is always the MOST IMPORTANT one. Your INI file is rarely needed. Yes, either delete all those entries, or reconnect the device so that it is given a Letter by FSUIPC next time. Pete

So it doesn't even find files it recognises as containing airports? (AFD files)? I'll have to find the L-M definition of AFD's then. One trouble is have no such scenery and don't intend to buy any. Is "ADE for P3Dv4" a new version of Scruffy Duck's ADE editor program? Or do you just point it at the new tools? As it looks like I'll have to recompile some as you did. It's also rather odd that L-M doesn't seem to have compiled the default scenery with anything which wrecks the old AFD recognition. That's why I didn't realise anything had changed. Pete

Yes. That was fixed in 4.801. You must have been running 4.800. And what is issue #2? What has changed? Pete

No. Is "System" the computer name, the one running ProSim? If so it should be entered as \\System Is the whole of drive F: shared on that system? If so you have to give the shared name. It won't be F: If you shared it as F it will be F. There's no : in a shared path string at all. They are just names. Pete

Good. Well done. Ah, that was when we were trying to work out what the problem was -- now we know it was due to PMDG using a 32-bit version of the FSUIPC internal access library to link through FSUIPC to Squawkbox. I have supplied them with the 64-bit version now, but for the time being, in their first quick fix, they've just stopped that link. Pete

You don't need the bitmap for ProSim, only the Rad.bin file. The path to the ProSim on a different computer needs to be the path to the ProSim folder on THAT computer! You need to SHARE that folder so that it can be seen across the network! For instance I have Prosim on a computer called EXTRAS and I shared the path as "ProSim737" so my line reads ASNwxRadarPath=\\EXTRAS\ProSim737\radar.bin Pete

That messsage almost always means that there was a crash in closing FSX the previous time. We need the crash details from Windows -- you can find those in the Windows Event Viewer, Application logs. And where is the FSUIPC4.LOG file from this -- that is the most important thing to see as it might show why? Are any logs produced on the subsequent load attempts? Also, is the PMDG 737 up to date? I remember there were similar problems years ago with one of the PMDG modules, depending on the loading order in FSX. Try uninstalling the PMDG aircraft, testing, then re-installing it. It may have been corrupted. What about the INI file now? If you got as far as FSUIPC "opened without a problem" there will certainly be a new INI file, and that is more important than an old one which has become irrelevant. Both LOG and INI files are important, please. Your "old working (?) INI file" shows 2 devices connected -- a T.16000M and a Saitek X-55 Throttle (no X-55 stick part?). This are devices 0 and 1 assigned as A and B respectively. However, you have many assignments to a device "3", which wasn't connected. If these were for a device no longer in use, or one of the current devices with a wrong ID from before you started using Joy Letters, they should be removed. Theywill be causing FSUIPC to scan a device which may not be connected and may have a driver which doesn't respond well to that. Pete

For many devices ProSim handles them directly, so you have them connected to the PC on which you have ProSim. If you are planning on assigning things in FSUIPC, then they need to be on the FSX or P3D PC. Interfacing to ProSim via FSUIPC offsets is not a usual way of doing things -- ProSim has assignments for most things. I think you need to check the ProSim documentation and use the ProSim support forum for questions. May own use of ProSim is completely non-standard due to the fact that I'm using a full 737 hardware cockpit all driven via my own drivers. Pete

Can you double check for me please. I found an error which might make event.com call its function but with nil or bad parameters. Could that explain your problem? Try using "ipc.log" at the start of the called function to log the parameters you receive. If that is the problem then I will have it fixed in the next update, which should be this week. If you would like to test the fix for me beforehand, I'll send you a link to an interim update. Just email me on petedowson@btconnect.com. Pete

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