Pete Dowson

I sometimes got trouble with BGLMANX.DLL. I think you might try changing the order of loading in the DLL.XML. I've had it clash with other DLL modules too, not just FSUIPC. You could also try re-running the AddOn manager after removing BGLMANX from the DLL.XML file. I think it's something to do with the problem SimConnect has always had loading modules. I think you'll find that FSUIPC itself is not even getting to run, so there's no code I can change to help at all. Pete

In that case it is definitely seeing the buttons and switches! ZIP it up and send as attachment to petedowson@btconnect.com. Thanks, Pete

Hmm. It all looks okay as far as you went. all of the correct data about your devices is read and the correct entries recorded ready to detect buttons and axes. However, I notice you closed it down pretty soon after it was all ready to fly. Did you press any buttons or move any axes? One more test, please. Change the LogExtras=x200200 to be LogExtras=x1000 then run the sim. Press each button and move each axis whilst in flight mode, then in FSUIPC Options "Buttons & Switches" for buttons, Axes for axes. Show me the log from that, please. I'm running out of ideas. No one else has ever had a problem like this, where the devices are detected but never supply any data. It's a real puzzle. Pete

When I first made FSUIPC, back in FS98 days, there was no "API" provided, no interface to work to. It was made by 'hacking' into the code in the simulator itself. I have been a programmer since 1963, working on the old giant valve and discrete transistor based computers of the time, and working from the bottom up -- machine code, assembly code (after writing an assembler). This gave me a good basis for understanding computers at a very low level and therefore getting into the innards of FS. Since FSX, add-on programmers have been rather spoilt by being supplied with an API (SimConnect) and full documentation on how to program for it. If, as you say, you are actually supplied with an API for ETS, then what is the problem, exactly? You want me to read it and explain it to you? Without knowing anything about ETS there's really no way I can do that. If you know what you want to do, and you are a programmer and have the tools, what else do you need? Pete

Not sure how I can guide you. What do you need to know? Pete

Hmm very strange. Do you have any other software installed which may be handling the affected devices? For instance a Saitek program? You say the rudder pedals are okay, so I don't understand how it cannot see the others. I'll need more logging. Please edit the FSUIPC4.INI file (in the Modules folder), adding these lines to the [General] section: Debug=Please LogExtras=x200200 Then run FS and try again. Please then show me the Log. Pete

Yes, it is because the parameter in FSUIPC is signed (it needs to be as many controls use signed values), and the positive value 2147483648 cannot fit into a 32-bit signed value. Try -2147483648, or even x80000000. Either will work. No, sorry. That's a function of the FS mouse options in gauges. I expect the answer is in the Microsoft gauge SDK somewhere. I know all the mouse action values are single bits -- i.e. each of the 32 bits in the parameter has some specific meaning. Pete

Well, you appear to have omitted the first line which tells me the version of FSUIPC. Please don't do that next time. FSUIPC is running fine, so it looks like it cannot find PFCFSX.DLL in the Modules folder. To confirm that, please download this latest (as yet unreleased) version and copy it into the FS Modules folder: FSUIPC4948f.zip Then edit the FSUIPC4.INI file (it is a simple text file, like the LOG), adding Debug=Please LogExtras=1 to the [General] section. Then run FS again and show me the log (the complete log this time, please). Also, try running FS "as administrator" (which is, I think, a right-click option on the EXE or icon). See if that makes any difference. Pete

Okay. From the INI file I see that all three devices ARE recognised by FSUIPC and do have assigned ID numbers (0, 1 and 2):: So, let me ask you, where exactly are you looking when you say the button presses and axes aren't recognised? Have you seen the pinned thread at the top of this Forum, entitled "IMPORTANT: FSUIPC calibration of axes in P3D version 3"? If that describes your problem then you can either use the suggested work-around or wait for the imminent P3D version 3.1, in which I think this will be fixed. Pete

Well, FSUIPC cannot engage 2X mode of its own volition, but certainly an application could. It might be sending a "SIM RATE SET" control, or writing to FSUIPC offset 0C1A. Try adding offset 0C1A as type U16 to the Monitor section on the FSUIPC Logging tab, checking "Normal Log" below. Also enable Event logging (no other, just event). Do NOT press the "New Log" button. Make the problem happen then check the log (FSUIPC4.LOG in the Modules folder). Paste it into a message here if you want me to look at it. BTW I've never heard of "FSXFlight". It isn't an FSUIPC application of which I am aware. Pete

Well, certainly some information to start with. If P3D is crashing, where are the crash details? If you think FSUIPC is involved I also need to see the FSUIPC4.LOg, which you'll find in the P3D Modules folder and which you can paste, along with the crash details from Windows Event viewer in a message here. The fact that you previously got the same error with a different aircraft and without FSUIPC4 does appear to indicate that your problem lies elsewhere. Pete

Thanks. I'll add a check on the Build Number in the next FSUIPC update. Waiting for P3D version 3.1 release at present, supposedly "before the end of the year" they said! ;-) Pete

Aha! According to all the Web references I can find, version 6.3 is Windows 8.1 FSUIPC should report 8.1 not 8.0. Which means internally Windows is actually saying it is version 6.2! What a mess! I really can only go by what Windows tells me. It's a good job it makes no difference to FSUIPC. Maybe I'll change Running inside Prepar3D v3 on Windows 8.0 to Running inside Prepar3D v3 on Windows 8.0 or later since evidently I can't rely on the Windows version function telling me the truth! But first I'll see if I can check the Build Number instead: 8.1 is > 9200, 10 is > 10000 Pete

