Jump to content
The simFlight Network Forums

Scotfleiger

Members
  • Posts

    390
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Scotfleiger

  1. 9 minutes ago, szeliga90 said:

    @Scotfleiger Are you aware whether these Lvars are planned to be exposed in the way FSUIPC7 will be able to use them? If that would be the case is it possible to map them as easy as FS contols/Offsets or would it require something more complicated like lua scripts?

    Also, the Beechcraft Bonanza G36 which I think is included with standard edition of MSFS has the same type of fuel pump switch. So if it's anything you could check and perhaps find out something more I would be very grateful. 

    I am as much in the dark as you regarding Lvars and their inclusion in SimConnect. Normally, default aircraft do not use Lvars, only those from 3rd party developers like PMDG.

    I will take a look at the G36.

  2. @szeliga90 Based on the original MS spec, the control for the Fuel Pump is 66237. This turns on/off all fuel pumps (up to 4). The status of the Fuel Pump switch is indicated by offset 0x3104 (0 off/1 on). You can also use the offset 0x3125 to set the available pumps on/off (bit 0=pump 1, bit 1=pump 2, bit 3=pump 3, bit 4=pump 4).

    There are also controls 66339-66343 that toggle the electrical fuel pumps (all/1/2/3/4). This has the same effect as above.

    I can find no Fuel Pump High option and I don't have the B58 in my available aircraft to check. I suggest this setting is outside the defined offset/control range and relies on internal variables  (Lvars) not yet exposed through SimConnect.

  3. At present, you have to go to the system tray, right on icon and click show to display the FSUIPC7 window. This enables users to confirm that it is connected to MSFS. My suggestion was for the window state (show/not show) be remembered in FSUIPC7.ini so that it returns to the last selected state when FSUIPC7 is started. It does not to be always on top. 

  4. @RainerM if I might chip in here. I do not use SerialFP2 with my VRI MCP panels except to install the FTDI serial to USB drivers. As the support developer I would recommend you investigate LINDA 3.2.6 which works with all VRI combo MCP panels and P3Dv5.

    There is a 30s delay on P3D closing before the MCP is released. This was added to FSUIPC6 to ensure that the P3D background task correctly terminated. This should solve your issue.

    • Like 1
  5. 10 minutes ago, Pete Dowson said:

    BTW do you know why a user with a VRI MCP panel using the SerialFP2, on P3D5HF2, should be having the problem of the process hanging when closing P3D down? I've suggested that he should try LINDA instead -- I assume that then does away with the need for SeriallFP2. Is that right?

    An additional delay was added in FSUIPC6 when it closes to ensure that LINDA could correctly terminate before the VRI MCP connection was terminated. This was because a P3D background task was left hanging. LINDA does not use the SerialFP2. I will read and reply to the thread. 

  6. 5 minutes ago, Pete Dowson said:

    Okay, thanks for letting me know. Seems to imply that the slight slowing down as a result of the logging actually stops something clogging up. You'd think it would make it worse wouldn't you? Ah well.

    I do not believe there is any additional slowing down when reading and writing to VRi Combo MCP panel comport. I found I had a coding error (bad reference) that was stopping me getting the read working. Your advice allowed me to track this down and fix it. Using LUA with ipc.control statements does not show any observable delay when changing data (like heading).

     

  7. Thank you for access to the FSUIPC7 7.0.0-beta (26 Aug 2020). May I make a few suggestions before you formalise the release?

    • The Show window should be made persistent.
    • The FSUIPC7.exe File Description property should be changed to 'FSUIPC7 for MSFS'. At present the Task Manager process name appears as 'IPC Interface and More, for MSFS' which may not be clear to users.

    I have checked the following offsets as set out in offset status 0.3:

    • 0x3124 = Flight Simulator version (1 byte) MSFS = 110 for version 11.
    • 0x3304 = FSUIPC version (4 bytes) in hex 0x70000002 = 7.0.0
    • 0x3308 = Flight Simulator Release (2 bytes) gives '13' (xD) for MSFS (P3D-64 bit was 12 and FSX 8).

    I hope this is useful.

  8. I have been testing FSUIPC7 with LINDA. I am able to output data to the VRInsight MCP panel without problem. However, receiving data (ie buttons) is problematic or intermittent. I was briefly able to read some data but this is inconsistent. Previously FSUIPC was able to log this data for testing purposes. Can you assist?

     

  9. OK. FSUIPC is looking for files in the installation location and nothing has changed. What was the FSUIPC5 installation location? 

    Regardless, the effect is that FSUIPC6 is looking is a different relative location for these files and this risks causing confusion and adding unnecessary FSUIPC6 files to the add-ons directory. Can I respectfully suggest that the reference to the installation directory be changed to place all files inside with the /FSUIPC6 or /Modules folders?

    Andrew

  10. Sorry if it is confusing you but it has confused me and my users.

    I don't understand why the relative install location for .MCRO files has changed between FSUIPC5 (and earlier), namely the enclosing /Modules folder, and FSUIPC6. With the FSUIPC6 add-ons installation, the /FSUIPC6 folder equates directly to the old /Modules and should contain everything related to FSUIPC6 (.dll, .ini, ipcready.lua, etc, .MCRO files and LINDA).

    Moving the macro files reference to the "installation" directory is wrong. It has broken things.

  11. Hi John

    Thank you again. Moving the .MCRO to the add-ons directory alongside /FSUIPC6 works as before.

    With the new P3Dv5 file structure would it not be useful to place all .MCRO files within the /FSUIPC6 folder? This would keep them separate from the many other add-ons that will be installed. 

    EDIT: In the past in the /modules structure the .MCRO were located inside the /modules. This seems to have changed with FSUIPC6.

  12. With FSUIPC6 installed in P3D v5 Addons for P3Dv4 and P3Dv5, a previously working .MCRO installed in /FSUIPC6 is not longer responding the LUA ipc.macro instruction (eg. ipc.macro("FSLTEST2: BAT1)) for aircraft running in P3Dv4.5 (ie. FSLabs A320). I re-recorded some key mouse macros and they proved identical to those I am using.

    I then ran P3Dv5 and set up a new mouse macro and referenced it using the LUA ipc.macro instruction. This failed to work. FSUIPC6.log contains no data relevant to this problem.

    I am using FSUIPC 6.0.8 with LINDA 3.2.x. The problem did not exist in FSUIPC5 or FSUIPC4.

  13. With the alternative P3Dv5 / FSUIPC6 installation using the traditional /Modules with P3Dv5, what is the correct DLL.XML entry? I have been trying the following copied from P3Dv4 but FSUIPC6 is not starting:

    fsuipcp3d<?xml version="1.0" encoding="UTF-8"?>

    <SimBase.Document Type="AceXML" version="3,0" id="dll">
        <Descr>AceXML Document</Descr>
        <Filename>dll.xml</Filename>

      <Launch.Addon>
        <Name>FSUIPC 6</Name>
        <Disabled>False</Disabled>
        <manualload>false</manualload>
        <Path>C:\P3Dv5\Modules\FSUIPC6.dll</Path>
      </Launch.Addon>

    </SimBase.Document>


    The reason for asking is that I am trying to set up the alternative installation for user support testing.

×
×
  • 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.