John Dowson

Note there are also existing support requests on the condition lever/cut-off for various aircraft - for example, see the following: Asobo C208 Caravan : ATR:

For the Asobo King Air, use presets KA Fuel Right Condition Lever Cut Off and KA Fuel Left Condition Lever Cut Off. I don't see the other 2 aircraft listed in the HubHop site yet, so you will have to investigate how the condition lever works in these aircraft. Try logging Events and Input Events and see what is logged when moving the condition lever in the VC. If anything is logged, try using that. You can also list any available lvars to see if any look appropriate and try them. And as a final resort, inspect the aircraft code that implements the condition lever which should give you an idea how it works, but this is not that straightforward. Please see here: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/. I can't help further with these aircraft as I do not have them. But, regardless of the aircraft or function you are trying to assign, the techniques to determine how to assign are always the same: use logging (events, axis events, input events), check for available presets, try looking at the available lvars and hvars, examine the model behavior.

This will not work - you cannot get a return value from ipc.execCalcCode. If you want to read a value of a simvar/a-type variable, you have to add this to an offset and read the value from the offset. You can add any simvar to a free FSUIPC offset using the facilities described in section Adding Simulator variables (simvars) to FSUIPC offsets on page 34 of the Advanced User guide. Also this is incorrect: This will try to write the string "panelneg", whereas you want to use the value of the variable, and there is no indexing on events, but you can use two parameters like this: ipc.execCalcCode(panelneg .." (>K:3:LIGHT_POTENTIOMETER_SET)") Otherwise, maybe try ipc.execCalcCode(panelneg .." (>K:LIGHT_POTENTIOMETER_3_SET)") It may be easier to define a couple of presets to inc/dec the panel lighting brightness and assign to these. What aircraft are you using? Maybe there is a preset already available... John

