John Dowson

Ok, but that is rather strange... I run MSFS without AI traffic (in MSFS) on my development system as this was previously a cause if CTDs in MSFS. Live weather as well. Not sure on the current status of these though. John

👍

Did you restart FSUIPC7? Presets are only loaded on start-up. Not sure what this means, but presets are attached to calculator code. If the calculator code uses hvars, these do not have to be made known to FSUIPC7 via using hvar files, but it does no harm (makes no difference) if they are. What do you mean by control value in this context? both what? I thought you said you couldn't see the preset? I am not sure what you are asking... To log button activities, active logging for buttons & keys. As I said, the calculator code to execute a single hvar would be '(>H:hvarName)' Don't know what you mean by obtain. The affect if executing calculator code depends on the calculator code. Activating a hvar (a html variable/element) would usually trigger a button press, or some other UI event, in the aircraft. Sorry, typo (corrected), should (obviously) be 262145. I am also confused - by your questions! Hvars do not take parameters. The parameter for an lvar update would completely depend upon the lvar in question, and similarly any parameter to calculator code would depend on what that code did. Please see the Advanced User guide, WASM section starting on page 45. I suggest you read (and understand) the entire section. John

Why are you updating your ini manually? You should be updating your button assignments using the FSUIPC UI panel for this. If you want to do this manually, you need to know what you are doing. It seems that you are just updating the comments/annotations, and not the actual keys that are being sent (i.e. the assignment itself). The comments will get re-written, based upon the actual assignments. You cannot just change the comment and expect the assignment to change. John

Assignment facilities are only available in registered versions of FSUIPC7. There is a trial license available in a sticky post at the top of this sub-forum if you would like to try. John

Generally due to a windows update or change. It shouldn't cause any issues if you are using the JoyLetters facility - if not, you should use that (see the user Guide). You can get your original settings back by editing your FSUIPC6.ini file - I can help with this if needed, but it is a lot easier if you are using the JoyLetters facility. That just shows devices with ids 0 through to 3 (4 devices) were acquired for use.

This question has been asked many times before - please check the support forum for my response, I am not going to keep repeating myself on this issue. Bottom line is that FSUIPC7 is a separate executable and in no way can cause an MSFS CTD. If it did, it would have to be an MSFS/Simconnect server-side error. There are many reports of MSFS crashing (both with and without FSUIPC7). You should try to isolate what is causing the crash and report to Asobo. The FSUIPC shortcut/desktop icon does not start MSFS and FSIOPC at the same time. It shows a splash screen and then starts MSFS,. It is MSFS that starts FSUIPC7, if you have selected to unstall the auto-start component. John

Ok, interesting. Thanks for reporting back. John

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