John Dowson

Note FSUIPCv7.3.3 has been released so please download and try that before reporting back. Note, however, that this also contains no changes that would affect the auto-start, but contains a few updates that may have caused FSUIPC7 to not start certain threads in certain conditions. If you still get your issue with this version, please show me your FSUIPC7.log file as well as providing information as to whether FSUIPC was auto-started or not, and if auto-started when did you actually start FSUIPC7. Also, you find FSUIPC7 'doesn't work', please try disconnecting and re-connecting from the MSFS menu. John

Hi Leo, The WASM has ben updated and released with v7.3.3 so please download and use that version before reporting back.

Possibly, but not having this aircraft I do not know - the OP should certainly try the condition lever controls. Thanks for the hint, John

I will update the trial license tomorrow (or maybe this evening if I get a chance)...

Was this test with the new WASM module I poste above? I forgot to update the version number so it is difficult for me to tell. Please try the attached version where I have update the version number - I have also added an extra logging statement to log the value of UseAirLocForHvars being used. I would like to get to the bottom of this issue if possible, so please ret with the attached and report back, including your FSUIPC_WASM.log file. Thanks, John FSUIPC7_WASM.wasm

If you mean FSUIPC7 does not auto-start with MSFS, please see item 3 under Problems running FSUIPC7 in the README.txt file. For any further issues if that does not solve your problem, please show/attach your EXE.xml file. Presume this is a separate issue...if this occurs, exit FSUIPC7 and then show me/attach your FSUIPC7.log file. John

What are you finding baffling? Just create a macro file (e.g. QW787.mcro) in your FSUIPC6 installation folder. Add the following entry: 1=L:QW_OH_LDG_LEFT_SWITCH=Toggle You will then see that entry in the assignments control drop-down where you can assign to a button. It really isn't that difficult... John

No, sorry - that resource is for MSFS2020, and not relevant to P3D aircraft. Try activating logging and flip the switch to Auto in the UI to see if any controls/event are logged. Maybe you need to use an event in conjunction with setting the lvar value. And check what the lvar value is when the switch is in the auto position. Other than that I can't really advise as I don't have this add-on. John

Quite a few add-on aircraft don't use the standard controls...For such aircraft, you need to look into custom control, if provided (although I don't think there are any for the QW 787), lvars or mouse macros. The easiest way to assign to change/set/toggle an lvar is to use a macro file. See section Gauge local variable access (L:vars), by macro on page 39 of the Advanced User guide. You should try lvars first for the functions you want to implement, if there are suitably named lvars. Otherwise, you can try with a mouse macro. John

I don't have a copy or know where you could get hold of a copy, sorry. Maybe better to also ask over on Avsim for this. John

There should be 3 presets for the FBW HDG push/pull button: HDG_Pull#(>K:A32NX.FCU_HDG_PULL) HDG_Push#(>K:A32NX.FCU_HDG_PUSH) HDG_Push_Pull_Toggle#(A:AUTOPILOT HEADING SLOT INDEX, Number) 1 == if{ (>K:A32NX.FCU_HDG_PUSH) } els{ (>K:A32NX.FCU_HDG_PULL) } They should all be included in the events.txt file that comes with the latest version of FSUIPC7, and so assignable in the controls drop down menu. If they don't work, then they are either broken or not applicable to the version (experimental) of the FBW A32NX that you are using. Either way, I can't help with this and you should ask about this on the MF support/discord channel. John

Btw, this is not cached values... This is the location for your preferences/files that will not be affected by FSUIPC updates. If you want to preserve your hvar files and ini settings, you should use this location. Anything you change in the Community\fsuipc-lvar-module folder could change on an update. John

Just checked the code, and it looks like I forgot to initialise the default value for the new ini paramater UseAirLocForHvars to false... Sorry about that. Please try with the attached WASM - use it to replace the one in your Community\fsuipc-lvar-module\modules folder: FSUIPC7_WASM.wasm If you get the same problem with that one, please attach your FSUIPC_WASM.log file (preferably with Debug enabled) and I will take a look. John

The load flight function has been broken in MSFS since inception. I'm not sure of the current status as I haven't checked this for a while. From the current documentation, this function is now working. However, there still seem to be issues in the Flight Save MSFS SimConnect function (as well as the Flight Plan Load function), so the problem may be in the flight save file. I will look into this further (next week now) and maybe raise another bug report with Msfs/Asobo. Not much I can do about this in FSUIPC7 I'm afraid, as FSUIPC relies on the corresponding SimConnect functions to do this. John

You could also add your own preset to do this, which maybe easier. For example, for the run/stop toggle, create a file called myevents.txt in your FSUIPC7 installation folder, and add the following line: CRJ Engine1 Run-StopToggle# 0 (>K:MIXTURE1_RICH) 0 (>K:TOGGLE_FUEL_VALVE_ENG1) 0 (>K:TURBINE_IGNITION_SWITCH_SET1) You can then assign to 'Preset: CRJ Engine1 Run'. You can add similar presets for engine 2 and also for off. Note that presets are only loaded when FSUIPC starts, so if you make any changes, restart FSUIPC7 to take affect. John

