John Dowson

Can you also please attach your UH1.ini profile file please? Are your axes calibration not profile specific (the profile-specific checkbox is not checked)? How do the in/out values move when you move the axis? Does this apply to all aircraft, just helicopters or just specific helicopters? You also have a lot of joystick/controller scans in your log file - do you know what is causing these?

Just assign to those presets via the UI key assignment panel. Check the Select for Preset checkbox and then the Find Preset.. button and navigate to the preset you need from the MobiFlight root. You can also search for available presets first using the MobiFlight HubHop site: https://hubhop.mobiflight.com/presets/

First check if the calculator code is being sent and applied in the FSUIPC WASM module (presumably you have that installed - if not, you need to install that). To do this, set Debug level logging (via the FSUIPC_WASM.ini file) and check the FSUIPC_WASM.log file to see if the command/code is logged. Probably. Hvars are only known (i,e, loaded and provided) by name if they are given in an aircraft-specific *.hvar file. However, they don't need to be known if using them via calculator code.

Licenses sent.

Are you using complex aircraft, many add-ons and/or add-on scenery? Could you also please attach your FSUIPC_WASM.log file if you get a WASM crash (preferably with Debug level logging enabled via the FSUIPC_WASM.ini file) An issue has been identified when scanning for lvars that can cause a crash, but this looks to be an issue in MSFS, not FSUIPC. There is a long discussion/investigation on this issue here: To reduce the chance of this crash, try setting the WASM ini parameter: LvarScanFrequency=0 and also maybe increase the LvarScanDelay parameter to 8 or 10 seconds: LvarScanDelay=8

Do you mean you updated the VC++ redistributables? Can you let me know your order number and I will check your details here. Do NOT post your key details!

Yes - see the ini parameter OpenOnStart:

Can you please explain what you mean - is your throttle recognized? Can you show me / attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files. John

👍😎

Also I see you are running FSUIPC with elevated privileges: Make sure you are also running MSFS and all other programs with elevated privileges, otherwise they won't connect. Always better to run with standard privileges unless you have a good reason not to. John

FSUIPC does not necessarily start MSFS. The desktop icon, installed by the FSUIPC installer, starts MSFS. In the default configuration, with auto-start using the EXE.xml, it is MSFS that starts FSUIPC7. As I said, for ALL issues with auto-start, please see that FAQ entry I referenced. This is located in your WASM persistence area, which is: I don't think it will show much but worth checking. Make sue toy attach it after you have shutdown MSFS. I don't understand this as FSUIPC is doing nothing with your MCP as far as I can tell. I can only think that it must be one of the programs that is started/stopped with FSUIPC: Maybe try removing them (temporarily - comment them out), and start each one manually to see if one of them is causing this issue.

Can you show me/attach your FSUIPC7.log file. I can take a look at that for errors, but otherwise you need MobiFlight support if the problem is with MobiFlight. Also check that you are running MobiFlight and FSUIPC at the same privilege level - they won't connect otherwise. John

There is no specific logging for profiles. I think the only thing that is logged is overridden buttons when a profile is loaded (when logging for buttons/keys is activated), e.g. The easiest way to see if a profile has been loaded is to open the axis assignment panel, or the button assignment panel and check the profile-specific checkbox. The profile name will be displayed in the panel title bar.

I so not support MobiFlight, only FSUIPC. Have you verified FSUIPC7 is actually running? Can you see it sitting in your system tray? Does the key combination Alt + F open the FSUIPC7 main window? If not, FSUIPC7 isn't running.

FYI, I have now released FSUIPC6 version 6.2.1. Please update to this version. John

You can do it that way, but its generally easier to use the togglebits controls. No idea what the 'Alpha controls listing' is. For standard controls (i.e. FS controls + FSUIPC-added controls), see the documentation. All FS controls are listed in the Controls List for MSFS Build 999.txt file, and FSUIPC-added controls are documented in the Advanced User guide, starting on page 28. Yes, that would be nice, but I doubt very much that I would ever have time to implement such UI updates. I would love to completely re-write the UI to update it to a more modern toolkit, but again this isn't going to happen. I spend most of my time on support, and remaining time on keeping up with MSFS/P3D updates, adding new functionality and correcting bugs, as well as updating documentation, testing, preparing releases, etc. I have to prioritize and updates that are 'nice-to-have' but take several weeks or longer to implement are just not worth my time. Allowing for a second parameter to MSFS events is something I would like to implement, but this also is quite difficult as there is no way to know which events take two parameters and which take one. I would need to go through the documentation to discover this, and this would have to be done after each documentation update. And also note that the updated SDK allows for up to 5 parameters to event, not just 2 (although I do not know if any events that take more than 2 parameters at the moment). And as there is a workaround for this (i.e. by defining a preset), this is not currently that high on my list of things to implement. No. All offsets are initially initialized to 0 on FSUIPC start-up, but not when 'ready-to-fly'. So, once you have set a value in such an offset, it will remain there until you change it. If you want to initialze your user-defined offsets, then do this yourself. However, this is rarely needed if you are using them to hold lvar or input event values as these will be set when the lvar/input event is received. John

