John Dowson

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

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. Fine, but why did you even install it in the first place? John

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. It won't. Why do you want to do this? 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.

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

I have released a beta version of the next release with the PMDG 777 offsets enabled if you would like to try it: John

I have released a beta version of the next release with the PMDG 777 offsets enabled if you could try it: John

I have released the next version (which contains a fix for this bug) as a beta if you would like to try it, available here: John

I have released a beta version of the next release with the PMDG 777 offsets enabled if you could try it:

I have released a beta version of the next release with the PMDG 777 offsets enabled if you could try it:

Offsets are just a 65535 byte memory are in FSUIPC, starting from 0000 and going to FFFF. No. An offset address is just a memory area. Offset address can be populated from reading simvars or lvars, cna be used internally by FSUIPC or can be used to hold client data from specific aircraft (only PMDG airliners supported for this). The client data held in offsets is based upon the the data structures provided by PMDG, but this data is split into different offset areas. See the specific PMDG offset data documents for how to access PMDG data via offsets. Note that in the current release of FSUIPC7, only the offsets for the PMDG 737 are enabled. I have enabled the offsets for the 777 now and will be releasing this shortly (i.e. in the next few days) , as 7.4.14. Take a look at the FSUIPC7 Offset status document, and also the specific offset documents for PMDG aircraft. I have attached the one for the PMDG 777 below. Not sure what this means. You can read any offset at any time, but whether that offset holds any relevant data depends on the offset and possibly the aircraft loaded. The PMDG offsets will not hold any relevant data for the 777 until I have enabled this (the next release), but they will hold data for the 737, if enabled both n FSUIPC7 and in the aircraft itself. John

There is a known issue with the WASM that has been identified and fixed, although this fix has not yet been released (officially) - see the following post where the fix is available: I will be releasing this fix officially in a couple of days, with the next version of FSUIPC7 (7.4.14). This just sounds like windows is not giving much time to FSUIPC7. This can happen if you have a lot of logging enabled and are logging to a HDD (and not an SDD). You can send logs if this happens, but I doubt they will show anything. John

I am currently looking into adding/re-activating the PMDG 777 specific offsets. They will be available in the next release of FSUIPC7, which I am currently planning on releasing towards the end of the week. John

This is because you have installed the FSUIPC7 auto-start component. If you do not want FSUIPC7 to start with MSFS, re-install and de-select the auto-start component (there are two distinct methods of using auto-start - make sure both are unchecked). 'Open on Start' means to open the FSUIPC7 main window on start-up. Usually it starts iconised to your system tray. Yes, you come across as very impolite. I provide a lot of documentation with my software. You should at least try looking at that before posting. Try starting with the Installation and Registration guide. You should also actually look at what you are installing - it should be obvious that you are installing a component called 'Auto-Start'. John