Jump to content
The simFlight Network Forums

Pete Dowson

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Pete Dowson

  1. 1 hour ago, Tigerhawk said:

    I am on Windows 10 Pro - build 19043.1202

    Hmm. It is working here with the latest MSFS WU6 and Windows 19043.1165. I'll try updating to 1202 (or later?) to see if that makes any difference, but to be honest I'm perplexed. It is definitely related to long pathnames, but what the steps outlined in the Mcrosoft help on that don't help i don't understand.

    Did you try both suggestions? if not, please do try the other.

    Meanwhile i'll investigate whether I can "fiddle" it by changing "current directory" and using just the local path, or maybe automatically creating linked folders with shorter names.  In fact you could try that manually. See


    A symbolic link to "C:\Users\David Hawxwell\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe" might work.

    Otherwise, the changes I would have to make to MakeRunways to use partial pathnames are rather complex, as the files it generates go locally.  I'll have to "tread carefully". So it may take a week or so before I have anything to test for you, but I'll definitely take a look at this.



  2. 8 hours ago, Tigerhawk said:

    Hope this helps.

    Thanks. This is identical to a problem reported in the Pilot2ATC forum on AVSIM.

    The problem is that your Windows 10 (I assume?) appears not to have long pathnames allowed.

    The normal maximum is 260 characters, but this restriction can be overridden by using the \\?\ prefix.  You'll see that in the list of folders to be scanned in your Runways.txt file.

    I'll reproduce my answer given to that other user. If this turns out to be a common occurrence I will probably have to add this advice to the documentation.


    From Windows documents I'd assumed the \\?\ prefix would work no matter which build of Windows is being used -- it was okay on three different versions on PC's I have. However, comparing the last line logged on your system with the file generated on mine, the very next line which should have been logged would show a pathname longer than 260 (discounting the "" envelope, which isn't used in the actual windows calls). And that's the first path longer than 260, at just 261 characters!

    Perhaps I should log also the version and build number of the Windows version in use. But could you tell me (use WinVer) please? And maybe try to update.

    Using Google I have found this:

    4.3 Enabling Windows Long Path (Windows 10 - 1803 build)
    1. Click Window key and type gpedit. msc, then press the Enter key. ...
    2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem.
    3. Double click Enable NTFS long paths.
    4. Select Enabled, then click OK.

    Could you try that please?

    There's also a way of editing the Registry instead. See


    Let me know please.



  3. 5 hours ago, MarkStallen said:

    f you just put it on with no other software at all and you turn for instance the heading button, then the display is showing 001 to 359 degrees without sudden movements. It does that on its own, without getting inputs of other programs. It's in the hardware of the Combo.

    So it isn't displaying the actual values in the Sim, is it? Seems little point. Surely when you are using the proper software with it, it is that which changes the displays? Otherwise how are the displays changing differently with FSUIPC running -- after all, all FSUIPC is doing is receiving the button presses from the encoders. It isn't sending anything back unless you've added something like LINDA or your own Lua plug-ins to update the displays.

    5 hours ago, MarkStallen said:

    So the question is: does FSUIPC send things to the combo without any LUA -scripting or assignements to the combo?

    No. It doesn't know what to send or how without additional software.

    5 hours ago, MarkStallen said:

    I don't use VriSim or SerialFP2. I don't need them.

    I'm sorry, I can't really help then. It was all designed to work the way it is documented. And that was many years ago. In all that time we've not had any other folks reported the problems you seem to have, but then I expect they are following the documentation.



  4. 10 hours ago, Tigerhawk said:

    The only file generated in the MakeRwys folder is the Runways.txt file.

    And what does that say (the clue will likely be in there)? What has changed since it worked for you? Have you added scenery to MSFS since then? And what exactly is this "windows user account control box"?

    Don't forget -- you must run it "as administrator", otherwise it probably won't be able to access the scenery files (depending how you installed MSFS).



  5. 4 hours ago, Luke Kolin said:

    I have a question - is there an enumeration of what offsets are being used by third parties?

    We have many registered for third parties, yes. But we don't publish those details. It's left to them if they wish to (for example, Project Magenta publish their own lists).

    4 hours ago, Luke Kolin said:

    I'd prefer to have a 64-byte block of offsets but I'm unsure as to whether I can reserve such a block

    If you ask I expect you can be accommodated -- John is in charge of that now. Send him a PM.  If you describe your application it would be best as it may be obviously one which would never clash with some other app which has a range of offsets, so making it more easily granted. Such an example would be SimAvionics v ProSim v Project Magenta -- no one would use any two of those at the same time as they do similar jobs.

    There are also a number of areas which have been reserved but were for applications never updated for use with today's sims,  However, some of those we would just be guessing as we've lost contact with the authors.



  6. As well as what John has told you, FSUIPC's inbuilt VRI facilities only deal with inputs -- switches etc which you can assign. It does not handle displays at all. You need to address whatever it is handling the displays. In the solution suggested by us, as described in the Lua Plugins for VRInsight Devices document, the Lua plug-ins needed  for proper support depend on using SerialFP2 and the twin ports as described.

    That document also confirms that the correct COM port speed is 115200, but, anyway, yours must be correct for the device to be correctly identified and logged, as I explained before.



  7. 18 hours ago, MarkStallen said:

    If you use FSUIPC, you don't need vrsim or serialfp2. Most buttons and rotary switches for my combo are programmed in the button-section of FSUIPC. The only thing what LINDA does for me (for instance the heading) is indeed writing 07CC back to the combo-device.

    So if I disable Linda then I can turn the heading knob FSUIPC executes the events and that works fine in the sim but the display of the combo does not match the heading shown in the aircraft. Using Linda matches the display with 07CC.

    Ah, I see. So without LINDA what are you using for the display? How are you expecting the display to work?  I thought you needed to rely on SerialFP2 (or maybe that newer program). I think that is why I always used a pair of virtual ports to link SerialFP2 to the device with FSUIPC sitting in the com chain.  SerialFP2->VPort1-linked to VPort2->FSUIPC->RealPort.

    If it works okay with LINDA why do you not want to use it? You need something to drive the displays.




  8. 47 minutes ago, MarkStallen said:

    If I test with VriSim or serialFP2. then turning doesn't give a jump an the combo display.

    I've never seen or dealt with "VriSim". That must have come along a while after I ceased VRI development. In my days with VRI stuff I seem to remember that "SerialFP2" was needed. Is its function now superseded by LINDA on your system?

    I think perhaps that you need LINDA support?

    The COM port settings must be okay because the log shows the device recognised and named:

    1735 VRI FMER ("MCP Combi") detected on port COM3

    so it's either something to do with the way you are interpreting the inputs, or more than one program trying to adjust the same values. What interprets the encoder movement as button presses? Is that in LINDA or one of your own plug-ins? In our document "Lua plugins for VRInsight Devices" we provide an example
    "VRI_SetMach: An example for the MCP Combi Device", but this depends on setting it all up with the pair of COM ports.

    I can only assume that LINDA takes it all on by itself?




  9. Error 0xC0000022 is:

    ERROR_WRONG_DISK  34 (0x22)
    The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1.

    I think I've seen this spurious MSFS error reported in the MSFS Forums. Assuming you are not running the boxed version (which I've read needs Diskette #1 mounted) then it seems likely to be an MSFS installation problem.



  10. 15 hours ago, bodmore said:

    This is with the default Cessna 172. When FSUIPC is used to control flap movement the buttons presses are either ignored or else result in erroneous flap movements (such as over or under flap movement). If I use the FSX button control assignment to assign flap incr/decr to the X52 buttons everything is fine. Likewise, the FSX F6/F7 direct flap controls work fine. I have tried various "two way centre-off switches" on the X52 with the same result. So there may be subtleties in using FSUIPC for this function which escape me and I'd like to understand this.

    If you assign one button to FLAPS INCR and another to FLAPS DECR, then irrespective as to whether you do this in FSX or FSUIPC, that's the only thing which is sent. Just don't select "repeat" for the buttons in FSUIPC.

    And if assigning in FSUIPC do not also assign in FSX.

    There's really nothing else I can say, it is really that simple.  

    In case something else is interfering in this very simple action, try using Event logging in the FSUIPC logging options. That logs events like those FLAPS ones as they reach FSX not matter how you have them assigned.



  11. 29 minutes ago, Knox1423 said:

    It was set to 9600, and I read that's where it should be. I just remember coming across a note where there's a certain type of PFC module that requires 19200, so I tried that, but defaulted back to 9600 since it didn't change anything.

    This is a great lead. I'll go ahead and order a serial ports card for my computer to give that a try and see what I come up with. I'm not at home at the moment but will double-check that I have the correct files later.

    During my testing, I tried a number of different planes, just in case. I tried a single-prop, double-prop, and twin-engine jet. I have the same throttle quadrant shown in the picture you attached - 6 levers, 2/2/2, same colors.

    I really appreciate the advice, and will update when I get further.

    Thank you!

    For serial ports I can thoroughly recommend those by Brainboxes. They are more expensive that the majority, but all mine have been superb over many years.



  12. 1 hour ago, Knox1423 said:

    I navigated over to FSUIPC, then to the PFC Add-On. I went to the Flight Controls tab for configuration, and noticed the Aileron input was changing without me moving the yoke. When I checked the throttle controls, two of them were jumping between inputs as well. I went through every calibration tab, enabled the appropriate column for which I had control (e.g. yoke, throttle, cowl flaps, etc.) and  tried testing/calibrating. None of them seemed to work though; the only input being shown was the random input number changes that wasn't me.

    I've not actually ever heard of, or seen, a Cirrus Console which wasn't using the USB (HID) system. That sounds like a very early model which I never knew about. You mention a DB9 to USB connector. Are you sure that's not delivering a true USB signal? Which PFC DLL are you actually using? The PFCcom64.DLL is for the COM/Serial port systems whilst PFChid64.dll is for the later USB/HID devices.

    I honestly can't think of anything in the PFC DLLs which would give the results you see, unless it is something silly like the wrong serial speed being set for the COM port. But then I wouldn't really expect the initial checks to pass.

    For my PFC gear I always first checked everything with the test and setup program supplied by PFC themselves. Haven't you got that? If not perhaps you could look at whether there's a download facility on the PFC site. If not please do contact PFC Tech support.



  13. 28 minutes ago, nantelp said:

    I have found a way by assigning a button on my joystick to arm/disarm the ground spoiler. But I am not able to configure the arm on my PFC to manage the speed brake arm.  
    I have separated the arming of the ground spoiler from the speed break movement, is this ok? 

    The calibration facilities for the spoiler/speed brake axis allows for a region to be set for the "ARM" action. It is rather futile trying to use a button to Arm it, as the FS/P3D spoiler axis includes the Arm action part way through the axis movement, and that area is unavoidable when moving away from full down to any raising of the spoilers. Try to calibrate the Arm position in the calibration to the area so marked on your lever.



  14. 17 hours ago, aua668 said:

    So as you can see, the function is fired immediately, when I register the offset, although frequencydid not change

    But effectively it did change from the zero or null which would have been assumed it started with. In the case of a radio frequency I would have though it useful for you to react to the initial value, as if it had changed.

    Most of my Lua plug-ins use the fact that you get the initial value to, er, get the initial value.


    As a consequence I would have now to add similar code to all my event functions, to avoid firing during the event registration process.

    I don't understand why you need to ignore the initial values?


    As I currently have massive problems, where events are not registered although they are defined in the same way since many years, I try to nail my problem down. 

    I don't see why event registration could fail just because it fires initially? 

    Also I doubt whether it applies to all events -- some are due to a true event, like those joystick ones detected by scanning, like button presses (though possibly a latched button press will fire initially to show that the switch is 'on'. I don't recall without checking the code (which I'm not doing today)).

    Aha, I see John has found that it is specific to Offset events.



    • Thanks 1
  15. 11 hours ago, Adooli said:

    Would installing FSUIPC in admin mode help? Or running it in admin mode? That is if either is possible.

    FSUIPC is a DLL module which, when running, is part of FSX. So if you run FSX in Admin mode (which should NEVER be necessary), then FSUIPC, being part of FSX, will be in Admin mode.

    Then any and all FSUIPC client programs must also be in Admin mode, or they won't get connected.

    If you can't get it working either way then it must definitely be a problem with FS_COM. I don't think anything else can conflict with that. So you really need CP FLight support.

    Ah you sure it is communicating with its devices? Didn't you say it was a USB link? Maybe it's just a configuration problem? Or USB3 v USB2. I think a lot of USB devices aren't compatible with USB3.



  16. On 8/25/2021 at 2:15 AM, Adooli said:

    When I launch FS_COM (the CP Flight addon) it shows up that it is connecting and then nothing and does not connect to the Sim

    The Log shows that FSUIPC is running okay, When you say FS_COM says it is "connecting", does that just stay like that? Isn't there any error message?

    I would guess that it isn't able to connect because you are running FSX in Admin mode, but not FS_COM (or vice versa). Programs running at different prililege levels cannot exchange data by the methods used by FSUIPC.

    If that isn't it then you really need to talk to CP Flight, as only they can debug their program or analyise their logs.




    Please never post support requests into reference subforums. They are clearly marked "not for support"!

    10 hours ago, Adooli said:

    CP Flight uses the Simconnect.dll to link with FSX/PMDG via FSUIPC.

    That makes no sense. It either interfaces to SimConnect, or to FSUIPC. Both are interfaces to FSX.

    As far as I know, nothing by CPFlight uses FSUIPC. If it does use FSUIPC, then with FSX running in Admin Mode, so much all the software wanting to talk to FSUIPC.

    If you think it is supposed to work through FSUIPC, then please show me the FSUIPC4.LOG.




  18. 5 hours ago, Thiago Duarte said:

    In this configuration, I have no way to calibrate the spoiler directly in FSUIPC, because the Arduino is not recognized as a USB JOYSTICK. That's why I need to use MOBIFLIGHT.

    I'm afraid I know nothing at all about MOBIFLIGHT.

    5 hours ago, Thiago Duarte said:

    Now when I return the offset to 0BD0 (SPOILER) I have no success. It appears that something is preventing it from extending and moving the spoiler lever. As I also said, this same code for the spoiler works on STANDARD FSX aircraft like Airbus and Boeing.

    That sounds like that particular aircraft does its own thing, ignoring the built-in FS spoiler logic.

    5 hours ago, Thiago Duarte said:

    I believe it has something to do with this range from 4800 to 5619, and when the potentiometer value goes through it, it must be going into the range of spoiler armed function and thus blocks the operation of the spoiler lever.

    No.  That cannot be if the FS spoiler logic is used. To start with, if you try to test on the ground then as soon as the value 4800 is passed the spoiler will fully deploy, just as they would when you land with armed spoilers. All that is different for spoilers compared to other flight controls is that the range 0 to 4799 does nothing.

    Note that even with your raw axis values you can calibrate spoilers in FSUIPC by writing the value to 3BB2 (or in fact any of the offsets 3BA8 to 3BC4).  Then FSUIPC will detect is as if it was a USB joystick interface, allowing you to calibrate it properly. Then you wouldn't need your formula.

    However, it sounds like that aircraft takes no notice of the FS spoiler. You need to find out (from documentation of the author) what you can use. Maybe you need to assign it directly to Axis_Spoiler_Set and not calibrate. That would deal with it assuming the aircraft logic traps the control directly, but then you'll need your formula applied.




  19. 1 hour ago, GillyTheKid said:

    It is indeed not writing to the log

    You mean not writing to the offset 0330, I assume.

    1 hour ago, GillyTheKid said:

    what would be the reason for this and is there any was to fix it?

    It's got to be that the STD button in that aircraft is not doing what it should. You need to get the author to fix it, I can't.

    1 hour ago, GillyTheKid said:

    The hotkey option within FSUIPC itself.

    Ah! that's "Set standard altimeter" -- I wouldn't recognise it as "Q1013".

    1 hour ago, GillyTheKid said:

    Just an addition to this - it seems like it may be an issue with the FSLabs. I ran two tests, one with the FSLabs and the other with the PMDG 777. Both named log files are attached below. PMDG 777 clearly writes the correct offset value, whereas the FSLabs is just not writing it at all. 

    So you need to ask FSLabs what is going on.

    Note that neither PMDG nor FSLabs aircraft use or depend on FSUIPC. They'll be setting the pressure value via SimConnect -- or should be, at least. FSUIPC interfaces to SimConnect to read the value and populate offset 0330.



  20. 2 hours ago, cellular55 said:

    thanks a lot.. but I do not undestand where I have to specify the number of seconds

    You simply use the function to PRESS the key(s), then use ipc.sleep for whatever time you want, then use the function again to RELEASE the key(s). Sorry, but I thought that didn't need explaining. 😞



  21. 2 hours ago, GillyTheKid said:

    I do change to barometric pressure to STD above the TA, but it does not seem to effect the level displayed on Merlin. It still reads it as the pressure that I had previously in below the TA; the flight level shown is a reference to the QNH I had previously, rather than that shown on the PFD on the aircraft, with STD selected. 

    You need to Monitor offset 0330 (FSUIPC Logging Tab, right-hand side, offset 0330 type U16. For 1013 that will read 1013x16 = 16208, or if it sets it more accurately (1013.25) then 16212.  check the option below to write it to the log.

    If your STD button is not writing this value then that will explain your problem.

    2 hours ago, GillyTheKid said:

    I managed to work out some sort of work around by assigning a key directly to Q1013 in FSUIPC itself

    Sorry, you need to explain that. "Q1013" isn't a control recognised by FSUIPC.




  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.