Pete Dowson

Please download version 5.102a from the Download Links subforum. It fixes this problem. Pete

Overworked for sure. Just about finished catching up after my (short) break, and investigating and fixing some bugs or P3Dv4 problem solutions. Will just get 5.102a, or maybe 5.103 out, then next on my list is the 64-bt user library, and sorting out MakeRunways to deal with the new airport data formats -- that might be a big job. Maybe tonight or if not, tomorrow morning. Pete

The source for the LIB is provided. Why not just use that directly? It's small enough to just cut and paste into your code. And you have full control then. I've no idea what "NetBeans" means. The stuff I provide all assumes you use Visual Studio. If you are using some sort of .NET managed code you must use the .NET DLL by Paul Henty -- please see the subforum above dealing with this. Sorrry, but that's unreadable nonsense to me. If you want me to read things please make sure it's at least readable. Pete

The PMDG 777? My understanding is that all three PMDG Boeing products, 737, 747 and 777 use the same methods for their throttle axis control inputs, so the same methods in FSUIPC should apply and work with both. Assign to Axis throttle1 set (etc) in FSUIPC, do NOT calibrate -- i.e. press "RESET" for each throttle in the 4 throttles page in the Calibration tab both with AND without your profile selected. Then, if it works with your P3D assignment, it works through FSUIPC because it will then be doing identical things. That is the way it works in FSUIPC for every one else. It will work for you unless there's something wrong with your 777 installation. Post your FSUIPC5.INI file when you've done, and I'll check it. In your previously posted one you had all your axes assigned Directly (not good for PMDG) AND all Calibrated (not good for PMDG) -- and all without any Profile specific selection at all. In fact, if I now understand you correctly and you actually had problems with no assignments in FSUIPC but all in P3D, then it obviously is a 777 problem. Try uninstalling it and reinstalling. Pete

Well, the INI entries look different. It certainly doesn't match either the Log or the CSV file! Are you sure they are after the same session? Ignoring the INI file and just going by the two files in agreement: 172 Device acquired for use : 172 Joystick ID = 2 (Registry okay) 172 2=Joystick - HOTAS Warthog 172 2.GUID={8868DD00-21F4-11E7-8007-444553540000} 172 Device acquired for use : 172 Joystick ID = 2 (Registry okay) 172 2=Throttle - HOTAS Warthog 172 2.GUID={8868DD00-21F4-11E7-8007-444553540000} The problem as you can see above is that both the Throttle and Joystick are registered with the same joystick ID and the same GUID (which is supposed to be unique). The registry entries for these devices are corrupted. The entries for the Rzer Orbweaver Chroma look rather stange too: Razer Orbweaver Chroma, {4B768EC0-21F3-11E7-8004-444553540000} Razer Orbweaver Chroma, {4B735A70-21F3-11E7-8001-444553540000} Razer Orbweaver Chroma, {4B752F30-21F3-11E7-8002-444553540000} Razer Orbweaver Chroma, {4B75CB70-21F3-11E7-8003-444553540000} Razer Orbweaver Chroma, {52F97860-21F3-11E7-8006-444553540000} Five entries for the same device seems rather, er, excessive, especially with two of them being completely unresponsive, but it is just possibly that devices can make those sorts of connections I suppose. I'd strongly advise unplugging them all, then going into the Windows Device Manager and removing every instance of both those devices, along with drivers if the option arises, Then re-booting the system and reconnecting them so they will be re-initialised in the Registry along with their drivers. Pete

Sorry, that was a typo (see FSUIPC4 at the beginning of the reply and just 4 lines above, where it should have been obvious it was a typo). So, it's the same request but with the FSUIPC4.LOG I've yet to see. Please just update the INI first as stated. Pete

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