John Dowson

Ok, then you can probably use that... Was the 0 value when the rudder was at the central position? If so, you need to determine the values for maximum left and right deflection: move the rudder full left/right, and list the values again. What is the update value when fully deflected? 1193 is just the id of the lvar and can be ignored. The 'Set' button always works and is never disabled as far as I remember. What values did you try and set? If you set WAPI debug level logging (Log -> WAPI -> Debug) then you should see the control to update the lvar logged (in the logging console). It is helpful to determine the max/min values for this lvar, and then try setting those values, as well as 0, and see if the rudder moves/reacts. If this lvar is writeable and working, I can show you how to use this to control the rudder, but I need to know the max/min values for full right/left deflection. If 0 is the rudder centre position, then the lvar will probably have a range of either -1 to + 1 (as a decimal), or -100 to + 100 (as an integer).

@MD80PROJECT Sorry for the delay. I have tested all those offsets and they are certainly available for general use, so you must either be already using those offsets or have something else wrong. As I said, logging should help. Here is the lua script I am testing with (also attached below): local offset = 0x6700 local lvar = "L:YokeLeftVis" local loggingActive = false -- change to true for additional logging messages local lvarValue local offsetValue -- event function to update offset when lvar is updated function lvarUpdated(lvarName, value) lvarValue = value if offsetValue ~= lvarValue then if loggingActive then ipc.log("lvarUpdated: Updating offset with lvar value " .. lvarValue) end ipc.writeUB( offset , lvarValue) elseif loggingActive then ipc.log("lvarUpdated: Not updating offset as already has correct value") end end -- event function to update lvar when offset updated -- NB: to assign to update the offset, use the control: -- Offset Byte Togglebits -- using the offset used and a parameter of x1 function offsetUpdated(offset, value) offsetValue = value if offsetValue ~= lvarValue then if loggingActive then ipc.log("offsetUpdated: Updating lvar with offset value " .. value) end ipc.writeLvar(lvar , value) elseif loggingActive then ipc.log("offsetUpdated: Not updating lvar as already has correct value") end end event.Lvar(lvar, 100, "lvarUpdated") event.offset(offset, "UB", "offsetUpdated") ipc.log ("lvar2Offset script running using lvar '" .. lvar .. "' and offset " .. offset) This script allows the offset to be updated to set the lvar, and any changes to the lvar will update the offset. Note that I am only using a byte to hold the lvar value - this is all that is needed for lvars that have values 1/0. John lvar2Offset.lua

There seems to be an issue that can prevent key presses being received by FSUIPC7 from MSFS that will stop both key assignments and 3rd-party hot-key assignment from working. If you have an issue with key assignments or hot-key assignments (from 3rd party add-ons) not working, then please first check/verify if key presses are being received by FSUIPC7. To do this, activate logging for Buttons & Keys (Log -> Buttons & Keys), open the FSUIPC7 logging console (Log -> Open Console), give the keyboard focus back to MSFS (i.e. click on the MSFS window) and then press any key. In the logging window, you should see the key press/release events logged, such as the following: If you do not see any key presses logged, then key presses are not being received by FSUIPC7 from MSFS. ** NB: you should have an aircraft loaded and ready-to-fly when testing for key presses, as they are not requested until the first aircraft is loaded and ready-to-fly ** To correct for this, you can perform one of the following operations: 1. Disconnect from MSFS (MSFS -> Disconnect) and then re-connect (MSFS -> Connect), or 2. Exit FSUIPC7 and restart This seems to be caused by a timing issue, when the SimConnect calls made to request the key presses are accepted (i.e. no errors produced) but are not acted upon. To correct for this, you can try increasing the delay from when MSFS is detected by FSUIPC7 to when it tries to connect. To do this, you need to increase the value of the DetectToConnectDelayAuto ini parameter, located in the [General] section of your FSUIPC7.ini file. Locate this parameter and increase its value by 5 (seconds) and try again (i.e. restart MSFS, let MSFS start FSUIPC7 and then test for key presses as shown above). If you get the same issue then repeat, i.e. increase the DetectToConnectDelayAuto ini parameter by 5 and try again. Once you have determined the correct value for the DetectToConnectDelayAuto ini parameter, you can then set/update the StartUpTuningDoneVersion ini parameter to -1: StartUpTuningDoneVersion=-1 This will prevent FSUIPC7 from further automatic tuning of this parameter,

There is no point just saying that it is;n't working. If you want help, please explain what you are doing and show me your files - I need to see your FSUIPC7.ini file, so that I can see your assignments, and your FSUIPC7.log file which shows me what is happening, and preferably generated with logging for Buttons & Switches activated. Have you used presets before? Are other presets working? Have you installed and activated the WASM? Have you read the documentation on using presets?

