John Dowson

Does your FSUIPC7 key still validate? If so, you are entering it incorrectly or you are using a different name and/or address for your WideFS key. If that is the case, check the appropriate box and enter those details. Otherwise, let me know your WideFS7 order number and I will check your key here.

By the way, where is your TCAS ID coming from (in Options->Miscellaneous)? It should be set to Flight (the default), but you could try Tail to see if that improves things. I am not sure where that example program is getting the callsign information from... Just looking at traffic with TrafficLook and I see no issues with the flight number in the 'To' field: Note for the logging, start with a custom value of x10000 and look for the following strings in the log: This will show you the data that FSUIPC is receiving regarding the identification of the AI aircraft and its to/from fields.

I don't think this can be anything to do with FSUIPC, as this will just be supplying/holding the string "Easy", and it will be up to the software to interpret this. That looks rather strange but I do not know the software you are using - could this be at fault? Could you try the TrafficLook program instead - do you see the same? FSUIPC just stores the information received, so if there i no callsign then none has been provided. I do not know of any issues. You can log AI traffic by using a Log->Custom value of x10000, (Logs AI data), x40000 (Logs additional AI data) or x50000 (logs both). I will take a look here later to check the callsigns and flight number / to field - this does look like data is being misinterpreted but I am not sure if this is in FSUIPC or in the program you are using... John

To freeze altitude and position, you can use the standard FS controls: 66833 FREEZE_ALTITUDE_TOGGLE 66834 FREEZE_ALTITUDE_SET 67216 POSITION_FREEZE_USER You can also use offset 0x3402 to both read the current freeze mode and set it for both freeze position and freeze altitude. Fuel freeze is more complicated - there is no such thing so you would have to implement this yourself. You would need a lua script that monitored the fuel tank level offsets and reset the value each time it decreased. Try and write this yourself, and I can help if you have difficulties. You just need to some offset events (event.offset) that are called each time a fuel tank level offset is changed. On the first call (when script started/initialised) would read the current value of the offset and save this as the current level to be maintained, and then on each subsequent call you would use that value to set the offset. Maybe better to just read the initial values and then have a timer event to set those values every half a second or so while the script is running. You could even have the script automatically running/active when position freeze is active.

WASM stands for Web Assembly Module, and is the architecture used by many MSFS add-ons. The FSUIPC WASM module provides the functionality to access lvars, hvars and presets, which are needed to control many add-on aircraft and even some functions in Asobo aircraft. Please see the Advanced User manual - there is a section on the FSUIPC WASM Module starting on page 47. John

See the above. This keeps getting reported - you should check for similar topics before posting. I do not support vamsys. Check FSUIPC is running and connected and you can check your FSUIPC7.log for errors.

WideFS is WideServer + WideClient. WideServer runs on the FS PC and is built into FSUIPC4 (and later versions - previous to FSUIPC4 it ran as a separate application). WideClient runs on the client PC.

T There are two ways - either via a cable or using WideFS. From the FSUIPC4 User guide (GPSout section): John

The trial license is available from the first post in this topic. It is valid until the 1st October (i.e. it will expire on the 2nd), and I will replace it with a new license, valid until 1st November, on the 3rd or 4th of October. John

Your files show that the GUIDs of your Razer Tartarus V2 and WINWING URSA MINOR CIVIL FLIGHT STICK have changed, causing issues. Can you please do the following: 1. Run Regedit (the Windows Registry Editor application) and take a back-up of your registry (File->Export...) 2. Disconnect/unplug your stick and Tartarus 3. Save the attached regedit script to your computer and run it (i.e. double-click it in Windows Explorer): removeDevices.reg 4. Reboot your PC and re-connect your devices. Once that is done. run FSUIPC7 and then exit (no need to run MSFS), and re-attach those 3 files again and I will check them again and see if your joyletters need updating. John

Please show me/attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files.

No - as far as I am aware (although I have still not looked into this yet) is that this issue is specific to the QW787 with RC4.

Ah yes, I hadn't noticed that.... I don't understand why its 37 when executed: No. I do not use or support MobiFlight. John

When UseAIClient is set to Yes, a separate dedicated simconnect connection is used for all AI traffic management, and when set to No the main simconnect connection will be used. O don't think this will make much difference but no problems trying this. This issue does look to be related to AI traffic in RC4, but may be a good idea to confirm this by running a flew flights without AI traffic to see if you get the crash, and then add AI traffic back yo see if the crash returns. Can you also attach an FSUIPC7.log file from a session when you get a crash, no additional logging required at the moment. Just want to check if there is anything strange reported. I will also take a look at the other posts on this issue on other forums as this is a known problem. John

So the simulator was running and had arrived or passed the main menu state when you closed/exited the simulator? Your log fie shows that FSUIPC could not connect to the sim, so it looks like an issue with the SimConnect interface in MSFS. This is also why other clients cannot connect. Not sure how to fix this - check the Asobo forums but you probably need to re-install MSFS.

Ah! Thought it was October 19th for some reason...

I don't know much about MSFS2024 yet, but I doubt FSUIPC7 will be compatible on day one. I will take a look into updating FSUIPC7 for MSFS2024 after release. Unfortunately I am also away when it is released, so won't be able to purchase MSFS2024 and take a look until the 24th October. I cannot provide any more information on compatibility until after that. John

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