Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,460
  • Joined

  • Last visited

  • Days Won

    279

Everything posted by John Dowson

  1. FSUIPC will use the FSUIPC6.ini located in the FSUIPC6 installation folder, and will create a new/default one if non is found. It sounds like you have re-installed in a different folder, si when you ran FSUIPC6 for the first time 9in this folder) it would have created a new/default ini, and so it would have no profiles (or assignments). So this sounds like you are looking at the old ini. Just copy this (together with any luas, macro files, dlls, etc) that you are using to your new installation folder. Alternatively, re-install but into the same folder as your previous installation (i.e. where your FSUIPC6.ini with your profiles/assignments is located) If you do not know where your installation folder is, use the 'Open Folder' button in the Logging tab. And, when installing, please take care on the selection of the installation location. If FSUIPC is already installed, it should (always) default to the same location - did you change this? Please see the Installation and Registration guide for details. John
  2. I think your WideFS7 order number (purchased with FSUIPC4) is 1207799. Note that your email address for WideFS7 is ecppassos@*****.com, whereas your email address for your FSUIPC6 license is ep_simp3d4@****.com. As these are different, you need to check the 'Check if using a different Name or Address for WideFS' box, and enter the WideFS Name and Address again. I've verified here and both your FSUIPC6 + WideFS7 license are validated ok, so please try that. Thanks, but you only need one license which covers 1 user, multiple seats. You only need additional licenses if there are multiple users (i.e. for commercial use). John
  3. Please try the following dll - Local Day of Week has been added to offset 0x026C as an unsigned byte (UB): FSUIPC6.dll
  4. Hi Ray, there is a Local Day of Week simvar that I can add to an offset. Give me a day or two and I'll post an updated dll here for you to try (FSUIPC6). Otherwise you could look into lua functions to convert a zulu time to another timezone, then extract the day, but I'm not sure what lua API/functions you would need to do this without investigating.
  5. No, not at the moment - it is something I should add really. Just check the Download page in this forum occasionally, or watch/follow the download page and you will be updated when the page changes, whuch means a new version of something has been released - but not necessarily FSUIPC7. Cheers, John
  6. You don't need the '0039' - that is the index number of the variable, so use: [LvarOffsets.TBM930] 1=L:Generic_Master_Warning_Active=UB0x66C0
  7. Please check your FSUIPC7.log file. You will most probably see that FSUIPC7 is exiting as MSFS has crashed. If this is the case, you need to determine why MSFS is crashing and report to Asobo. There is an issue in FSUIPC7 if using the lvar-to-offsets functionality with a code of UD/SD. This has been corrected in the version posted in the following post, and will be released in the next few days:
  8. Please try again - it was a http link which I have updated to https. A single click should work, if not, right-click and select 'Save as...'.
  9. There is one parameter you could try that stops the CMDRST command being sent to the device - from the Advanced User Manual: ...but I think that was added for issues related to connection (and also closing down) VRI devices. See John
  10. Are you sure? Is that if using LINDA? I have no idea what is making the display erratic, but, looking at the documentation (and also what Pete has said), I think you still need the SerialIFP2 driver if using it with FSUIPC, or check with Linda support. Your logs show that FSUIPC is working as expected. However, some of the runs of the HDG.lua were killed before running, meaning some button presses would have been cancelled by subsequent ones as they are using the same lua and didn't have time to complete. Maybe not an issue, and certainly not related to your problem.
  11. If you re-installed windows, you will also need to re-install the VC++ redistributables from 2015, 2017 & 2019. Please see the section Invalid Key Problems in the Installation and Registration guide,: and this section in the README.txt: John
  12. Hmm, I don't see how this can be.. Without MSFS running, no offset data is populated, and no controls/events are sent. I don't see any point investigating or looking at this without MSFS running (and an aircraft loaded and ready-to-fly). No idea, sorry, as I don't have (and have never used) any VRI devices. Maybe check the FSUIPC & VRIinsight manual (or search the support forums). So, if you close FSUIPC, what is controlling the rotary assignments if your VRISim software isn't running? Ok, more relevant. But maybe better to exclude your lua's for the time being, especially LINDA, if your issue is just with your assignments. Are these the events fired when you turn your rotary: ? If so, what is sending them - I can't see anything assigned to those events in your FSUIPC7.ini file. Maybe you can let me know what/where the assignments to your rotary are (i.e. which lines in your FSUIPC7.ini)? And if its assigned to a lua (HDG.lua maybe?), then please show me that lua. Also, please activate logging for buttons & keys - this will at least show me which device/button number you are operating. And what is driving the display? Is that offset 07CC, the one you are logging? If so, please correct to log as S16. Does the display show the same as the offset (*360/65536)? Also, as another test, please try disabling your VRI device from FSUIPC7, but use FSUIPC7 for logging when you operate the device and the VRISim software is running, so we can see what is logged when it is running normally. Also, please check the FSUIPC & VRInsight document. It does say: You are not specifying the second COM port, but I do not not enough about VRInsight devices to know if this is needed or not. John
  13. I'm not sure I understand your issue. Please activate logging and see what is logged in the different situation. You probably need to log Buttons & Keys and also Events, but if your rotary works on an axis you also need to log Axes controls. I don't have any VRI devices and no nothing about VRISim, but if your assignments are done by VRISim, why have you also assigned in FSUIPC? Wouldn't your rotary be assigned in both, giving such issues associated with assigning in multiple places? And I don't think its worth testing without MSFS running, and certainly not when using FSUIPC7.
  14. Ah, yes - this can happen if you are changing screen sizes/resolution/etc. You just need to remove the Window ini parameter from the [General] section of your FSUIPC7.ini file so that it reverts to the the default size/position. I am also looking for a multi-screen solution for MSFS. I'll take a look at this, thanks. John
  15. Then use a flag for the compound condition, and set/clear the flag on your 'shift' button. This is also explained in the same section of the Advanced User guide.
  16. Not sure I fully understand this...why would the hat switch have double the number of functions, especially as you are already holding down one of the hat switches, so how can you trigger the others? Or do you mean that you are using a button (hat switch or otherwise) as a type of 'shift' key, and holding this down when you press another button triggers some sort of virtual button instead of the original button? We usually don't recommend using other config software if assigning in FSUIPC. FSUIPC reads your device directly at a low level and probably won't see these 'virtual buttons'. To achieve something similar in FSUIPC, you can use the Compound Button functionality, which allows you to specify actions for one button which are dependent on the state of another button (or switch). See the Advanced User guide for details (P22 in the FSUIPC6 manual).
  17. Ok, then you need to uninstall and re-install some VC++ redistributables. Please see the provided README.txt: I wouldn't do this just Yet. That error is most likely shown when MSFS tries to start FSUIPC7. However, it certainly shouldn't crash the sim - it should just prevent FSUIPC7 from starting. Anyway, uninstall and re-install the VC++ redistributables and see how you get on.
  18. Does MSFS run without FSUIPC7 installed? Can you manually run FSUIPC7 (without MSFS running)? I see Pete has also replied: Uninstalling FSUIPC7 and running MSFS would verify that it is an MSFS installation issue. If its an MSFS installation issue, then check the Asobo forums and/or raise a ticket with them.
  19. Great! Please try the attached version: FSUIPC6.dll
  20. So MSFS is crashing even before it even tries to start FSUIPC7? It is the EXE.xml file that is created or updated, not the .exe. Did you install the FSUIPC WASM module into your MSFS Community folder? If so, try (temporarily) moving it out of your Community folder to see if that helps. Do you have anything else installed there?
  21. Please try with this version: FSUIPC6.dll I can only see it occasionally in event.button, but I've added some extra logging around event.offset in the dll above.
  22. Ah, sorry - I attached a debug build rather than a release build so you will be missing some windows dlls to run that. I'm going to add some more logging and I'll post a correct build later today for you to try.
×
×
  • 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.