All available FS controls are listed in the document Controls List for MSFS Build 999.txt, and are listed in the drop-down menu. If they are not there, they don't exist. I suspect the controls for '1' just don't have the number, so are these: The fuel selector events provided by the MSFS SDK are documented here: https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Aircraft_Fuel_System_Events.htm. All these should be available. But, as always with MSFS, what these controls actually do is completely dependent in the aircraft you are using. You should get into the habit of looking how the MF presets are implemented (using https://hubhop.mobiflight.com/presets/) for the aircraft/function you are trying to assign - this will give you an idea of what control you need to use, or just use a preset, if available.

Many aircraft, especially add-ons, do not use or respect the standard FS controls and you need to look into other ways to control, such as lvars, hvars, Input Events, custom controls or a combination of different events, using calculator code via a preset. But you should not by now that I cannot help at all if you just say 'X isn't working'. This will depend on the aircraft you are using, which you do not tell me, and how you have assigned, which you also do not specify. So, please ALWAYS provide more information - I need to at least know the aircraft you are using, and it is always helpful if you attach your FSUIPC7.ini files, so I can see your assignments, and your FSUIPC7.log file, so I can see what version you are using, what aircraft, and if any errors are logged. John

Try logging axis event and input events, open the logging console and see what is logged when you move the throttle in the VC, and then try that. If that doesn't work, then you can try using the lvars L:A_FC_THROTTLE_LEFT_INPUT and L:A_FC_THROTTLE_RIGHT_INPUT, which take values 2 = IDLE, 3 = CLB, 4 = FLX, 5 = TO (maybe more if there are more positions?). There are several ways to assign an axis to control lvars, but the easiest way would be ti define your own preset. There are already two presets available for this on the MF HubHop site - FNX320 THROTTLE LEFT LEVER SET and FNX320 THROTTLE RIGHT LEVER SET, but these are for potentiometers with a range of 0-1023. You can define your own preset based on this but adjusted for your axis range (probably -16384 - +16383). I can help further if you want to try this. Also maybe try the new beta 7.3.6c, available in a post at the top of this forum. This should fix any connection issues that some folks are experiencing recently. John

That is a bit of a pain, but you can also use the control numbers to execute presets via offset 0x3110, but it can be troublesome as the control number is based upon the position in the file. To prevent this changing, you need to use the myevents.txt file and not install the events.txt file. There are some details on this approach in the manuals. No point in doing that as this will not reload the lvar offsets. I think these may be read when the WASM/WAPI connection is established, but it maybe before. Best to restart FSUIPC7 to pick up changes to this section. Yes - the preset just increments by one each time it is called, so even numbers are off, odd numbers on. Strange! I would still try using 0/1 (i.e. toggle) rather than incrementing on each press, at least to see if that is valid. I am not sure. How/where are you assigning? Please attach your FSUIPC7.ini and FSUIPC7.log files, the latter with logging for Events and Buttons & Keys activated, as well as offset monitoring on the offsets you are using, Also try listing the lvars after you have updated them, to confirm they are actually being updated. Also, there are some connection issues in the latest few releases. Hopefully these are now resolved in the latest beta, so please update to this version, available here: John

The latest beta is now available for download here: Hopefully this should fix any remaining issues. John P.S. I have updated the title of this post, Please remember to give any new post an appropriate title so that others with the same issue can find it easily and not submit the same issue. Your original title 'FSUIPC7' means nothing - every post in this subforum is about FSUIPC7!

That version was actually 7.4.6b, although it was logged as 7.4.6a. Anyway, there are still some minor issues in that version, mainly when ending and then starting a new flight. Hopefully these are all fixed now in the latest beta, 7.4.6c, available here: John

The latest beta which should hopefully fix all connection issues is now available here: John

Maybe some connection issues in that version - please update to the attached, Any issues, please attach your FSUIPC7.log and .ini files. John FSUIPC7.exe

There are some issues with the sim data connection that seem to present at the moment, so it could be due to FSUIPC7 not initialising the offsets correctly and so not allowing clients to connect. Seems to be a lot more reliable in the attached version if you would like to try it, If you get the same issue, show me/attach your FSUIPC7.log file (located in the FSUIPC7 installation folder). I will test this further and release when happy, hopefully over the weekend or early next week. John FSUIPC7.exe

There are some issues with the sim data connection that seem to present at the moment, so it could be due to FSUIPC7 not initialising the offsets correctly and so not allowing clients to connect. Seems to be a lot more reliable in the attached version if you would like to try it, If you get the same issue, show me/attach your FSUIPC7.log file (located in the FSUIPC7 installation folder). I will test this further and release when happy, hopefully over the weekend or early next week. John

I don't think so but I am not sure... the devices should still be visible with the same GUIDs, although the ids for the problematic device will change bit the others should stay the same. Don't do anything after this change - show me the files first as some further updates may be needed.

This is a VAMSYS issue - please contact them for support. They can advise me if there is a problem with connection to FSUIPC7. I cannot help with 3rd party apps. John

Looks like the preset name is not being saved for key assignments when the preset is selected from the Find Preset dialog box. I have corrected this in the attached version if you could try it: FSUIPC7.exe John

What app? Try contacting the support for the app you are using. What version of FSUIPC7 were you using begore the update? Please attach your FSUI{C7.log file.

Your scan shows 8 HID devices (4 distinct, with 2 Button Box Interface and 2 Virtual joystick). Disconnect these: Button Box Interface (both) Button Box Interface BBI-64 Virtual joystick (both) BU0836 Interface The script I attached removes the registry setting for these devices. If you look at your JoyScan.csv file, you will see a discrepancy between the HID scanning (first section) and the Registry scanning (second section). These two sections are then matched/merged with your current user settings (third section) to produce thee matched/decided settings (fourth section). The incorrect entries are these in bold: The .reg script removes all the entries for these 6 devices (4 distinct types). Hopefully, when these entries are removed and your devices reconnected, it will add the correct entries. John

I only provide this file. It is generated from the community-driven effort led by MobiFlight, and the source is here: https://hubhop.mobiflight.com/presets/ Note that if/when defining your own presets, you should do this using the myevents.txt file. Otherwise you will lose your changes as the events.txt file will get updated/overwritten each time you install/update FSUIPC7. If any events in the events.txt file, provided by MobiFlight, are not correct, then you should submit changes/updates on the HubHop website. This is the community driven resource for these events/presets. John

Can you please attach your FSUIPC7.ini file complete and in its original format. This is because there is an error in your assignments. If you look at them, they are all like this: 433=38,8,P,0 -{Up: Press=Preset Control }- i,e, assigned to a preset but no preset was selected. An assignment to a preset should look like this: 239=83,8,PParking_Brake_Set,0 -{S: Press=Preset Control }- i.e. with the name of the preset after the P. How are you adding these assignments? For key assignments, you need to Confirm before clicking Ok - are you doing this? Otherwise, please let me know how you are generating assignments to presets with no preset specified. Also, please check what version of FSUIPC7 you are using., If it is not 7.4.5, please update.

From http://fsuipc.com/ Can you please switch to using joyletters: change the following in the [JoyNames] section of your FSUIPC5.ini file: AutoAssignLetters=Yes Then run P3D/FSUIPC5 and exit. This will switch to using JoyLetters. Your JoyScan file shows some confusion in your registry and needs to be cleaned. First, run regedit and take a back-up of your registry. Then, disconnect your devices, and download and run (i.e. double-click) the attached file - this will remove registry entries for 4 of your devices. Reboot and reconnect your devices. Then run P3D/FSUIPC5 and exit, then show me/attach your ini, log and JoyScan.csv files again. removeDevices.reg

Try logging offset 0B63 (as U8 in Hex) to see if this offset is being used. Does it update correctly when using the PMDG->Vehicles->Failure Menu? If you also log events, what events do you see? When your lua script sets/clears the bits in this offset, do you see the same values and events? As you are using a PMDG aircraft (which one?), it may not be responding to standard FS controls. Again, use logging. If you are sending the same control in an event callback that is handling the control, then you will get into an infinite recursive loop. Maybe check the event parameter - is this different between a toggle on and a toggle off (some toggle controls do use a parameter)? If so, you can use that to distinguish between toggle on and toggle off, and only send the control for one parameter. Otherwise, try using event.offset instead, and again only send the required control when needed. What events do you see when you use the menu to toggle failures on and off? Check if a parameter is needed. If you need further help, please show me your lua script, and your ini and log files, the latter with logging for Events activated as well as logging for offset 0B63, and maybe also lua plugin logging. One log file should show you toggling and clearing the brake failure via the PMDG menu (without your lua running), and another log file showing what you are trying to achieve with your lua script running.

@Marcolinno Does your parking brake work with 7.4.4?

Yes, of course - please see the lua library documentation: I have moved your post to the FSUIPC7 / MSFS sub-forum. John

Can you please attach your FSUIPC5.JoyScan.csv file please, as well as your FSUIPC5.ini file. Note that you are also using an old and unsupported version of FSUIPC5, 5.131 - please update to the latest and only supported version, 5.157. John