And are you using Windows 8.0 as FSUIPC seems to think? If you are using Windows 10, what is the actual version number? According to web references it should be 10.0. Anyone with FSUIPC not telling the correct version (and not running in a "compatibility mode"), please do this for me and report the results: How to find windows version number Click Start, type regedit and press Enter to open the Windows registry Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion Find the key in the right-hand panel called CurrentVersion. Its value is your windows version. Thanks, Pete

Hmm. odd. Some much older versions think anything later than Window 7 is Windows 8. But 4.948e should certainly see any major version number greater than 6 as Windows 10 (Vista, Win7, Win8, Win8.1 were 6,0, 6.1, 6,2 and 6.3 respectively). Are you perhaps running FS in a compatibility mode? I think that may make the O/S lie to programs about its version number. Anyway, it has no effect, it's only a logging entry. (Incidentally, I'm still on Windows 7. No reason to move, it is easily the best O/S MS ever made!) There are no differences in FSUIPC for any version of Windows after XP -- XP and Vista were different enough to change how FSUIPC (and especially the Installer) look things up in the Registry. I am not aware of any changes since Vista which make any difference to the functions FSUIPC use. Pete

Really? I never saw one of those. It must be pretty old? If it is in the FSX Modles folder it will be seen and loaded by FSUIPC. And it is FSUIPC which places the entry in the Add-Ons menu on its behalf. I use PFCFSX.DLL all the time for my PFC 737NG cockpit. Perhaps you should show me the FSUIPC4.LOG file also from the Modules folder. Paste it into a message here. You won't get one for PFCFSX because it isn't loaded by FS, but by FSUIPC. I wouldn't worry if you didn't get one for FSUIPC -- if the Add-Ons menu entry is there for it, it is loading okay. Pete

FSUIPC4 is different to FSUIPC3. So I won't comment on your difference in results from FS9 to FSX. FSUIPC3 is no longer under development and I no longer have any way of checking it in any case. FSUIPC4 operates IDENTICALLY on FSX and P3D. there is no difference whatsoever in any area relating to axis, button, key assignments nor the control set. Assuming you have disabled controllers in both FSX and P3D (essential to prevent cross-intererence) then if you have different results in the two USING THE SAME SETTINGS then the difference is being imposed by either the sim itself or the aircraft model being used. Copy your FSUIPC4.INI file from the FSX Modules folder to the P3D Modules folder. Also note that P3D 2.4 is out of date. If you are staying with version 2 and not purchasing version 3 you should at least update to version 2.5. Pete

If you have a Profile naming the PMDG 737NGX then it will only come into force if you load an aircraft which is listed for that profile. If it is active for other aircraft then you MUST have assigned that aircraft to that profile. To remove it from the Profile you must edit the FSUIPC4 INI file and delete its name in the relevant [Profile...] section. If you don't understand Profiles, take a moment to read some of the User Guide for FSUIPC. If you want help fixing your settings, post your INI file here -- paste it into a message. Pete

Did you not get any documentation at all from PFC? I don't actually support PFC myself, they have their own support. PFC.DLL 2.41 will not work with FSUIPC4 as it is the version for FS9, as clearly shown. The one for FSX and later is PFCFSX.DLL. Why are you downloading the wrong module? Futhermore, both those drivers are for the old-style serial port devices which PFC used to make. The Cirrus 2 Pro which I used to have was not a comm/serial port device at all, but a full blown USB HID device which most certainly should at least be seen by Windows. The freeware driver I made for PFC HID interface devices, including the Cirrus, is PFCHID.DLL. Pete

Very clever! Maybe you could write it up and post it to the User Contributions subforum.? Others may want to do something similar. Pete

Out of the very long time of 36 seconds (!) you allowed FSUIPC to check your frame rate, at least 10 seconds was whilst it was still loading stuff, initialising the system ready for flight. Why stop it then and close down? You aren't even giving the system a chance! Anyway, FSUIPC has nothing to do with your low frame rate and certainly has absolutely nothing to do with sound. If shutting the sound off fixes your performance then it is more likely to be something to do with your sound system, maybe the driver, maybe a bad install of P3D, don't you think? Tell me: how on Earth do you decide to blame FSUIPC? Just because it reads the frame rate from SimConnect? Blaming the messenger? If I were you I'd go visit the P3D Forum on AVSIM to get advice on P3D performance issues. And if the folks there can't help, report it in the Lockheed Martin forums. I think you are in the wrong place here. Pete

Sounds like an automatic FS assignment. Have you disabled controllers in FS itself? Check. Or at least de-assign the switch there. FSUIPC cannot stop FS using switches, buttons and axes. You have to make sure there aren't dual assignments with those you make in FSUIPC. Pete

Ok. I think I've fixed that. I'll test a bit in the morning then let you have a copy to test more thoroughly. Pete

The longest name I found was 28 characters long. So this can be used as a guideline for the length. With 30 chars I believe you are on the safe side. For the own cameras you can influence the length of the camera name. The only uncertain names are the aircraft cameras, which are defined in the aircraft.cfg files. Anyhow you can shorten names there too. So if someone is so experienced to control cameras from LUA, he/she should also be able to edit names of cameras ;-) I'd round to a nice 32 bytes. I've implemented it but it won't work at present because the "...ByName" function isn't in any of the FSX SimConnect libraries so I have to recompile my wrapper, SimConnectP3D2.DLL with that function supported. However, I can't get it to compile with either the P3D v2 SimConnect.lib or the version 3 one -- different errors, unfulfilled imports. I've no idea at present how to satisfy those (the P3Dv2 one needs an "Exception" Class and I've no idea where that comes from). So I've put a request for help on the developer section of the L-M Forum. Pete

As noted in the FAQ subforum thread on lost keys, you need to retrieve it from your SimMarket account. I don't issue the keys myself, it is all done by SimMarket. Pete