John Dowson

The log file you attached shows that either FSUIPC7 was still running when you attach the file or it had crashed - which was it? Did MSFS start-up and get to the main menu, and if so how long did this take? The log file you attached shows that FSUIPC still didn't connect after over 7 minutes. If your MSFS takes a ling time to start to the main menu, you need to configure/update your DetectToConnectDelayAuto ini parameter - please see the section Auto-tuning of initial start-up ini partameters and the following FAQ entry for details:

SimConnectStallTime is now TrafficStallTime - although SimConnectStallTime should still work (for backwards compatibility) although not documented. UseAIClient is also still valid, but looks to be not documented. This also goes in the [General] section of your ini file. IPC read/write is the logging I would need if I was going to look into this issue, and that does generate a huge log file. But you need to follow that advice in that other post first so you may as well disable logging for the time being. If that doesn't work, I can maybe take a look at a log file, but we can discuss that if/when needed. This should really be fixed in RC4 (it is RC4 that is crashing after all, not FSUIPC), but I know that is no longer possible.

First, you are now using A:CIRCUIT CONNECTION ON:137 now when it should be A:CIRCUIT CONNECTION ON:37 - so try with the correct index number. Yes, that is because nothing is changing the value in offset 0x66C0. You write the value of am lvar to that offset, although the lvar will be undefined at this point, so you will be writing a nil value. The offset is then never updated. That is because A:CIRCUIT CONNECTION ON:137 doesn't exist. You should ALWAYS check your log file for any errors when adding to offsets, and you can also use logging to debug your lua code. Correct that index number in your myOffsets.txt file and then log the offset value (using FSUIPC's offset logging facilities) to verify that it is changing when you change the relay. Once that is done, try the lua I already suggested if you want the value of executing the calc. code to be stored in an lvar. Here is an improved version:: -- Offset event handling function: -- here we execute the calculator code and store the value in our Lvar -- Note the offset should hold the value of the simvar CIRCUIT CONNECTION ON:37 -- which should be added via the myOffsets.txt file 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 -- Lvar event function: -- here we will just log the lvars value when it changes function lvarUpdated(varname, value, userParameter) ipc.log("Lvar updated: L:My_Relay_Result=" .. value) end -- First, lets create our lvar with an initial value of 0 ipc.createLvar("L:My_Relay_Result", 0) -- Now wait until FSUIPC has received this lvar so it can be used for an event -- ipc.reloadWASM() -- this shouldn't be needed while ipc.getLvarId("L:My_Relay_Result") == nil do ipc.sleep(20) -- wait for 20ms end -- wait for an event in the offset holding the simvar, which will get triggered when the simvar/offset changes value event.offset(0x66C0, "UB", "updateMyLvar") -- Monitor the lvar value to log any changes event.Lvar("L:My_Relay_Result", 100, "lvarUpdated") ipc.log("Lua script to update Relay lvar My_Relay_Result is now running") Also, it would be easier for me if you could just attach lua/log files or paste code (as I do) rather than use images.

No - that is just used for additional/extra logging and should only be added when instructed for investigation of support issues. If that is in the ini file, it can/should be removed, but otherwise just to go to FSUIPC's logging tab and make sure everything is unchecked, and that the Debugging Data field is empty (i.e. is 0 or x0). Further logging can also be performed when the TestOptions ini parameter is used, so if that has been added, that should also be removed.

You can do this with a lua script - you will need a registered / licensed copy of FSUIPC to do this. There is also an example lua script that does this, called record to csv.lua. This can be found in the Example LUA plugins.zip file, which is located in your FSUIPC documents folder. John

Then why not just follow the advice in that post? But they do - all the settings mentioned in that post are available in FSUIPC6. Why do you think otherwise? Check the documentation. If the log file is that big, then you must have some logging settings activated. Turn them off to reduce the log file size. There is no point in me looking at such a large log file, especially as the OP has no idea where the RC4 crash occurred in this file. Logging should not cause any major issues, except if the disk/add you are logging to runs out of space. Excessive logging may cause some performance issues, but this depends. But if there are issues, I would usually first like to see a vanilla log file, i.e. with no additional logging activated, and I would advise if I needed any additional logging activated for the issue in question. If a log file is too large to be attached, it should be compressed. If its still too large after compression, then you need to use one of the free file transfer services. But this seems to be a known issue, and I cannot add any more to what Pete has already said in this post - just follow the advice there, it applies to FSUIPC6 as well as FSUIPC4:

If this is a crash in RC4, I cannot help - you need support from RC4. What advice? What settings? Do you have a reference/link for this? Why is this specific to the QW787? If it is specific to this aircraft, shouldn't this issue be fixed in that aircraft?

That is never going to work - ipc.execCalcCode does NOT return any value (it cannit as its asyncronous). As I have said, to get the value returned by executing calculator code, you have to write the value to an lvar and read the value from the lvar. But that calc code string returns one of two values, -80 and 20, depending on the value held by A:CIRCUIT CONNECTION ON:37 (which is always 0 or 1). so if you know the value of that variable, you know the value that executing that calc code string will return. So why don't you just add that simvar to an fsuipc offset, as I showed in my previous comment? If you really want the value of that calc code string in an offset, then change the calc code string to send the value to an lvar, then either have an event.lvar function that picks-up any change to the lvar value and write it to an offset, or add the lvar to an offset via the [LvarOffsets] ini file section. That will work as ipc.readLvar will return a value - lvar values are held in FSUIPC and so this is a synchronous call. Please use the lua library documentation - you will see that there is no return code/parameter/value from ipc.execCalcCode. John

You posted this in the FAQ sub-forum, where it explicitly states NOT for support requests. I have moved your post. You cannot set it to OFF. It is an Add-on - you can disable it from the Options->Add-ons menu. This will then take effect when you restart P3D. You cannot. It is a sub-window of P3D, accessible from the Add-ons menu (or hot-key). When open, it also blocks P3D. Why would you want to put it in a notifications bar? FSUIPC just runs in threads under and managed by P3D, as it is an add-on, and not a separate executable/application. You won't see it in the task manager (unless maybe you can also see thread information).

@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.