I've checked this and they don't change. This changes the run/stop from off to Stop, but I can't get it to Run using this. I've also tried Starter 1 Set control and this achieves the same thing. However, overloading assignments and sending the following 3 controls toggles between run/stop: MIXTURE1_RICH TOGGLE_FUEL_VALVE_ENG1 TURBINE_IGNITION_SWITCH_SET1 and Run switch to OFF: MIXTURE1_LEAN TOGGLE_FUEL_VALVE_ENG1 To overload your assignments, to need to manually edit the ini. Assign to the first control and save, then, with the FSUIPC button assignments window open, open your FSUIPC7.ini file in an editor. Locate the line for the assignment just added, then place a ; after the '=' on that assignment line and save. In FSUIPC, reload your assignments. You can then assign to the second control. Repeat to assign to the third control. Once all assignments are done, remove the ; you added, then reload your assifnments one more time. This is how my ini looks for button assignment to run/stop toggle: 70=P174,7,C65983,0 -{MIXTURE1_RICH}- 71=P174,7,C66494,0 -{TOGGLE_FUEL_VALVE_ENG1}- 72=P174,7,C67017,0 -{TURBINE_IGNITION_SWITCH_SET1}- There are also other control combinations that work. See https://forums.flightsimulator.com/t/map-engine-run-stop-to-device-button-citation-cj4. John

You are probably better of installing the WT mod for the CJ4 and using the MobiFlight presets for this (see https://hubhop.mobiflight.com/). You could try the presets with the vanilla CJ4 - they may work or not... If you want to use the vanilla CJ4 and the MF presets (for the WT mod) don't work, try monitoring offsets 0x0892 and 0x092A (which hold the General Eng Starter simvar for engines 1 and 2 respectively) and see how they change when you run/stop the engines in the UI. If they change values accordingly, you can try assigning your buttons to set the values in those offsets using the Offset Word Set control with the appropriate parameter. You could maybe also try the Toggle Starter 1/2 controls. John

Then that is the way the lvar works. What switch/function for what aircraft are you trying to assign? Have you checked the MF HubHop resource to see if there is a preset available?

Are they still there? Better to keep your own hvar files in the other location. You don't need to do this as No is the default value. Understandable as doing this doesn't change anything. Don't restart MSFS - try restarting FSUIPC7. Before you do this, please check for that line in the FSUIPC7.log file as indicated in my previous post. To see details on the loading of hvar files, set Debug level logging in the FSUIPC_WASM.ini file and take a look at your FSUIPC_WASM.log file. You could also consider switching from using hvar files to presets. You can activate hvars via presets without making the hvars known to FSUIPC7. To activate a hvar via a preset, create a file called myevents.txt, and in it add lines of the form presetName#>(H:hvarName) You can then assign to the presetName in the drop-down as 'Preset: presetName''. John

Which folder is your hvar file under, and is it still there? It takes values Yes and No (default) and goes in the FSUIPC_WASM.ini file, preferably in this file located in your WASM persistent storage area, not in the one under your Community\fsuipc-lvar-module folder. if you don't know what this means, please see the Advanced User guide. However, it does look like i forgot to add this new ini parameter to the manual - i will do this for the next update. How are you starting FSUIPC7 - manually or via auto-start? I have noticed that since the latest MSFS update, FSUIPC7 is sometimes/occasionally not starting everything that is needed. This seems to occur occasionally when auto-started, and when manually starting FSUIPC7 when MSFS is in the main menu. I am currently looking into this. This occurs if/when the following message is not reported (in your FSUIPC7.log file) by the time you are ready to fly: -------------------- Starting everything now ---------------------- If this is the case, you could try restarting FSUIPC7 once you are ready to fly and things should be ok. If that is not your issue, please attach your FSUIPC7.log and FSUIPC_WASM.log files and tell me the name and location of your hvar file. Note the name should probably change if you set UseAirLocForHvars to Yes, so best not to set this for the time being. John

@Gianni4 I'm not sure if thus is of interest (or if you solved your issue), but for the latest FSUIPC7 beta I have added a facility to allow FSUIPC7 to use a global keyboard hook to receive keyboard input rather than getting it from the FS via SimConnect. This may (hopefully) detect the key presses sent from your controller. This version is currently available in the following post: John

Ok. Then try activating logging for events, and then move the Fuel-Control-Switch to its various positions to see if any events are logged. If they are, try assigning to them. Also, maybe take a look at the MF preset list (https://hubhop.mobiflight.com/) to see if there are any presets available for the SWS Kodiak. There are different control numbers as they are different controls: 66292 AXIS_MIXTURE_SET 65773 MIXTURE_SET See the auto-generated document 'Controls List for MSFS Build 999.txt' in your FSUIPC7 documents folder for a list of MSFS provided controls. The difference between these is the range - MIXTURE_SET uses 0 to +16383 whereas AXIS_MIXTURE_SET uses -16383 to +16383 But you probably shouldn't be using the axis mixture controls if the mixture control is not an axis in the aircraft itself... And I don't understand why you want to map a button to Mixture Set - for buttons you would normally use the rich/lean (and inc/dec) controls - as you seem to be doing... I also don't have the SWS Kodiak 100, so cannot really advise on how to configure FSUIPC for this aircraft. This post on the Asobo forums may help - it refers to the Bravo but should be nearly the same for other controllers: https://forums.flightsimulator.com/t/kodiak-100-mixture-lever-on-honeycomb-bravo-with-fsuipc/506489 John

Hi Detlef/ @dedel, could you try the attached FSUIPC7.exe, v7.3.3b. You can use a global keyboard hook for keyboard input (instead of receiving keyboard input via SimConnect) by adding the following to the [General] section of your GSUIPC7.ini file: UseKeyboardHook=Yes The hook is set when you leave the MSFS main menu, and removed when you go back to the main menu. Let me know if this enables FSUIPC7 to see the key presses from your button box. John FSUIPC7.exe

No problem. John

Ok, that is interesting... I don't understand how this can cause your issue though, as requests to update lvars from a client are ignored if the WASM is configured to update itself. I may look into this further when time permits to find out exactly what is happening in this configuration. Thanks for reporting back, and I am happy that you have now found the solution and cause. John