No need to attach if it is now working. However. you should not need to restart for this to work, If you find that key assignments are not working, exit FSUIPC7 and then attach the log file. The log file is in the same place as the ini, in your FSUIPC7 installation folder. If you can't see it, you have Windows Explorer set to hide the extension of known file types. There does seem to be an ongoing issue where key presses are sometimes not being sent from MSFS to FSUIPC7. If this happens, you can try disconnecting and re-connecting to MSFS (using FSUIPC7's MSFS menu) or restarting FSUIPC7. This also seems to be due to the timing of when FSUIPC7 connects to MSFS when auto-started, so you can also try increasing the DetectToConnectDelayAuto ini parameter by 5 (seconds) or so.

For lvars, use Add-ons->WASM-> List Lvars - do any look like they control the rudder? If so, you can try setting them using Add-ons->WASM->Set Lvar. For Input Events, use Log->List Input Events to see what is available. If either an lvar or an input event is available, I can help you assign to use these. Ok, then you need to try lvars and Input Events. If its also not possible in MSFS, you should ask about this on the aircraft support forum.

Can you please attach your files and not screenshots. I need yo see your FSUIPC7.ini and FSUIPC7.log files, the latter generated with logging for Buttons & Keys and Events activated: start MSFS and FSUIPC7, activate the logging (Log->Buttons & Keys, Log->Events), load your aircraft, test the assignment then exit FSUIPC7 and attach those files. John

The log file shows the axis controls being sent and applied correctly, so it looks like this aircraft is not responding correctly to this rudder control. Try assigning using Send direct to FSUIPC calibration to see if that makes a difference. Did you check for any lvars or Input Events that could be used to control the rudder? Does the rudder function correctly when assigned in MSFS?

What was the issue? Seems like there was a space before the folder name (" Fsuipc") which could cause issues...

Did you try the preset FNX320 Glareshield Master Warning Captain Button Press? That preset uses the lvar L:S_MIP_MASTER_WARNING_CAPT. If that us not the correct one, you need to check to see if there are any events or lvars that you can use. You can use FSUIPC's logging facilities to assist with this, As I do not have this aircraft, I cannot really help much with this. You can also post of the Mobiflight Discord server, in the MSFS2020 channnel - this is the place to ask about presets for specific aircraft functionality.

Ok. If the implementation of this AP is different from the real thing, I cannot do anything about this. Try asking about this on the support for the aircraft.

Sounds like FSUIPC7 wasn't auto-started. Please show me / attach your InstallFSUIPC7.log file. For any and all issues with auto-start, see the FAQ entry:

1. You are still using 7.4.11 - please update *Ok, I see you posted for an issue with the update - I have responded there 2. You did not activate the required logging so the log file is useless 3. Your ini file is now empty except for the one assignment to the rudder?

You should always attach files after exiting FSUIPC7, not before. Try zipping/compressing. You are also using an old and unsupported version of FSUIPC7, 7.4.11 - please update to the latest version, 7.4.16. Looks to be. You could try changing the rudder control used, from Rudder Set to Axis Rudder Set (which you use with the DC-6 profile, although you only seem to have a DC-3 in that profile). Also take a look to see if there are any Input Events or Lvars that look like they may controller the rudder (using Log->List Input Events and Add-ons->WASM->List Lvars)

The usual cause of such behavior is dual assignments, i.e. having the rudder assigned to two different axis. Can you do the following please: once MSFS and FSUIPC7 have started, activate logging for Buttons & Keys, Events and Axes Controls. Load your aircraft, then move the rudder to full left, then full right, then back to center. Then exit FSUIPC7, and show me / attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. John

Did you read that Appendix? For a slave/client PC, you do not need MSFS installed and you do NOT install FSUIPC via the installer - you copy it across. Please read that appendix. If you have installed MSFS on your client PC then you need to run it at least once before running the FSUIPC installer. If it does not install, what does it say? Have you checked the InstallFSUIPC7.log file? Check that for any issues, and you can also post/attach it here. John

FSUIPC will do nothing with such sections (i.e. they will be ignored). FSUIPC only uses certain section names - others will be ignored. However, there position in the ini file may change when other sections are re-written, but I am not sure about this - just try it. John

Isn't this the same behavior you see when you push the button in the VC?

This is because you are using offset 0x2FA8, which is HSI BEARING, which, as pointed out earlier, holds: You should try with offset 0x0580 (PLANE HEADING DEGREES TRUE) or 0x2B00 (PLANE HEADING DEGREES GYRO). If you want to use PLANE HEADING DEGREES MAGNETIC, you would need to add this to an offset. Note also that for some offsets, you will need to convert the offset value to degrees before applying (e.g. for 0x0580 you have to *360/(65536*65536) to convert to degrees). Or just use a preset or calc code - easier!

