
John Dowson
Members-
Posts
13,156 -
Joined
-
Last visited
-
Days Won
269
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
I have just created a FAQ entry for assigning an axis to an lvar - see That is NOT a standard FS control/event. It may be a custom event, or possibly an Input Event or lvar. You can list the lvars and Input Events to see if it exists there, Does the aircraft come with an SDK, or with any documentation on custom events? If so, please check that. Also, do you know the range of values that this takes? You can use custom events/controls in several ways with FSUIPC7: - using a <custom control> number - by defining a preset - by using an event file (*.evt). For this, you would need to know what the event prefix group is John
-
There are several ways to assign an axis to an lvar in FSUIPC7, but the easiest way is to use a preset. First, you need to know: 1. The name of the lvar that you want to control. You can list the lvars using Add-ons->WASM->List Lvars to see the available lvars. 2. The value range of your axis. Most axes will gave the range -16384 to +16384, however some potentiometer axes may have a different range (e.g. 0-100). To verify the axis range, you can look at the IN value in the axis assignment panel when you move the axis. 3. The value range that the lvar takes. To determine this, you can list the lvars to see the values. Move the axis you want to control in the Virtual Cockpit to one extreme, then list the lvars (Add-ons->WASM->List Lvars). Then move the axis to the other extreme and list again. This will give you the maximum and minimum values for the lvar. Once you have to determined these three things, you can define your own preset in the myevents.txt file, located in your FSUIPC7 installation folder. Note that this file will not exist by default - you need to create this file. The format of a preset definition is <preset name>#<calculator code> where <preset name> is the name of the preset, the name that you will see in the assignment drop-down menus in FSUIPC <calculator code> is the calculator code that is sent to MSFS when you trigger the preset. The calculator code to set an lvar is as follows: <value>(>L:<lvarName>, Number) As the value will be coming from an axis, you should use a placeholder - either the @ symbol or the string $Param. You will also need to convert the axis value to the lvar value range. You do this using RPN (Reverse Polish Notation) calculations in the preset. As an example, lets define a preset for the A2A Comanche carb heat switch. The details for this are: 1. Lvar name is Eng1_CarbHeatSwitch 2. My axis range is -16384 to +16384. 3. The lvar range is 0 to 100 A preset for this would be: //A2A SIM/Comanche 250/Engine MY_PA24_250_Carbheat_Axis#$Param 16384 + 327.68 / 0 max 100 min (>L:Eng1_CarbHeatSwitch, Number) Breaking this down: - the first line, starting '//', is not just a comment, but is used to position the preset in the appropriate node in the tree view that you see when you click the Find Preset... button. This preset will be listed under Personal -> A2A SIM -> Comanche 250 -> Engine - the preset name (in the drop-down menus) will be My Pa24 250 Carbheat Axis - the input axis value ($Param) will be calibrated by 1. first adding 16384 to produce a value between 0 and 32768: $Param 16384 + 2. the result will then be divided by 327.68 to give a value between 0 and 100: 327.68 / 3. the result will be constrained to a minimum of 0 (0 max) and a maximum of 100 (100 min) 4. the resulting value will be used to set the lvar Eng1_CarbHeatSwitch Another example is for the ATR condition lever: 1. Lvar name is MSATR_CONDITION1_POS 2. My axis range is -16384 to +16384 3. The lvar range is 0 - 3 (i.e. 4 discrete positions) A preset for this would be: //Microsoft/ATR 42-600, ATR 72-600/Fuel MSATR CONDITION1 LEVER SET#$Param 16384 + 10923 / near 0 max 3 min (>L:MSATR_CONDITION1_POS) Once you have defined your preset, you can assign your axis to use the preset by selecting to assign using Send Preset to FS on the left hand side of the axes assignment panel. Note also that presets are only loaded automatically when FSUIPC7 initializes. If you modify the myevents.txt file while FSUIPC7 is running, you can use the menu option File -> Reload Presets to reload the preset files. For further information on using presets in FSUIPC7, please see the WASM section in the Advanced User guide. For further details on RPN and calculator code, please see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm
-
Note also that your DetectToConnectDelayAuto ini parameter seems to be set far too low: From that log extract, you should be using a value of 262.
-
Please see my previous response: You have LvarScanFrequency set to -2.
-
Nothing will be logged, as there is no specific facility to log lvar changes. You need to list the lvars again when the rudder is at the full deflection (not after) to see the value when fully deflected. Did you do that? Otherwise, you can log an lvar by adding it to an FSUIPC offset and then log the offset changes. This logging was to check that FSUIPC7 was sending the lvar update request when using the Add-ons->WASM->Set Lvar menu option. Did you try that? What was logged? These would be the FS control/event that are logged. You have already tried assigning to the FS controls which doesn't work, so you can forget that. Try the following: 1. Add the following to your FSUIPC7.ini file: [LvarOffsets] 1=L:RudderPos=F0xA000 This will add the lvar RudderPos to offset 0xA000 as a 4-byte/32-bit floating point number. 2. Start MSFS and FSUIPC. Then open FSUIPC, remove all logging options except for Events and Input Events, then go to Log->Offsets, and add logging for offset 0xA000 as FLT32, and make sure to check Normal log file. 3. Load your aircraft, move the rudder through its full range, from neutral to left full, back to neutral then right full and back to neutral, List the lvars (Add-ons->WASM->List Lvars) and then exit FSUIPC7 and show me / attach the FSUIPC7.log file.
-
Also note that the preset assignments shown by AndyCYXU in the image above are assigning to both the press AND the release of a button. This is ok if using a switch or sticky button, but if using a standard momentary button then the press will be followed by the release, and so this may switch the warning off and then back on again, although as I don't have the Fenix I cannot confirm this. If this is the case, you need to either change the presets to toggle the lvar, or use separate buttons/keys for the press and release events/presets.
-
Sorry if you interpreted that way - I am certainly not scolding you, but letting you know that I cannot help you if you don't provide any further information apart from saying 'it doesn't work'. I get a lot of posts saying 'X isn't working, please help'. Just saying 'it isn't working' is just not enough for me to help - I ALWAYS need more information. Please see There are many reasons why something 'doesn't work'. If you want help, you need to provide more information. If you have no idea what the FSUIPC7.ini file is or where that is located, then please at least read the User guide. You should always consult the documentation BEFORE asking for support. And if using presets/lvars/hvars, you should at least read the WASM section in the Advanced User guide, which should tell you everything you need to know about using presets. John
-
WASMINSTRUMENT/POPUP Window and key assignement via FSUIPC?
John Dowson replied to ricky74's topic in FSUIPC7 MSFS
I don't think so but am not sure - I will take a look later. This is standard MSFS functionality and not restricted to the Fenix. There doesn't seem to be a way of doing this via FSUIPC at the moment. However, there is a specific free add-on for managing pop-up panels which also allows keys to be assigned to show/hide such panels: MSFS Pop Out Panel Manager. See https://flightsim.to/file/35759/msfs-pop-out-panel-manager John -
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).
-
(MADDOG X) search offset, indication light.
John Dowson replied to MD80PROJECT's topic in FSUIPC Support Pete Dowson Modules
@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?
-
Issue with Key Assignment and Fenix A320 presets
John Dowson replied to ricky74's topic in FSUIPC7 MSFS
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.
-
Issue with Key Assignment and Fenix A320 presets
John Dowson replied to ricky74's topic in FSUIPC7 MSFS
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.
-
MSFS Garmin GFC 500 AP: Synch the HSI heading bug to current heading
John Dowson replied to Guido's topic in FSUIPC7 MSFS
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
-
ProSim 737 Assignements: Parking brake and cut-off
John Dowson replied to Phil64's topic in FSUIPC7 MSFS
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