John Dowson

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

Yes of course - as with all ini parameters, they are documented in the Advanced User Guide. Yes, I also see that with this aircraft, logged every second or so with a parameter of 1. I also get many TAXI_LIGHTS_ON events logged, around 80 of these per second...! John

First, it is always helpful if you can specify which aircraft you are using if you have an issue with a specific aircraft... This could be due to one of several reasons: 1. You have an assignment to AVIONICS_MASTER_SET in MSFS to an 'always on' button on your controller. Check your MSFS assignments- i recommend creating an empty profile for your controllers in MSFS if using FSUIPC for your assignments, but it is also ok to have some assignments in FSUIPC and others in MFS. 2. This is just an event that is continually send from the aircraft model. Many aircraft in MSFS continually emit certain events, which are different for each aircraft. For such events, you can ignore them in FSUIPC's logging function by using the DontLogThese ini parameter, which can go in your [General] section or in a [Profile.xxx] section, which is better as such events are aircraft-specific. 3. You have this assigned in FSUIPC on repeat - although from what you say, I doubt this is the reason. John

I've checked this now, and it all seems to be working as expected, except for one thing: the profile [LvarOffsets.xxx] sections are not moved to the separate profile files when setting UseProfiles=Files for the first time. I have corrected this in the next release. But both general autos and profile-specific ones are being started correctly, irrespective of when FSUIPC7 is started. I think your issue maybe due to when you are editing the ini files - if you do this when FUIPC7 is open, then when you exit FSUIPC the ini file will be re-written and you will have lost your changes. I have also tested this when using the LuaPath ini parameter, and that is also working as expected. Maybe you could test again with the attached version, v7.3.7d. If your lua's aren't starting correctly, we can maybe add more logging to see why this isn't working for you. John FSUIPC7.exe

Sorry, but I am not sure I fully understand. Offset 0x3BA0 holds the TAIL HOOL POSITION simvar as a double floating point number (8 bytes) with values between 0 and 1. What has this got to do with custom controls? Also many MSFS aircraft, especially add-ons, do not use the standard MSFS simvars and use there own variables, usually lvars. So first, check the simvar is being used by monitoring the offset and change the tail hook position in the aircraft cockpit UI and see if the value changes. If not, try listing lvars to see if any look appropriate, ot look to see if there are any MF presets available and see what they use. If you want any further help, please state the aircraft you are using and what you are trying yo do. Your initial post is very cryptic... John

I don' think I'll deprecate it - just not advertise/document it. It will still be available for those that already use this feature. But I will certainly make sure its working correctly first! John

If you could let me gave them I could make them available in the Documents download section for other German speakers. I am happy that you have managed to solve your issue. Regards, John

Hi Joe, ok, thanks for the updates. It does look like an issue when using profiles in separate files. I will look into this - I must admit, its not something I use (and would discourage others - maybe I will remove the documentation for this feature in a future update...) and don't test, except when problems are reported. And this can be related to when FSUIPC is started - I will check that. Thanks again - I will report back once I have looked into this in more detail. John

Listing them from FSUIPC (Add-ons->WASM->List Lvars...) will list all available lvars (well, the first 3066) at the time you list them (it does an automatic rescan), so nothing else should be necessary. John

He is doing well, thanks. He only monitors the main forum these days, and still supports MakeRunways, but the rest he leaves to me (he has retired!). I have seen some strange issues when both the WASM and a client is controlling the update frequency, but I don't understand why. The WASM ignores requests to update the lvars from a client if set to update automatically, so this really shouldn't be an issue - just not necessary. John

All errors in the WAPI should be logged, regardless of the log level set. Otherwise the OP wouldn't be seeing these: John