Before I check this (and I am pretty sure that the details are correct - EVERY key I have checked so far has been correct), PLEASE make sure you have read the Invalid Key Section of the README.txt and/or in the installation and registration manual. All support requests on invalid keys are always due to one of three issues: - not entering the details correctly - not updating your VC++ redistributables - interference from anti-virus software

First, you are using 7.4.15 - please update to the latest and only supported version, 7.4.16. Your ini file is also a bit of a mess as it looks like the GUIDs of some of your devices have changed, and rather than correcting this you have re-assigned to the new joyletter. I have tried to correct for this in the attached ini file, so can you please try this. But as I said, isn't it 1 to activate and 0 to release? Anyway, your assignments were confused as you had assignments to PARKING_BRAKES with a parameter, and this is a toggle control that doesn't take a parameter, and also assignments to PARKING_BRAKE_SET, which does take a parameter. Anyway, try the attached ini and if you have issues with this, please activate logging for Buttons & Switches as well as Events, and show me/attach your FSUIPC7.log and FSUIPC7.ini files. Normally you would use TOGGLE_FUEL_VALVE_ENG1/2, which you have assigned to buttons 17 & 16 of your JoyWarrior A8-16 controller. Do these not work? As I don't have the ProSim 737, I cannot advise on what to use. Try using FSUIPC's logging facilities and see what control is logged when you cut-off in the VC, and then try assigning to that. Any issues with this updated ini, please re-attach it together with your FSUIPC7.log and FSUIPC7.JoyScan.csv files and explain the issue. FSUIPC7.ini John P.S. I thought with the latest versions of the ProSim 737, it is recommended to use ProSim itself for (most, if not all) assignments ...is this not the case?

You cannot add 'comment sections', and I am not sure about comments outside sections - check the documentation (via google) for comments in windows ini files. Trailing comments are allowed in most FSUIPC7 ini file sections but not all, and not on the section label itself. For example, this is from the Advanced User guide on comments in the [Buttons] and [Buttons.xxx] sections: Also, as I said, the FSUIPC7.ini file is a standard windows ini file and the standard rules on comments apply except where documented (e.g. we allow trailing comments on most but not all entries). John

Pete retired many years ago now... What do you mean by 'but using it reverses the settings.'. Normally you would activate with a parameter of 1, and release with a parameter of 0. Have you tried that? What are you using/assigning to for this? Please attach your FSUIPC7.ini and FSUIPC7.log files. I don't have the ProSim 737, but I can take a look to see if I can see anything. What do you mean by this? If MSFS is not installed on the 2nd PC, then you cannot install FSUIPC7 via the installer. If using FSUIPC7 on a client PC (i.e. without MSFS installed), please see Appendix 4 of the Advanced User guide - this gives instructions on how to install and configure FSUIPC7 on a client PC.

Could you please attach files rather than pasting their contents. Also, please make sure that you exit FSUIPC7 before doing this. Also please provide an explanation to accompany the files. Were the presets not working at all? The log shows that your 777-800 profile was loaded and the preset calc code was sent to the WASM. If they were not working, I also need to see your FSUIPC_WASM.log file, with Debug level logging activated in the WAPI. Please see the WASM section in the Advanced User guide on where this file is located and how to set the log level in the WASM. Please also activate Debug level logging in the WAPI (Log->WAPI->Debug). Your files do show some issues: 1. There are some reconnection attempts at start-up as your DetectToConnectDelayAuto ini parameter is set too low. This would correct itself automatically if you went back to the main menu before exiting, as these would be detected and then the auto-tuning would kick-in on the next restart. However, you can do this manually by setting DetectToConnectDelayAuto=110 in the [General] section of your FSUIPC7.ini. 2. You have many full aircraft titles in your [Profile.xxx] sections. You should switch to using substrings so that the substring matches all liveries. So for example, for the [Profile.B737] section, just use: [Profile.B737] 1=PMDG 737 and for the [Profile.A320 Fenix] section: [Profile.A320 Fenix] 1=FenixA320 2=Fenix A320 3=Vueling 4=Fenix Airbus A320 5=Airbus A320neo v2 6=fnx-aircraft 7=Air Canada CFM [Not sure about entries 3 and 7...] Do this for all your profile aircraft., i.e. use substrings that catch the aircraft you want to use with the profile rather than the full aircraft name. You should get into the habit of editing the aircraft name to be a substring whenever you add one to a profile.

There has been no change in 7.4.16 that could effect preset operation. You can start FSUIPC7 manually or have it auto-started with MSFS, which is the recommended way. FSUIPC7 should function the same regardless of how or when it is started. This warning can be safely ignored. There are a couple of things that could cause this behavior. Please show me / attach your FSUIPC7.log and FSUIPC7.ini files, generated when you experience this issue. i.e. when you get this issue, exit FSUIPC7 and attach those files (from your FSUIPC7 installation folder) here. John