John Dowson

Not me...! I have added Project Magenta to the tile of your post to (hopefully) attract any other PM users... Have you tried asking on PM support? Writing to this offset sends the Bleed Air Source Control Inc/Dec controls - maybe that is not working in the PM 738? I don't know.... Where do you see these controls? Do you know the associated control/event numbers? I could look into adding them if needed...Probably best to talk to Project Magenta / Enrico and get them to contact me for adding any new controls. I can't really comment on your lua script as I don't know much about the PM offset areas (0x5400 -5FFF) - I have no information on what these hold. However, it does seem a little strange that you are only using event.offsetmask and event.offset functions, all calling the same function. So the function is only called when something triggers one of those offset to change - what is doing this? John

lvars can take some time after the aircraft has loaded to be available. By default, the WASM waits 5 seconds after aircraft load to scan for lvars. For complex aircraft, such as the A320 neo, you need to increase this by changing the default value of the LvarScanDelay WASM ini parameter (should be 45seconds and upwards for the A320!). Please see the Advanced User guide for details. Since the latest FSUIPC7 release, v7,2,16 released two days ago, listing lvars (from the Add-ons->WASM->List Lvars menu entry) will automatically perform a rescan before listing. Hvars need to be made known to FSUIPC7 before they can be used directly. Please see the Advanced User Guide. Since the release of 7.2.16, there is an easier way to assign to hvars using presets. Create a file called myevents.txt in your FSUIPC7 installation folder. To assign a preset to activate a hvar, insert a line with the following format: presetName#(>H:hvarName) where presetName is the name of the preset which you will see in the drop-down menu hvarName is the name of the preset You will then see 'Preset:presetName ' that you can assign to directly in the assignment drop-down menus. To trigger via offsets (i.e. from SIOC), you can use the general control offset at 0x3110. The control number can be difficult to determine...if NOT using an events.txt file (remove/rename this if installed to not use), then the first control in that file will have the number 0x400001 (or 262145), and each subsequent line will increase the control number by one. Be aware that any comment lines (starting with '//') are ignored and will not affect the control numbers. I haven't tested triggering presets by offset 0x3110 yet, so if you try this please let me know if you have any issues. Its a good idea to test the hvar first - use the Add-ons->WASM->Execute Calculator Code... menu option and enter the same code you use in the preset file, i.e. (>H:hvarName) Once you have mastered that, you will be able to execute any calculator code. Please see the Advanced User guide for full details. I understand that this method of activating presets via offsets is a bit tricky and prone to errors on changes, as well as calculating the control number to be used. I am thinking of adding another offset to activate presets on the preset name. I will look into this at some point. John

Ok, good - and thanks for sharing. no... John

Sorry, no idea what this means...can you please explain and also include any relevant files - FSUIPC6.log, FSUIPC6.ini, and any other relevant files. John

You still have some assignments to the virtual buttons used by the Bravo lua script: You should delete this and re-assign to the actual button numbers if you want to use them. Did you have an aircraft loaded and ready-to-fly? Luas are only started once in this state (well, 5 seconds after, or longer, depending upon the value WASM ini parameter LvarScanDelay which has a default value of 5 seconds). I can't really tell what is happening from the log you attached as it is a continuation log file (i.e. you selected 'New Log' from the logging menu). Always attach a full log when you need support - there is information at the beginning (and end) that I need to see to diagnose issues correctly. Also, did you activate logging in the Rotaries.lua as I advised if you have issues? If not, and you still have issues, please do that and show me your full log file. The log file you attached has no lua logging so I can only assume it wasn't running for some reason. John

The logging level shouldn't make a difference for error logging - they should always be logged, regardless of the logging level. Just checked the code for this as well and it looks ok. Whet logging level were you using when you saw the error? Can you try again and see if you still get that, and if so let me know what logging parameters you are using. I will also update that message to make it clearer what it means. That is strange then. If MSFS was still running when you installed, then this could explain things. However, I think the installer will show a message and not proceed if MSFS is running, so I really have no idea why you saw that message. No problem. Cheers, John

Hi Andre, glad you got it working. One thing in your lua scripts - you are reading as an 'unsigned double', which is correct, but writing as a signed double. It will still work in this case, but better to also write as a signed double using the ipc.writeUD() function. Also, you could have achieved the same using a standard control assignment with an offset condition. That would be slightly faster, as the lua method requires your script to be compiled each time before it is ran, but in this case it doesn't matter much. John

How come you get different logging? Did you re-install and install the WASM? This is correct, and indicates that you have installed the latest WASM. Well, it is certainly in the installer... This is correct - that is the date the WASM 0.5.7 was built. It is (but for FSUIPC7, not FSUIPC6, presume a typo)! Please look at the component options when installing - one of them is the WASM. I really don't understand why you are confused. Please tale a look at your InstallFSUIPC7.log file, this will tell you what was installed and where. John

