John Dowson

@chrisingham05 I can't find this software anywhere - do you have a link or can you provide one? Otherwise it looks like you need to purchase this software: https://secure.simmarket.com/fily-it-msfs-bridge-connector-for-foreflight-and-skydemon.phtml John

The value returned by executing that calc code only changes when the value held in the simvar CIRCUIT CONNECTION ON:37 changes, so you need to run that calc code to update the lvar value when that simvar changes value, The easiest way to do this is to add that simvar to an FSUIPC offset, viai the myOffsets.txt file - see the Advanced User guide on how to do this but basically you just create that file and add the following lines (or append the line if the file already exists): // offset, size, simvar, type, units [, w] 0x66C0, 1, CIRCUIT CONNECTION ON:37, I32, Bool, w That will add the simvar CIRCUIT CONNECTION ON:37 to offset 0x66C0 (for read/write) as a 1 byte bool. You can then use a lua script (that must be running, usually via auto-start) to monitor that offset and update the lvar when the value changes, i.e.: function updateMyLvar(offsetm value) ipc.execCalcCode("20 13 (>A: BUS LOOKUP INDEX, Number) (A:CIRCUIT CONNECTION ON:37, BOOL) 100 * - (>L:My_Relay_Result)"); end event.offset(0x66C0, "UB", "updateMyLvar") John

So they don't use the turb engine fuel flow variables then? If the use lvars or b-vars/input events then you can use those. Or if there is any other way to access the values from their custom model, you can try to see if they can be used (and maybe spoof the original offsets with the correct values). John

👍 Thanks for the update - cheers, John

That is from VAMSYS, which I do not support. I only support FSUIPC. If VAMSYS is getting its airport data from FSUIPC, check FSUIPC is running and VAMSYS is connected. Otherwise, try VAMSYS support. If FSUIPC is running, you can show me/attach your FSUIIPC7.log file and I can take a look, but if this is a VAMSYS issue I can't help with that - you need their support.

I see you have posted in the MSFS devsupport forums on this issue. Sorry, but your post there doesn't make much sense... Not sure what you mean by this... FSUIPC makes available what is available in the aircraft, nothing more and nothing less... If it is already in an lvar, then just use that lvar... You cannot convert code to an lvar, you can only set a value to an lvar...i,e, you can store the result of executing the calc. code in an lvar But that doesn't tell you what is happening with the resulting value... if you want to store the resulting value from that code in an lvar, execute the code and save the value to an lvar. e.g. this is the code 20 13 (>A: BUS LOOKUP INDEX, Number) (A:CIRCUIT CONNECTION ON:37, BOOL) 100 * - To execute that and save the result in an lvar, in lua, you would do: ipc.execCalcCode("20 13 (>A: BUS LOOKUP INDEX, Number) (A:CIRCUIT CONNECTION ON:37, BOOL) 100 * - (>L:My_Relay_Result)"); and then the result of executing that code will be available, for whatever you want to do with it, in the new lvar My_Relay_Result. The pull is executing the exact same code - but you see a different value (0 instead of 1) as the value of the simvar A:CIRCUIT CONNECTION ON:37 is different. John P.S. What exactly are you trying to achieve here? Your initial question: is straightforward - you add that simvar to a free/spare FSUIPC offset, and then you can read the value from the offset, and update the simvar by writing to the offset.

Why are you running with admin privileges? It is really not a good idea to do this unless you really have to,,,, Sorry but what does this mean? FSUIPC does NOT launch MSFS, it is MSFS that launches FSUIPC (when using the EXE.xml auto-start component. If you use the MSFS/FSUIPC icon installed by the FSUIPC7 installer with the EXE.xml component. this just displays a splash screen and starts MSFS, which then will start FSUIPC7 (via the EXE.xml). If you use the batch auto-start method, FSUIPC7 will be started by the MSFS.bat script via the desktop icon. And what do you mean by 'but only for a few second then it disappear completely'? What disappears, MSFS or FSUIPC7? If MSFS 'disappears', then it is crashing at start-up. For FSUIPC7, this will show a splash screen and then sit in your system tray. You can access it from there, or use the default hot-key combination of Alt+F to open the main window. And as this article says, if your EXE.xml is correct and all your permissions are set-up correctly and MSFS still does not start FSUIPC7, I cannot help and you should try switching to the batch method of auto-start,

The connection is timing out - this is usually due to a firewall issue. Could it be that you have added an exception to allow communication from P3D (for wideserver) but not for FSUIPC7? Try disabling all firewalls - client, server and router(s) and see if it then connects. If so, then add each firewall back one-by-one until the connection fails, then allow that connection through the firewall. Also maybe try running your P3D installation for WideClient to see if that connects to FSUIPC7 - if that connects, then the issue is with the firewall on the client for the MSFS WideClient installation.. John

Ok, no problem. Looking at those screenshots, those seem to be from the behaviors tab - I don't know how to interpret that (I am not a gauge programmer!). Maybe try looking at the code in the Input Events tab instead, if there is any.... See this article in how to discover input events via the behaviors tools: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/

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