Jump to content
The simFlight Network Forums

Pete Dowson

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Pete Dowson

  1. They don't. Entirely separate interpreters are used. No. ALL of the functions documented in the FSUIPC Lua library document are local to FSUIPC (and mostly WideClient). They are additions to the standard libraries documented in the Lua.org documentation. I expect the P3D implementation includes some or all of those standard libraries. Pete
  2. I thought PMDG were reputed to provide quite realistic aircraft implementations? Have you asked then for advice on this? The curves available in FSUIPC calibration offer extremes both ways. However, I'm not sure PMDG aircraft very much appreciate throttles calibrated by FSUIPC as the way that works bypasses the inputs the aircraft are looking for. If the PMDG parameters set for their aircraft are really so bad (I see you have that for elevator too) then I would have thought they would have fixed it by now. these things are probably adjustable in the Aircraft.CFG file, but I don't know enough about that. I suspect your best bet is to ask in the PMDG support forum. But first also check that your device is properly calibrated in Windows and, if assigned in FS, the sensitivity and null zones as set properly (max and min respectively). Pete
  3. That is a settings (INI file) line to send Ctrl E on a button push. I thought you needed to work via Offsets? And why send the Keystroke? All Ctrl+E does in the sim is cause it to look at its key assignments list and fire off a CONTROL! You need to simply send the correct control with 1 or 2 as its parameter for the Engine. To do that via offsets please look at offset 3110 in the Offsets Status document provided with FSUIPC. To get the control number to be used you could enable Event Logging in FSUIPC then Press Ctrl+E and see what is logged. Or just look for autostart in the List of Controls document also provided. I think it's called "Engine Auto Start". Pete
  4. I seem to recall that to keep the turbine turning you have to keep writing 1 to offset 0892 (etc). Else it reverts. But I wouldn't swear to that. You can of course use the 0D70 to send whichever control the CTRL+E sends. The choice of engine would be the parameter to go with it. Pete
  5. I'm not too sure either as I've never had a call to use them. John knows about them, so I'll ask if he can help. I've had a look at possible changes in MakeRwys to use relative paths, but it's going to be very difficult, affecting so many different things -- so very error prone. I really don't understand what has changed since you used the same version ofMakeRwys separately. I'm sure it isn't a Windows update. Could you be now using different security settings or anti-virus programs? Pete
  6. I have now updated Windows to 19043.1237, and still I have no problems. I'm sure it must be related to that registry item. Can you check again before I embark on rather complex (and possibly error-prone) MakeRwys modifications? Pete
  7. 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 https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ 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. Pete
  8. 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) Click Window key and type gpedit. msc, then press the Enter key. ... Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem. Double click Enable NTFS long paths. Select Enabled, then click OK. Could you try that please? There's also a way of editing the Registry instead. See https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ Let me know please. Pete
  9. 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. No. It doesn't know what to send or how without additional software. 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. Pete
  10. 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). Pete
  11. 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). 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. Pete
  12. Run the FSUIPC4 Installer. If the FSX-SE installation is correct, the Installer will detect it and install itself correctly. Pete
  13. 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. Pete
  14. 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. Pete
  15. 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? Pete
  16. 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. Pete
  17. 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. Pete
  18. 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. Pete
  19. Any luck contacting PFC Technical Support? If you are getting spurious changes in the inputs it does really sound like a hardware problem, and maybe the console itself if the connections are good. Pete
  20. 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. Pete
  21. 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. Pete
  22. 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. I don't understand why you need to ignore the initial values? 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. Pete
  23. Either way would work. You just want the value to be near max and min for each press. You should still set a centre zone too. Pete
  24. 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. Pete
  25. 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. Pete
  • 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.