Then you also need to update your WASM. You should always re-install the WASM from the installer when you install FSUIPC7. The message is slightly misleading...it is saying the WASM installed is 0.5.6 whereas the WAPI/FSUIPC is expecting 0.5.7. You should update as it may cause issues . John

Yes - a 'K' type variable is the same as an FSUIPC control, so just assign your button to the control (when you select 'select for FS control') Toggle Tailwheel Lock. 'A' type variables are simvars and are held in fsuipc offsets (that is in offset 0x2A90). The conditional check 'A:TAILWHEEL LOCK ON, Bool) 0 == if' is only checking the lock is off before sending the control ('(>K:TOGGLE_TAILWHEEL_LOCK)') , so its the code to turn on the wheel lock. You don't really need that if assigning to a button. If assigning to a switch, with one button for off and another for on, then you would use an offset condition (see Advanced User Guide) to only send the control if the actual state of the wheel lock (as reported in that offset) was in the correct position (value 1 or 0, depending if the assignment is for on or off). The latest version of FSUIPC, v7.2.16, released a few hours ago, also has assignments to MobiFlight (as well as user-provided) presets available for direct assignment in the menus. Please download and try that. The MF presets should be available automatically, but please check the Advanced User guide for details. John

That is strange...I see: Are you sure that is from the latest release? Can you check and show me the full log file. And did you also reinstall the wasm? I will check further on that message tomorrow, but it shouldn't be an issue... John

Btw, I am looking to add functionality to add any simvar (or MSFS A type variables) to a free user offset for the next release. Couldn't fit it in to this one (didn't want to delay any longer!), but should hopefully be ready for release by early next week. John

Hi Joe, Please do, and if you haven't done this already, check out the MobiFlight HubHop website for presets/calculator code, and consider submitting any additional code there. It is the main community resource for MSFS calc code. Cheers, John

Thanks Andrew - updated for the next release. Cheers, John

If it is related to a simconnect issue, then logging simconnect could maybe point to something. However, if MSFS is freezing this really could be anything (e.g. related to weather or AI, your rolling data cache, an aircraft issue, etc) and nothing to do with simconnect. You really need to try and narrow it down. You probably won't get any response from Asobo, but worth checking there to see if anyone else has a similar issue with a possible cause or solution. John

Sure, no problem. This does seem strange - I will look into this further when time allows...maybe someone else has noticed this and can respond? John

So MSFS froze? Check the Asobo forums and report this to them. But this error was logged/produced due to a simconnect failure in MSFS, so needs reporting to Asobo. No, this won't help with you issue as it is with MSFS and not FSUIPC7. John

@joeherwig FY, I have just released v7.2.16, which allows you to define parameterized presets to assign and execute calculator code on a button press without needing to use lua. The MobiFlight presets are also included. Please see the Advanced User guide for details. John

You can now assign to calculator code by using 'presets' in the latest version of FSUIPC7, v7.2.16. The MobiFlight presets are also included. John

v7.2.16 has now been released, containing the condition lever controls, as well as direct access to MobiFlight presets amongst ither updates. Please see the history document or the changes.txt file for a complete list of changes. John

v7.2.16 has now been released, containing the condition lever controls, as well as direct access to MobiFlight presets amongst ither updates. Please see the history document or the changes.txt file for a complete list of changes. John

This new functionality is now available in v7.2.16, just released. John

No it doesn't. FSUIPC knows nothing about the views you have set-up, it only send controls to the FS to change and set views, as you have defined them. It sounds like it is going back to the default cockpit view for that aircraft. Have you changes this (in the camera.cfg file)? I really can't help you with setting up custom views - try looking on avsim.com, I think there are several posts / tutorials on how to set this up, otherwise try asking on that forum. John

👍

Why are you using the hidAlphaButtons and hidBravoButtons lua scripts? These were initially useful to access the buttons with numbers > 31, but have not been needed since FSUIPC was updated to recognise up to 128 buttons, in v7.1.0 back in May 2021. I think you should remove those luas, and update the assignments you were using (on the virtual flags used by those scripts) to assignments to the actual button number. If you do that, you should be ok, as it seems like the issue is that both the Alpha lua script and the rotaries script are using the same offset/virtual flags (at offset 0x3340). If you want to continue using the Alpha/Bravo luas (although I recommend not to), you need to update the Rotaries.lua to use the next virtual device, which will be at offset 0x3348 (the alpha script uses 0x3340 and the Bravo 0x3344), i.e. change line 61 to: offset = 0x3348 That will be virtual joystick 66, so you would also need to change all your rotary assignments from virtual device 64 to use 66 instead. John