John Dowson

Ok, thats good to know. It was the altitude issue you had that I was thinking about: How did you get around this? Maybe you would consider adding a topic to the User Contributions section on how to set-up/configure RC4 and FSUIPC7 for use with MSFS, I am sure others would find this helpful. John

The TRANSFER IDENT simvar is not held in any offset. You can add it to an offset if you like, but you would normally trigger it using one of the provided events - from the MSFS documentation: If you want to use an offset, you can trigger any control using offset 0x3110, e.g. write 67314 to trigger XPNDR_IDENT_ON

Could you try spoofing from 0x0570 instead of just 0x0574, i.e. -- Loop till flag 0 is set while ipc.testflag(0) == false do gpsAlt = ipc.readDBL(0x6020) ipc.writeStruct(0x0024, "1UW", 0x0570, "1UW", 8, "1UD", math.floor((gpsAlt - math.floor(gpsAlt))*65636*65636), "1SD", math.floor(gpsAlt)) -- Sleep for 50 mSecs so the update gets done roughly 20 times per second ipc.sleep(50) end -- Now undo the overrides (otherwise they'll take about 12 seconds to die, with frozen values provided!) ipc.writeStruct(0x0024, "1UW", 0x0570, "1UW", 0)

Please see offset 0x0354:

Ok, but probably better to add the simvar to an offset and use that. It seems a bit convoluted to write the simvar to an lvar and then add the lvar to an offset, and you need to keep (manually) updating the lvar to keep in sync with the simvar. Sorry but I can't really help with this - I am no expert in complex calculator code, and looking at the existing presets for the King Air, this seems like quite a complex aircraft to control in this way. For assistance with calculator code (and with help defining presets), you should ask on the MFSF2020 channel on the MobiFlight Discord server. Maybe a good idea to tag the author of the existing presets for the King Air (Stefan Kelley).

I can also allow for: PlaneAltitudeSwitch=GPS to switch 0x0570/0x0574 with the GPS altitude in offset 0x6020. In fact, this is probably the only sensible option. And rather than switching the offsets, i think I will just change the simvar used for offset 0x0570/0x0574 and leave the other offset as-is.

Can you also please show me / attach your FSUIPC7.log and WideServer.log files from your FSUIPC7 installation folder, Better to attach files rather than paste contents. I need to see the 4 files (WideClient.log, WideClient.ini, WideServer,log, FSUIPC7.log) from the same session. Please also be aware that the WideServer component in FSUIPC7 is only started once you have an aircraft loaded and are ready-to-fly. WideClient won't connect when MSFS is in the main menu.

There is no such function as ipc.readAvar - and such a function is nit possuble. To read an a-type variable, also known as a simvar, there are two ways to do this: 1. Add the simvar to a free/spare FSYUPC offset and use the read/write offset lua functions in the ipc library. See the Advanced User guide on how to add sumvars to offsets. 2. Write the simvar value to an lvar and read the value from the lvar, e.g. ipc.execCalcCode("A:CIRCUIT CONNECTION ON:37 (>L:CIRCUIT_CONNECTION_ON_37)") -- write the simvar value to an lvar ipc.reloadWASM(); -- reload the WASM to receive the new lvar ipc.sleep(50); -- wait for the lvar to be received circuitState = ipc.readLvar("L:CIRCUIT_CONNECTION_ON_37") To write to a simvar, there are also two ways: 1, Add to an offset and write the value to the offset 2. Use calculator code, e.g. ipc.execCalcCode("5 (>A:CIRCUIT CONNECTION ON:37)") would set the simvar value to 5.

Maybe also check-out/log the value of offset 0x0590 (INDICATED ALTITUDE CALIBRATED), but note that this is in feet and not metres. Is that correct, both below and above transition level? I am thinking I could maybe add a new ini parameter than when set would switch the value held in 0x0570/0x0574 to use either INDICATED ALTITUDE CALIBRATED (currently held in 0x0590 in feet) or INDICATED ALTITUDE (held in 0x3324 in either feet or metres, depending in the value held in offset 0x0C18) instead (in same units and format) of the current PLANE ALTITUDE. I don't think I should be using an AP/GPS altitude for this though...what are your thoughts on this? e,g, either PlaneAltitudeSwitch=Indicated -- this would switch the simvars held in offsets 0x0570 and 0x3324, preserving the current format of both offsets or PlaneAltirudeSwitch=Calibrated -- this would switch the simvars held in offsets 0x0570 and 0x0590, preserving the current format of both offsets (maybe also PlaneAltirudeSwitch=GPS to use - but maybe not switch with - GPS POSITION ALT currently held in offset 0x6020) I can look into adding this parameter for you to try over the weekend, if you think that would help - check those offsets and let me know. John

Please also see this (long) thread on this issue: https://forums.flightsimulator.com/t/vatsim-ivao-pilotedge-users-be-aware-of-an-important-bug/426142/398 An important comment is this one (quite old now): and also one of the last comments on that thread: So this looks more to be an issue with the clients that use this data, and I am not sure a fix for this in FSUIPC is appropriate as it may break other things/clients- should probably be fixed in the clients themselves, e,g. VATSIM. I will talk to Pete as he may have some ideas as to anything that can be done in FSUIPC. John

I think this this altitude problem could be a general issue and not related to the METAR data. See this long discussion on altitude issues in MSFS: https://forums.flightsimulator.com/t/vatsim-ivao-pilotedge-users-be-aware-of-an-important-bug/426142/461 and this topic in FSUIPC: Not sure what I can or should do about this at the moment - I am going to investigate further and see if I can come up with anything... John

Maybe try converting the double from offset 0x6020 to an int before writing it to 0x0574: -- Loop till flag 0 is set while ipc.testflag(0) == false do ipc.writeStruct(0x0024, "1UW", 0x0574, "1UW", 4, "1SD", math.floor(ipc.readDBL("6020"))) -- Sleep for 50 mSecs so the update gets done roughly 20 times per second ipc.sleep(50) end -- Now undo the overrides (otherwise they'll take about 12 seconds to die, with frozen values provided!) ipc.writeStruct(0x0024, "1UW", 0x0574, "1UW", 0) Also try logging offset 0x0570 as an SIF64, and also 6020 as a FLT64 in FSUIPC. Aren't these values more or less the same anyway (especially the integer component? Note the original value will be logged, not the spoofed value. Are you sure VATSIM is reading the altitude from 0x0570/0x0574 (i,e, does that match what VATSIM shows)?

Read that link on RPN! $Param 16384 + : adds 16384 to the axis input value ($Param) to give a value between 0 and 32768 327.68 / : divides the result by 327.68 to give a value between 0 and 100 near 0 max 100 min: I think near just converrs the result to an integer, and the rest ensures the value is between 0 and 100 (>L:BKSQ_MixtureLeverPosition_1) : sends the result to set the name lvar' value So up is one button, (as seen by FSUIPC), and down another? You can do this in 2 ways: 1. Create one preset: BKSQ_Duke_CowlFlapSwitch_L#$Param (>L:var_cowlFlapSwitch_L) Then assign the press on your up button to that preset with a parameter of 1 and also assign to it with a parameter of 0 for the release, and your down button with a parameter of 2 on press and also a parameter of 0 for release. This is what I mean by 'you give the parameter value in the assignment' 2. Create 3 distinct presets: BKSQ_Duke_CowlFlapSwitch_Up_L#1 (>L:var_cowlFlapSwitch_L) BKSQ_Duke_CowlFlapSwitch_Down_L#2 (>L:var_cowlFlapSwitch_L) BKSQ_Duke_CowlFlapSwitch_Off_L#0 (>L:var_cowlFlapSwitch_L) and assign to those in a similar manner. This is what I mean when I say 'Alternatively, you can hard-code the value into the preset and just use that'.

First, try to use logging to determine what the condition lever is using. If standard controls are not being used, then it is most likely an input event or an lvar. You said you have tries input events, but what exactly have you tried? Is there an input event available for the condition lever position, does it change value when you move the condition lever (use logging!)l and if so if you set the value of the input event does the condition lever move? If there are no input events, then there is probably an lvar. Try listing the available lvars and values (using Add-ons->WASM->List Lvars) to see if any look applicable. If so, determine the maximum/minimum values for the lvar and define your own preset. I have just explained how to do this (in another aircraft) in this post: I don't have the PC-12, so cannot look into this in any detail, But the procedure to determine how to assign to control something is the same in all aircraft - logging and trial and error... John

First, check for existing presets. There are currently 38 presets available for the BS Duke - they are under MobiFlight->Black Square->Duke (in the Find Presets panel). If the presets toy are looking for don't exist, then look into adding them. What is the range of the lvar? You need to know this to calibrate the axis value to the lvar range, If the range is 0-100, the preset would be: //Black Square//Duke BKSQ_Duke_Muxture1#$Param 16384 + 327.68 / near 0 max 100 min (>L:BKSQ_MixtureLeverPosition_1) The would convert your axis range (-16384 to +16384) to the lvar range (0-100) and set the value to the lvar. To use RPN (reverse polish notation) in calculator code, see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm. The preset calculator code to set an lvar value (without any calibration) is just "$Param (>L:lvarname)", and you give the parameter value in the assignment. Alternatively, you can hard-code the value into the preset and just use that.

But what exactly is your problem? Your files show that all 4 of your devices were detected and acquired for use: Can you not assign to them? What have you tried? Your ini file shows no assignments and is basically empty. Why did you not install the FSUIPC WASM module? You will have no access to lvars, hvars or presets without this installed. Also better to have FSUIPC7 auto-started with MSFS. If manually starting. best to do this when MSFS is up and running and at the main menu, to prevent issues that can arise from too many reconnection attempts. John

There may be an old version of FSUIPC3 around somewhere that works with FS2002, but I am afraid that I cannot provide this. Your question has also been asked before - see Later: Maybe one of these versions will work (found by google): 3.75: https://www.flightsim.com/files/file/65823-fsuipc-375/ 2.92: https://www.fs2000.org/2002/10/16/fs2000fs2002-fsuipc-dll-v-2-92/ Note that there is also a free license available for FSUIPC3 (presuming it works with these older versions) on FSUIPC.com. John

Ok, then you will have lost any presets that you added to the events.txt file. You should only add events to the myevents.txt file - that is why this is provided, and leave the events.txt dile for the MF presets, which is updated on each release. You could check your recycle bin to see if your old events.txt file is there. If so, restore that but then move the presets you added to that to the myevent.txt file instead, Thanks! John

Yes - the events.txt file is ALWAYS deleted when you uninstall, and re-installed when you install (provided you have not de-selected the install component for this). The myevents.txt file is never touched - this file is not known to the installer or uninstaller. This is why you add your own presets to the myevents.txt file and not the events.txt file. The latter is managed by the installer/uninstaller, whereas the former is managed by you. No, as I have no idea what you added to your myevents.txt file. I have my own, of course, but it will be completely different to the one you were using. As I said, you have to try and find it on your system - you are the only one with that file, and it is created and managed by you. If it has gone, then you must have deleted it. Please don't attach images - far better to attach files, i.e. it is your InstallFSUIPC7.log file that would tell me what was installed, not a screenshot. Your screenshots do show that you have Explorer set to hide the extensions of known file-types - best to change this. Also looks like you deselected the option to install the MF events.txt file for some reason. If you didn't do this, there may be an error in your installation log but I doubt this very much as there has never been an issue installing this file.

Or find out which offset it is using, if it is getting this value from an FSUIPC offset. You can then spoof the value of the offset it is reading to read the correct value from a different offset, using the facilities provided at offset 0x0024. There is a lua example plugin provided that shows you how to do this, called liar.lua. John

Installing/re-installing does not touch the myevents.txt file - if it is gone you have either manually removed it, or possibly you have re-installed into a different folder. Did you change the installation location? If so, the file will be in your old installation folder. You can also check the UninstallFSUIPC7.log file which will list the files it has removed. It should be in your installation folder, but if its not there then, as I said, you have either manually removed it or possibly installed into a different folder. Try searching your system for this file - you can use Everything or something similar. If the file is not on your system, there will be no way to recover it. John

Sorry, but I don't see how this can be due to the latest update - or in any update. If your axis is inverted, then this is due to the device driver, and not FSUIPC. There are two ways to handle an inverted axis: 1. via calibration, if calibration of the axis is allow via FSUIPC's calibration pages 2. via axis scaling, using a parameter of *-1 appended to the end of your axis assignment entry - see the section Additional parameters to scale input axis values in the Advanced User guide on page 42. If you need further assistance, please show me / attach your FSUIPC7.ini file so that I can see your assignments. John

This is usually due to using an aircraft with a different livery and not using substrings for your aircraft names in the profile section (i.e. you must manually edit the name of the aircraft in the profile section of your FSUIPC6.ini file)... If everything is shaded/inactive, then this implies that there are either compound or offset conditions have been added to the assignment, or that the button/switch is overloaded (i.e. has more than one control assigned to it). To diagnose assignment issues, please activate logging for Buttons & Switches as well as Events/controls (non-axis) and reproduce your issue, and show me/attach your FSUIPC6.ini and FSUIPC6.log files, after exiting P3D. John

If you are using a steam installation, check to see if a phantom xbox controller is being detected - this is a known issue, and can be fixed by adding IgnoreDevice=0x28DE,0x11FF to your [JoyNames] section of your FSUIPC7.in file. Otherwise, f your devices are not being recognised, please show me/attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files. As a new forum user, your upload limit will be very low and the files may need compressing/zipping. Note I have deleted your first post on this issue, posted in an unrelated topic. John

Looks like something is continually trying to set two lvars (with ids 2109 and 2110. Try listing the lvars (via Add-ons->WASM->List Lvars - the lvars will be listed with ids and in id order in your log file) to see what those lvars are, which should give you a clue as to what is updating them (probably either a lua script or maybe GSX). Try and see if these are necessary and if they can be stopped. But 4 lvar updates a second shouldn't cause any issues, but excessive logging can cause stuttering issues. Why are you logging the FSUIPC WASM to the MSFS console, instead of the WASM log file? You must have set this in one of your FSUIPC_WASM.ini files - stop this by setting/changing the ini parameter LogType back to File: ; LogType: File, Console, Both LogType=File You can also switch off such logging by setting the LogLevel back to Info. You only need Debug level logging set when needed for support issues.