John Dowson

I just corrected the format of the files - I left the paths as they were specified. Then just change the paths in the EXE.xml file so that the <Path> element is pointing to the correct location for the exe....its not that difficult to understand... John

The trial license has been renewed, now valid until 30th July. John

Yes, of course - did you not take a look? You should, and familiarise yourself with the format so that you can correct if something corrupts it. John

The desktop shortcut should be removed and added again when you re-install. I suspect that things are going astray as you are running the installer from the zip file. You should extract the zip and re-install from the extracted installer - no need to re-register. John

You ran the installer directly from within the zip file. You shouldn't do this as it can cause issues - please unzip/extract before you run the installer. However, the log file you attached shows that you are running a licensed version: Where is it saying that it is not registered when you launch? Do you see the Assignments menu? John

Could you attach your InstallFSUIPC7.log and FSUIPC7.log files please, and let me know your SimMarket order number and I will check here. Thanks, John

Replace that file with the attached. John EXE.xml

Another thing to try, as the button press is sent before the ' Starting everything now' line, is to add an offset condition on the ready-to-fly flag in offset 0x3364. This will be non-zero before everything is started, and 0 afterwards. So add B3364=0 before your assignments, i.e. John

Ok, took a look at the video and I think I understand your issue - it is the initial press being triggered on start-up. I am not sure why this is occurring... FSUIPC usually only reacts to changes in state, so it must be receiving an initial state of 'off', then on the next scan it is on, and so triggers the assignment. Not sure how to prevent this... One thing you could possibly do is have a small lua that is auto-run that sends the control again, i.e. ipc.control(66725, 1) This will then send the control twice (i.e. once from the initial button state, once from the lua), and should so then be in sync with your hardware. Not ideal, I know but maybe worth trying. Otherwise we need to determine why the initial button state is triggering a button change event... John

But you wanted to know: That log line tells you - it is here: C:\Users\User\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml But there is something wrong with that file - please attach that here. John

No, that is just a standard event log line. Why are you sending the same control on a press and a release? This is strange if you didn't actually press those buttons...not sure why that is happening, but most probably due to the driver/interface card... Not sure what to advise...if the press is activating automatically and you don't want the assigned control sent, then remove the assignment to the press. I don't have much time now I'm afraid - I'll review this again tomorrow and take a look at the video then... John

There is no point in me watching that video until I have seen your files...and then it may not be necessary...

Didn't you see this: ?

It will only be there if you opted to install the auto-start component. This is in mine: But why didn't you attach your InstallFSUIPC7.log file so that I can check this? John

FSUIPC should be started from the MSFS EXE.xml file. You should also start Spad.next using the EXE.xml file, not the MSFS.bat file provided by FSUIPC. You should only start things directly from the MSFS.bat file if having issues when using the EXE.xml batch file. Ok. For others reading this thread, that is this topic: John

The key file you previously attached was not a valid FSUIPC5.key file (I seem to remember(, and error 16 is 'No FSUIPC entry to check'. Please check and attach your InstallFSUIPC5.log file. You can also compare the format of your FSUIPC5.key file against your FSUIPC7.key file as they are the same. What error do you get? What does it say in the installation log file? Did you check/update your VC++ redistributables as advised? Any further issues, please let me know your FSUIPC5 order number (or the email address used for the license) and show me your InstallFSUIPC5.log file. John

So you have this assigned in both P3D and in FSUIPC? You should only assign in one place. If assigning in FSUIPC, we recommend that you disable controllers completely in P3D as it has a tendency to reassign automatically if not disabled. Also, FSUIPC only reacts when buttons are changed - it should not send anything until you change the state of a button. Note also that for the parking brake toggle, you can use an offset condition to determine the state of the parking brake (using offset 0x0BC8) and so only send the command when needed to maintain the correct state for your switch - see the Advanced User guide for details. For the starter. you could try the Starter 1/2 Set controls instead. But if you want me to look into this further, I need to see your FSUIPC6.ini and FSUIPC6.log files, the latter generated with logging for Buttons & Keys activated as well as Events (non-axis controls) and showing your issue. John

Just re-install and do not select the AutoStart component. It is only auto-starting as you had this component selected (it is selected by default) when you installed. John

I don't understand why you have the aircraft for your profile in the profile file, rather than in the FSUIPC7.ini file. Did you create this manually or did FSUIPC7 do this? The [Profile.xxx] sections should still be in your FSUIPC7.ini file listing the aircraft that use that profile, i.e you need this in your FSUIPC7.ini: [Profile.MD82] 1=Gateway Airlines Classic White This then matches the aircraft and the MD82.ini will then be read/processed. The [Profile] section in your profile ini file should just contain the Created timestamp, not the aircraft that use that profile, as they should be in your FSUIPC7.ini. John

Yes. the developers should supply them (but they rarely, if at all, do...), otherwise you need to go through the aircraft code to find them... But these days it is far easier to use presets than hvars directly. Presets are a name associated to a junk of calculator code, that can use hvars (without them being known to FSUIPC via hvar files), lvars, A:vars (simvars) and k:vars (simulator events). Tale a look at the MF HubHop site (https://hubhop.mobiflight.com/presets/) - this is a community driven effort led by MobiFlight to determine the code (i.e. what lvars, hvars, etc to use to set a particular function) for various aircraft, both by Asobo and also for add-on aircraft. What is this? I have not heard of this... Yes - that is just a cut-and-paste error in the changes.txt file (it has already been corrected). John

I've just checked this and it looks ok to me - the [LvarOffsets] sections are being processed once all lvars have been received. So I think the lvars you are using aren't initialised by the time the lvar scan is performed by the WASM, and so aren't being provided to FSUIPC. This is usually due to the LvarScanDelay WASM ini parameter. Not sure what you are using for this - it defaults to 5 seconds, but for complex aircraft this needs to be increased substantially - to between 45-60seconds for the FBWA320, for example. So I suggest you try increasing this parameter - this should be set in your FSUIPC_WASM.ini, but not the one in your Community folder (otherwise it will be overwritten the next time you update) but the one in the WASM persistent storage area (copy the existing one to this location and modify). Check the Advanced User Guide for details. John

Yes, that does look like it was trying to add the lvars before being received. I will look into this and get back to you. I suspect that it is trying to add the lvars to offsets after the first group of lvars has been received, or the 'ready' callback is being fired before all lvar name packets have been received, rather than waiting until after all have been received. John

The latest and only supported version is v7.3.6 - please update. I am also planning on releasing v7.3.7 tomorrow. Your issue sounds like you are just trying to list the lvars to early, before they have been received by FSUIPC7. When you list lvars or hvars, they should appear both in the FSUIPC7 main window as well as in the log. Note that hvars are only available if you have a valid *.hvar file for the loaded aircraft in a folder scanned for such files by the FSUIPC WASM module - see the Advanced User guide for details. If you require further assistance, I will need to see your FSUIPC7.log file, preferably with Debug logging enabled in the WAPI. Make sure that you have updated to the latest available version before showing me this file. John

It is an update exe, not an installer.

The current license is still valid - it expires at the end of today. I also like to leave a few days between the expiry of one license to the start of the next, so I will most probably generate a new license at the weekend. John