John Dowson

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

Just checked the start-up procedure for this aurcraft: So which item on that checklist do you have issues with when FSUIPC is running?

But how are you starting the engine? What are you doing to start the engines, both with and without FSUIPC - are you using the cockpit UI (and if so, what are you activating), or are you using the keyboard (ctrl+e maybe?)? Please explain. Your ini file just shows that you are not using FSUIPC for anything at all, so I can't see how it can be doing anything. Please explain how you start the engines without FSUIPC. And show me your FSUIPC7.log file from when you try to do this with FSUIPC7 running. John

Ok, but strange...would be useful yo know why it wasn't working previously though... Thats a good idea - there are now far too many entries in the control menu with all the available presets. I am thinking of separating these and make them accessible on a new checkbox instead.... But I'm happy that you now have it working...😀 Cheers, John

Well yes...but is that updating the lvar? Can you monitor offset 0x341D using FSUIPC's offset monitoring facilities - you can select to send this to the FS title bar (as UB) and key an eye on that. Then try sending either 1 (>A:CABIN SEATBELTS ALERT SWITCH) ot 0 (>A:CABIN SEATBELTS ALERT SWITCH) after you have switched the alert switch on/off in the cockpit UI, to see if these requests are actually changing the simvar. I will still look into the auto-not-loading issue, as this seems strange to me... John

First, you posted this same question in multiple places - I have deleted your other posts. If the values aren't using the standard simvars (or A-type variables) that are held in the FSUIPC offsets (did you check these? I presume so, but you don't say...) then they may be held on lvars. I hear there are a large number of lvars available for the Fenix A320 - try listing them (Add-ons->WASM->List Lvars...) to see if the values you want are there. If so, you can add any lvar to an offset and then access the value from there as you would any other offset. John

This error: indicates that your client is requesting lvar updates. You should leave lvar updates to the WASM if using multiple WASM clients (i.e. if also using FSUIPC7). And if you do want to control lvar update frequency from the client, then you should turn of the lvar update in the WASM otherwise such calls will be ignored. However, this will not help with your current issue. Ok, that is important information! You posted in the wrong forum - you should use @Paul Henty;s .NET dll client sub-forum for issues using that dll. I will move your post. No, that just shows the WAPI log from FSUIPC, not your client (and it looks ok). There should be another WAPI log for your client, although I am not sure what this is called if/when using the .net client dll - Paul should be able to help with this... That sounds strange and indicates that it could be a timing issue. Be aware that once you have started the WAPI connection, it should NOT be used until lvars/hvars are available. This is done via a callback passed from the WAPI function registerUpdateCallback - there should also be a way to set this using the .Net client dll. You should not start using the WAPI until your registered callback function has been triggered - although I am not sure how this works with the .Net client dll. John

I am slightly confused by your post...especially the title... Aircraft do not create there own controls. There are presets for the HT1 (so, controls beginning with Preset:HT1... These are MobiFlight presets (see https://hubhop.mobiflight.com/presets/). To use presets, you must have the FSUIPC WASM module installed and enabled. I suspect that you have not enabled the WASM - do this from Add-ons->WASM->Enable (you only need to do this once). Once enabled, please disconnect and reconnect to MSFS (or restart FSUIPC7). Please see the section on the WASM in the Advanced User Guide - information on using lvars, hvars and presets is given there. You should also use the logging facilities provided by FSUIPC to trouble-shoot any issues. You can enable logging for various facilities from the Log menu, and open the logging console to see what is happening when you press a button (i.e. if a control or preset is being activated). John

They look ok to me - at least, nothing obvious stands out. I will check this here (most probably tomorrow or Monday) and get back you. I see you are using the LuaPath ini parameter. Could you test without that - comment it out or remove it, and copy your lua file to the FSUIPC7 installation folder.

There should be the InstallFSUIPC7.log file, in your FSUIPC7 installation folder. There won't be an FSUIPC7.log file if FSUIPC7 has not been ran. First, check that you have not installed in a Windows protected folder, such as under Documents or Program files. If so, te-install in a different folder. Otherwise, please see the README.txt file provided (ub the zip dile you downloaded). This contains the following: I have nothing further to add on this topic that I have not said many times before. Please check the documentation and the forum for similar posts before requesting suppoty. I am closing this topic. John

Have you enabled the WASM (Add-ons->WASM->Enable)? If not. do that. Afterwards, either restart FSUIPC or disconnect/reconnect from MSFS. This sounds strange... You should not use the MSFS add-on linker with FSUIPC - that is for managing Community add-ons, FSUIPC7 is not that... You can use it to manage the FSUIPC WASM module - but also not recommended. You ALWAYS need the FSUIPC WASM module in your Community folder if using lvars/hvars/presets with FSUIPC7. John

Well, they are menu options in FSUIPC7, so you can't use them. If using the WAPI, set debug (or even trace) level logging and look at the log file - that should tell you what is happening. There is a reload function in the WAPI: void reload(); // This sends a request to the WASM ro re-scan for lvars and hvars, and drop/recreate the CDAs And to disconnect/reconnect, use the end() and start() functions: void end(); // Terminates the connection to the WASM bool start(); // Startrs the connection to the WASM. But it is the log file generated by the WAPI which will tell you what is happening. Use Debug level logging - that should be enough. If you require more help, post more details...it is still unclear to me what you are doing...by saying 'using the WAPI', what do you mean? Are you developing with this API, or using a client from another developer that is using the WAPI? If the latter, talk to the client developer. If the former, you should be able to log and debug to see what is happening - you can always post the WAPI log file here for me to look at. Also, check the FSUIPC_WASM.log file (and you can also set Debug level logging in the WASM). John

Missed that, sorry. But it should be in your first post, or better still, in the title of your post... 😉

You attached your a file containing your registration details - I have removed this. DO NOT POST YOUR KEY DETAILS!!!! Doing this invalidates your license. You also attached the installation executable for some reason - I have also removed that. You can just copy across your FSUIPC5.key file from your old computer to your new computer. If you don't have it, entering the details (copy and paste) should work... If not, and it is a new pc, this can be due to not having the correct VC++ redistributables installed. Download and install the latest combined redistributable package from microsoft (https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170) - best to uninstall any of the individual 2015, 2017, 2019 or 2022 packages you currently have installed before installing the combined one. You should do this even if you have your old FSUIPC5.key file as FSUIPC will not function correctly without the correct VC++ packages installed. John

Try zipping/compressing them then attaching. @Pete Dowson will take a look at some point... John

If you installed FSUIPC7, then the documentation will be under your Windows Documentation folder. in an FSUIPC7 folder. Please look there. The location of all files installed is documented in the Installation and Registration manual, which is also included in the zip file you downloaded (as well as in the FSUIPC7 documents folder). I suggest you take a look at that (as well as the README.txt, which is only available in the zip file you downloaded, it is not installed). Then you need to show me your FSUIPC7.log file when this occurs so that I can take a look, and also show me/attach your FSUIPC7.ini file at the same time. Something else is going on for sure. Please also make sure that you have not installed FSUIPC7 in a windows protected folder, such as under your Documents or Program Files folder. Doing so will prevent your settings file from being saved, and can cause such issues. Next time you experience this issue, exit FSUIPC and attach your FSUIPC7.log and FSUIPC7.ini files here and I will take a look. Also, please make sure you are using the latest version of FSUIPC7, which is v7.3.6. John