John Dowson

FSUIPC7 should start-up automatically however you start MSFS, if using the EXE.xml auto-start method. Yes, your SimConnect seemed to be blocked, which is why I recommended a reboot. Usually restarting MSFS should fix this, but if problems persist always better to reboot. John

Ok. That log shows FSUIPC7 was auto-started and it connected and everything looks ok. Was not everything working? One thing to note is that you DetectToConnectDelayAuto parameter is quite high (375). This may be ok, if MSFS takes > 5mins to boot to the main menu, but if MSFS isa ready sooner this will imply that FSUIPC7 will not connect and be available for some time after MSFS has started. You can change this parameter to 60, and then also set StartUpTuningActive=Yes to re-run auto-tuning, and that should then set a good value for this parameter. John

Then show me a log file! Both of the log files you attached show FSUIPC7 manually started: 141 Manually started with DetectToConnectDelay=1, InitialStallTime=5 John

That is the recommended way. Show me the log file from this then - you keep showing me log files when FSUIPC7 is manually started.

That log again shows FSUIPC7 was manually started, and with InitialStallTime=5. Are you not using auto-start? If manually starting, when are you starting FSUIPC7? As I said, if manually starting, make sure MSFS is already running and has passed loading to the main menu. But once you have so many re-connection attempts, best to exit MSFS and start again. And, as I said, I would reboot your system to start afresh.

Please change the InitialStallTime first... I think you have your FSUIPC7 start-up parameters badly tuned, so it is re-connecting too many times and using up all the simconnect connections, and so preventing other clients to connect, You need to tune your FSUIPC7 start-up parameters (or use auto-tuning). Anyway, your logs will confirm this. Taking the dogs for a walk now, I will look at your logs when I get back... John

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

I am not interested in images, especially from vPilot. I only support FSUIPC. Please show me the log file. John

Please show me / attach your FSUIPC7.log file. Also, try exiting and restarting - does it then work? John

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

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

First, you posted in a FAQ entry completely unrelated to your question. I have moved your post to a new topic. 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

This is happening as you have added some simvars to be requested from the Modular Fuel System in your myOffsets.txt file: 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

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

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

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.

No - I already sent you one on June 9th. You should have had enough time to decide if the product is suitable for your needs or not.

Yes of course - please see the Advanced User guide on how to use presets.

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

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

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.

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

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. You need to get rid of these errors before we look at anything else. 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

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?

No, sorry. I will try the free/trial version of SkyDemon and see if I can get that working and let you know, but it may take a week or so before I get time to looking into this. John