Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    11,999
  • Joined

  • Last visited

  • Days Won

    241

Posts posted by John Dowson

  1. The log file shows that you started FSUIPC7 manually when MSFS was already running, and it failed to establish a stable SimConnect connection.

    Can you please exit MSFS (and all your MSFS clients) - and also maybe reboot your system. Then restart MSFS, and let FSUIPC7 and let get auto started (presuming you are using auto-start). Once MSFS gets to the main menu, wait a short while to see if FSUIPC7 gets a connection. Once it does, or if it doesn't after a short period, exit FSUIPC7 and then show me the FSUIPC7.log file.

    If you are not using auto-start, please start FSUIPC7 AFTER MSFS has started and arrived at the main menu.

    John

    P.S. Before re-starting MSFS, please change the InitialStallTime parameter in your FSUIPC7.ini to 15, i.e.
        InitialStallTime=15

  2. If things are working, keep it that way. Just be aware that many things won't work when MSFS is in the main menu, and especially when booted to the main menu as many FSUIPC threads will not be running and are not started until an aircraft is loaded and ready-to-fly.

    6 minutes ago, LeoSchoonbroodt said:

    do this when the "Checking for Aircraft auto's" doesn't load the lua which sometimes happens.
    ...
    If it happens again that the auto lua isn't loaded i will attach the logfiles.

    That certainly shouldn't happen, but I think there were some situations where this could happen in the past but these should have been corrected. So, if you do get this again, please show me your logs.

    Regards,

    John

  3. 2 minutes ago, willyj9939 said:

    Thank you, John, for your reply.

    I have moved your post to the FSUIPC7 support sub-forum, where it belongs. Please take care to post in the correct forum for support. You posted in the User Contributions sub-forum, which is, as the name suggests, for User Contributions only, and it does say NOT for support requests.

    John

  4. First, you posted in a FAQ entry completely unrelated to your question. I have moved your post to a new topic.

    2 hours ago, Drrick said:

    ... If i have to redo my PC, and re. install MSFS AND FSUIPC, how can i save my settings that i made in FSUIPC?

    All your settings are saved in your FSUIPC7.ini file, so just save and re-use that. Note that if you re-install windows (and for other reasins), your device GUIDs and IDs may change. This can cause issues but is easily fixed. I can help with this if/when needed.

    Other files that you can save (if using) are the following:
      - FSUIPC7.key file : this holds your registration details
      - *.lua files: any lua scripts that you are using
      - *.mcro : any macro files that you are using
      - *.dll : any additional drivers you are using
      - myEvents.txt file : if you have defined any of your own presets
      - myOffsets.txt : if you have added any simvars to spare/free FSUIPC offsets

    John

  5. 10 hours ago, vanislepilot said:

    As part of that, I noticed that running FSUIPC seems to be causing thousands of repeat error messages in the MSFS dev mode console. Is there a way to prevent these from occurring without shutting down FSUIPC?

    All messages seem to be "Attempting to call Modular Fuel System simvar on a plane that doesn't use it." See attached file.

    This is happening as you have added some simvars to be requested  from the Modular Fuel System in your myOffsets.txt file:

    Quote

        4156     Adding simvar 'FUELSYSTEM VALVE SWITCH:3' to offset 58A0 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:1' to offset 58A1 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:2' to offset 58A2 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:3' to offset 58A3 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:4' to offset 58A4 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:5' to offset 58A5 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM PUMP SWITCH:6' to offset 58A6 (size 1, type 'I32') for read-only access
    ...
          4156     Adding simvar 'FUELSYSTEM VALVE OPEN:9' to offset 58D0 (size 1, type 'I32') for read-only access
         4156     Adding simvar 'FUELSYSTEM VALVE OPEN:10' to offset 58D1 (size 1, type 'I32') for read-only access
     

    You need to remove these entries when using aircraft that do not use the new modular Fuel system.

    This is really an issue with MSFS - it should log (and return) an error once when such a simvar is requested, but it continues to log an error at the request rate, and no erro is returned to the client.

    John

  6. Sorry, but I cannot really help you with python as I am not familiar with this language or the SDK. However, you can also use FSUIPC to log those offsets to check the values, although they certainly don't look correct, although I do not know why.

    3 hours ago, willyj9939 said:

    Can FSUIPC determine what type of a COM1 frequency it is tuned to? Like 127.30 is Approach and 128.25 is a Center frequency.

    Yes, but you have to request this.  This information is held in the indexed simvar COM ACTIVE FREQ TYPE. To read this simvar, you need to add it to a free/spare FSUIPC offset first, using the facilities provided. See the section Adding Simulator variables (simvars) to FSUIPC offsets in the Advanced User guide.

    John

  7. This sounds very strange... However, all FSUIPC does with autosave is to call the P3D function to save the flight, and a P3D function is then later used to load the saved flight. So if there are issues with saving or loading a flight, it will be an issue with P3D.

    Does this only happen with the PMFG MD11? Does the same occur if you save / load the flight from within P3D?
    If it only occurs with the MD11, then you should probably raise this with PMDG.

    Otherwise, you could try re-installing the P3D client to see if that fixes this issue.

    John

  8. Your issue is that you had lvar updates set both in the client (FSUIPC) and in the WASM.

    You did NOT experienced a WASM crash. The WASM is embedded into MSFS and is started with MSFS and closes with MSFS. You had issues with the WAPI, which is the API that FSUIPC uses to connect to the WASM.

    What you have now done is switch of lvar updates in the WASM and are using FSUIPC7 to request lvar updates. This is not a good idea and could get issues in the future with this configuration. Please do the following:
       - Go back and set LvarUpdateFrequency=6Hz (or to VisualFrame) in your FSUIPC_WASM.ini files (both of them, if you are using both)
       - open your FSUIPC7.ini and remove the 
    LvarUpdateFrequency from the [WAPI] section

    This will switch lvar updates back to the WASM, which is the better and recommended configuration.

  9. 44 minutes ago, Flávio Oliveira said:

    Just copy this code and paste it into the events.txt file in the B777 block.

    No! Please do not modify the events.txt file, as this will just get overwritten the next time you install. Add them to the myevents.txt file instead.

    Better to submit them to HubHop so they get added to the events.txt file.

    John

     

  10. 11 minutes ago, DaveSCUSA said:

    I've tried a couple of methods (e.g. event.control(67209,"StartLVars")  --PANEL_LIGHTS_POWER_SETTING_SET or event.control(67213,"StartLVars") ELECTRICAL_EXECUTE_PROCEDURE) as they are executed after loading the aircraft - didn't work.

    Sorry, but what do you mean by 'didn't work'? Wasn't your handling function called when the event was sent? If not, please show me your logs and ini files.

    13 minutes ago, DaveSCUSA said:

    Can you advise me of a method of executing an Lua function() after the LVars, HVars and Input events are loaded?

    Why not use the [Auto] section? Lua autos are ran once the initial lvar/hvar list has been received by FSUIPC7. That is the whole purpose of the [Auto] section. See the section Automatic running of Macros or Lua plugins in the Advanced User guide.

    There is no event or offset change when Input Events are received, but these are requested once the initial lvars have been received and should be available shortly afterwards.

    John

  11. 9 minutes ago, DaveSCUSA said:

    I normally dont use Confirm. Not needed, aparently, in button assignments but needed in keypress assignments.

    Then how do you enter the next assignment if you do not confirm the current one?
    You need to confirm, or otherwise it is not guaranteed that the details (especially any parameters) will be saved.

    Can you explain EXACTLY what you are doing then please, and in what situation you want me to retain the status of the profile-specific checkbox.

  12. 37 minutes ago, Komet said:

    Is it possible that the TCAS function is still available in the radio? STBY,ALT RPTG OFF, XPNDR, TA ONLY, TA/RA

    I don't know - if standard controls are not working, why don't you look at the available custom controls for the PMDG 777? I am not going to do that for you...

  13. 1 hour ago, LeoSchoonbroodt said:

    Problem of WASM stop still present, see logs.

      The log file shows that the WASM ran and exited as expected.

    However, it does look like you have a WAPI client set to update Can you please set
        LvarUpdateFrequency=0
    in all of your WAPI clients, including FSUIPC7. Allowing the WAPI to request lvar updates was something I thought would be useful, but this is really of no use and you should let the WASM update and push-out lvar updates, I will remove this option at some point.

    1 hour ago, LeoSchoonbroodt said:

    My other problem (FSUIPC-Window not accessible), still present, but only when in main menu, during Flight this is accessible normal.
    Have seen that FSUIPC_WASM.log contains about 5000 lines "[ERROR]: Ignoring request to update LVARs as updated internally" for a short flight.

    Although it's logged to an SSD drive could that be the culprit of FSUIPC-window not accessible? and when so, why then only in main menu?

    You need to get rid of these errors before we look at anything else.

    56 minutes ago, LeoSchoonbroodt said:

    Another question, how can i disable WASM logging?

     You cannot disable completely. You need to stop those errors.

    I moved your comments from the beta release thread to here where they belong. Please use this thread for your issues, as they are nothing to do with the latest beta release.

    John

  14. On 6/20/2024 at 4:39 AM, DaveSCUSA said:

    1. The keypress assignments doesn't retain the profile radio button to the next assignment as does the button0 assignment. When performing numerous assignments for an aircraft, forgetting to select the check can obviously cause issues. Could you carry the profile button forward?

    I have just looked at this and the state of the profile checkbox IS kept when you Confirm a key press and then want to enter a new key assignment, so I am not sure what your issue is here. Can you explain?

  15. Just now, Holt said:

    Iff uninstalling is what it takes to fix the problem

    Well, it is NOT a problem. When you installed, you selected to install the auto-start option, so then obviously FSUIPC7 will be auto-started with MSFS. If you do not want that behavior, then you need to install without this component.
    This option is ONLY available during installation as this installs a component in the MSFS EXE.xml file to get MSFS to auto-start FSUIPC7.

    3 minutes ago, Holt said:

    I won’t have any need to reinstall.

    Fine, but why did you even install it in the first place?

    John

  16. I have moved your post to a new topic, as this is not related to the topic that you originally posted in.

    Why are you running luas when MSFS is in the main menu? FSUIPC7 only fully functions when you have an aircraft loaded and the camera system is out of the menu system.
    The ipcInit.lua should only be used for any one-off initialisation you need to perform, it should not wait for events.

    6 minutes ago, LeoSchoonbroodt said:

    Started MSFS and when in main menu selected another Aircraft (Schweizer) as seen at 144297 BUT ipcInit.lua doesn't execute the plane change

    It won't. Why do you want to do this?

    7 minutes ago, LeoSchoonbroodt said:

    After waiting for 118 seconds i loaded the Schweizer.lua manually from a Buttonbinding in the ini file and as this worked, it's an indication that

    Are you doing this outside of the main menu? FSUIPC7 should not process button assignments when MSFS is in the menu system.

    Things have changed quite a bit moving from FSX/P3D to MSFS, especially with the new menu system. FSUIPC7 is really designed to work with an aircraft loaded and ready-to-fly, and you should not be doing much, if anything, with FSUIPC7 when MSFS is in the main menu.

    If the auto-luas are not started, then that would be an issue. If that is the case, can you please show me log files for this.

     

  17. 1 minute ago, Komet said:

    Where can I download it? The site still says 7.4.13

    Strange question - did you not see the link I posted above? The download link is in that post which starts 'Please find below a link...'

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