Also, are you running the CPFlight MCP driver (and if not, why not?)? I believe this uses the FSUIPC WASM module. Check that this is still running (via the devmode debug console window), or show me the FSUIPC_WASM.log file, but attach only AFTER exiting MSFS. There is an issue where the WASM sometimes can crash - if this is the case, there are some config. parameters you can set that will make this crash less likely. But best to confirm if this is an issue or not first. John

For all auto-start issues, see The log file you attached shows no issues, but also shows that you either attached it when FSUIPC7 was still running, or FSUIPC7 had crashed. Please always exit FSUIPC7 before attaching files. Does not connect to what? If the MCP doesn't connect to Prosim, this is nothing to do with FSUIPC. There are no com ports configured in your FSUIPC7.ini file. Can you switch back to the previous version and see if it works with that please. If not, it is not an FSUIPC issue. The previous version, if you don't have it, is available here. John P.S. If access is denied on a port, then it could be a permissions issue or something else could be using / blocking the port. Make sure toy are running everything at the same privilege level, and reboot your PC.

The parameter is the bit (in the byte) to toggle. x1 is but 0 (2^0). If it was bit 1 you wanted to toggle, you would use x2 (2^1=2), bit 2 would be x4, etc. And you toggle multiple bits by summing. So x3 would toggle bits 0 and 1. Basically its the mask of bits to toggle. A byte cannot hold a decimal value - you would need 4-bytes for that (a float). FSUIPC does the conversion of the original decimal value of the Input Event using the modifier you specify in the line where you add the input event to an offset. No, you didn't try this - that was SET EXTERNAL POWER, which requires two parameters. The toggle control only needs one. You add it to an offset and toggle that offset, as Al showed in the previous post. As its a toggle control, you don't need to gave a condition on this. If you did, you would just add an offset condition as explained in the Advanced User guide. John

If it helps the investigation here, I tried both of the above (assigned a different key to each one) and they both work to toggle the Longitude's external power on and off Thanks Al - I don't know why the OP just doesn't use those instead of messing around with input events and lvars. The easiest way is usually the better way...maybe @DaveSCUSA could explain why he can't use either of those, as he just seems to want to toggle on a keypress.

Trial key sent via PM.

Note also that some devices send a press on the first button press, and a release on the second button press, acting like 'sticky' buttons. For such devices, you need to assign on the press and release. You seem to be using some sort of button-box that sends key presses, no? If so, check it is sending the same key presses each time you press, and if the second press is a release, you need to assign to that as well. Otherwise, follow my previous posts and respond to them. And show me your assignments and log files so that I can see what is happening - these are needed as otherwise I cannot understand what you are trying to tell me. Finishing now for the day. I will review again tomorrow - and see if I can get access to the Longitude to take a look. John

You also said: I asked to see these assignments that work. Please show me them and we can go from there. If they are using Input Events, please log the offset holding the input event and see if that changes. If so, you can use one button and an offset condition on your two assignments. Otherwise, if an lvar changes, add that to an offset and use that for your offset condition. If the input event works on its own, you can also just write to the offset to change the value of the Input Event,

Sorry, what does this mean? But you need to check fist if the input event is sufficient. Normally, a properly implemented input event will do several things, such as triggering events (k-vars) and updating lvars, so you shouldn't need to do anything else but trigger the input event. But, as I keep saying, this depends on how things are implemented. You need to test. This doesn't make sense...of course you can change an offset with/on a button or keypress, using the provided offset controls. You can also do that in a profile - whatever you can do in general assignments, you can do in a profile. What is a 'mom button'?. If you mean a standard (momentary button), then I just call that a button (i.e. a standard button) - the other types are sticky buttons (i.e. stay in when pressed, and release when pressed again). If thats the case, I have already shown you - use overloaded assignments and an offset condition. BUT, you need to test the offset that you a are using, which is why I have asked you to monitor the offset that holds the Input Event. Did you try this? And input events have values, not off/on, although some may have a value of 1 for on and 0 for off. But input events seem to be like lvars - they are just a different type of variable that holds a value. To set/change this value, you just assign to the input event and specify the value as the parameter.

If it works with two buttons, foes the offset holding the Input Event change value? If so, you can use offset conditions. No, I didn't know this and find this confusing. I thought you were using the Input Event only, not lvars. Can you please show me the assignments that work, and/or explain what you mean. Not sure what you mean here, please explain. I am confused about your assignments and what is working. Why are you talking about offsets when the assignment is using input events (or so I thought)? If the input event works, you can try just using the input event offset and write to that. There are differences - compound functionality relates to the state of one button (or button flag) when another is pressed. For key presses, this just doesn't make sense. For key presses, you use modifier keys, not other conditional keys, hence the difference. Offset conditions are the same for keys as buttons.