John Dowson

You posted in the Announcements sub-forum, where it explicitly states Not for support requests. I have moved your post to the main support forum. Do you mean 3 throttle controllers? if so, a throttle is just another joystick device as far as FSUIPC is concerned, and you can have up to 64 such devices. Otherwise, it depends upon what you mean by 'handle'. Up to 4 throttle axis can be used and calibrated (for engines 1-4), and mapping facilities provided to map from using 1 throttle to 2 or 4 throttles (use in the a/c), or from 2 throttles to 4 throttles.

That sounds pretty good! Maybe you could share it in the User Contributions sub-forum?

I have fixed this issue in the attached beta release, v7.2.17a: FSUIPC7.exe Please download and use to replace your existing FSUIPC7.exe and test with this version. John

The issue should be corrected in the attached version, v7.2.17a: FSUIPC7.exe Again, apologies for this. John

I have found an issue that prevents lua Autos from running if the WASM is not installed and enabled. I will fix this in the next release, but for the time being please make sure that you have the WASM module installed and enabled (using the Add-ons->WASM->Enable menu item), or you can manually start your luas (e.g. on a button or key press). John

You can safely ignore that message - it is related to the new preset mechanism (see Advanced user guide). The problem seems to be due to changes I made in 7.2.15 related to starting luas after lvar/hvar lists have been received from the WASM. Looks like I forgot to test without the using the WASM, as luas are no longer started when not using the WASM. I will take a look and fix this in the next release. However, in the mean-time, to get your luas working again you will need to activate the WASM, using the Add-ons->WASM->Enable menu entry. You don't need to use the WASM, but it must be installed and enabled. Sorry about this. John

Are you sure you had an aircraft loaded and were in the ready-to-fly state? Your log shows the lua's were killed as you were (most probably) in the main menu: If this is not the case, something is triggering the lua threads to be terminated.

Just took a look and I don't think any of the condition lever controls are working in the C208. I have tried various and none seem to have any affect. Also, moving the condition lever in the UI logs no control, so it seems like you can't use these at the moment in the C208 (or maybe in any aircraft). John

The same as any other control...if using an axis control, assign it to an axis. If using a non-axis control, assign it to a button or key press. Note that I have added these controls and have not tested them in all (or any!) aircraft. If they don't work, it will be an MSFS issue. I'll can take a look at the C208 later to see if these controls work in that aircraft. John

That log file is pretty small, I am surprised that you cannot attach a zipped copy! Looking at that log, there are no messages logged for buttons C.12 and C.13. Are you sure you pressed them (i.e. turned the rotary)? Also, did you have an aircraft loaded and ready-to -fly? Your log indicates that the Rotaries.lua was killed about 22 seconds after it was started, most probably as you were still in the main menu: Try running with the logging console open (Log-> Open Console) so you can see what is happening in real-time. Always make sure that you have an aircraft loaded and ready-to-fly when using luas, as they are only started when in this state (they can be started on MSFS start-up, but will be killed when the main menu state is detected). For the first test, rename/disable the lua and verify that turning the rotary logs button presses for your C.12 and C.13 buttons. If these are not logged/detected, the rotaries.lua will not work. You did day you saw these in the assignments window, so I cannot see how there activation is not logged. If they are logged, activate the lua again, turn the script logging off (set LogActivity variable to false in the script and turn off lua logging in FSUIPC) and then monitor your console again to see what happens when you turn the rotary knob. You can also post/share the two logs and I will take a look. But please also describe what you see in the logging console, if anything, during these tests. John

You cannot do this. Although its not clear from the documentation (I will update), hvars multi-line macros have the same restriction as lvar multi-line macros: As the only action on hvars is Set, multi-line hvar macros don't make sense. I will make this clear in the documentation. To trigger multiple macros, you have two options: 1. Use multiple assignments Define each hvar as a set macro. Then assign those macros to the same button. To do this, you need to assign to the first macro, then comment out that assignment (in your FSUIPC7.ini file), reload your asignments, then assign to the next macro. Repeat until all assigned, then uncomment those macro assignments that you previously commented-out. 2, Use the new preset mechanism, introduced in the latest release, v7.2.16. To use this method, create a file call myevents.txt in your FSUIPC7 installation folder. In that file, add this line: CJ4:load_FP# (>H:CJ4_FMC_1_BTN_IDX) (>H:CJ4_FMC_1_BTN_NEXTPAGE) (>H:CJ4_FMC_1_BTN_R1) (>H:CJ4_FMC_1_BTN_L3) You should then see this in the controls drop-down menus as Preset: CJ4:load_FP. Note also that using this method, you do not need to make the hvars known to FSUIPC7 via the *.hvar files, although this does no harm. John

It is the id of the lvar, used both in the sim itself and in FSUIPC7. Probably not useful to the end user, but was useful to me during development. I should probably remove these now. Yes...I get the occasional crash. I did have a lot of issues with the FBW A320, even when it was installed in the Community folder and not being used. Now I remove this if not using it and have had very few crashes since. I also usually disabled AI and live weather on my development set-up and this improved things a lot. If activating your presets via the 0x3110 offset, remember either to not install the MobiFlight preset list, or to rename it once installed, as using this will change the number of the presets in your myevents.txt file. If you want to use any MobiFlight presets, just add them to your myevents.txt file. It is easier to search for and copy any you want to use directly from the Mobiflight hubhop preset list site, as you can break the (very large) list down by vendor and aircraft name, and it also has a good search facility that allows you to find most things pretty easily. John

You also need to (temporarily) remove this line from the [Buttons] section of your FSUIPC7.ini file to see those buttons: IgnoreThese=C.12, C.13, C.21, C.22 Sorry for not mentioning that earlier.

Ok, glad you got it working. Strange that you need a parameter of 2 to the 66300 control though, which is Toggle Starter1 - doesn't this work without that parameter? Ah! Then they are MSFS simvars (or A type variables), not controls, and nothing to do with PM. I could add those to FSUIPC7 offsets. However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset. This should be available in the next FSUIPC7 release, hopefully sometime next week. John

Can you also temporarily remove the lua (just rename it to Rotaries.lua.off) and see what button numbers you see in the button assignments window when you turn your rotary in both directions. You should see 12 in one direction, 13 in the other. If you don't see those, your rotary button isn't working.

The one in the documents folder is an older general one. I customised this specifically for the Bravo rotary, which is the one in this thread. I should have renamed it to BravoRotary.lua really, I guess...sorry about that. John

Try zipping the file and attaching. I cannot access from that link. John

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