John Dowson

Isn't it obvious what that error is? The lvar is not available. This is probably because since version 7.5.0, only an initial scan for lvars is performed, as continual scanning for lvars can cause the WASM to crash. If an lvar that you want to use is not picked-up in the first scan, there are a few things you can do: 1. Increase the WASM ini parameter LvarScanDelay. This ini parameter determines the delay from aircraft load to the first lvar scan, and the longer the delay, the more lvars will be detected. Try increasing this value. See the WASM section in the Advanced User guide for further details. 2. You can have a lua script to test for the existence of an lvar and if not available, then you can request an WASM reload, e.g. As for this error: That looks to be due to an offset request at 0x0284 to update the ADF1 Standby frequency, and FSUIPC was using the wrong control number, using 68038 which doesn't exist. I have corrected this in the attached version if you could try it. John FSUIPC7.exe

By the way, you should also set the simConnection for the WAPI, i.e. add the following to your ini: [WAPI] UseSimConnection=0 John

Yes, I was going to ask you to check the extension of that file...! Glad you spotted it. John

Maybe @Paul Henty could advise on this - does the WebSocketServer need to be updated for MSFS2024? I presume the websocketserver is checking the FS version at offset 0x3308. This holds 13 for MSFS2020 and 14 for MSFS2024, and is set when FSUIPC establishes a simconnect connection to the FS (and so knows what version it is connected to). You could try manually setting the value in this offset to 13 once it has been set to 14. You could do this in an ipcReady.lua script (if you have a license for FSUIPC7).

This error usually indicates an issue with simconnect and is temporary, but in this case I am not sure as I would expect to see more than just one error. Do you see this all the time or occasionally? is this causing any issues? Your log file does show some issues and is rather strange...could you please download 7.5.1 again and re-install to be sure that you are using the latest official 7.5.1 version please. Also, there are some re-connection attempts so you should tune the startup parameters - set the following in your FSUIPC7.ini file: DetectToConnectDelayAuto=100 InitialStallTime=0 Then can you switch off all logging (including lua plugin logging) and activate logging for Buttons & Keys and Events only, and show me / attach your FSUIPC7.log and FSUIPC7.ini files when you get the error.

That would be good, thanks.

Yes, should be the same as for MSFS2020, although I have not tried it. The simconnect API is the same, so shouldn't be an issue.

Born in England, although I consider myself European.

Yes I could add that, and maybe better than using VERTICAL SPEED while on ground. I can switch to using the simvar PLANE TOUCHDOWN NORMAL VELOCITY for offset 0x030C, but if you want to use this now you can add this to a spare/free FSUIPC offset using the facilities provided (i.e. via the myOffsets.txt file). It may be better to add this to a new distinct offset. If you could add that to an offset and compare the values and let me know if you think offset 0x030C should be replaced or add this to a new offset, that would be great, Cheers, John

Unfortunately my language skills are no match for my programing ability, and as I now live in Spain it is my spanish that needs improving, and I am also trying to learn galician/portugese as I live on the border. English is and always will be the preferred language of support, but I do my best with any language that is posted, although I will usually respond in english unless familiar with the language!

Then you need to look into the SDK to see if this information is available anywhere. The aircraft type, as known by applications via the simconnect interface/API, is determined by the SIMCONNECT_SIMOBJECT_TYPE stricture when received, which has the following values: So for all other aircraft/objects (e.g. AI traffic) the type is known, but for the aircraft/object you are flying/controlling it is always SIMCONNECT_SIMOBJECT_TYPE_USER, and it is expected that the the user knows its type. This is obviously not optimal for third party software that need to determine the type, but I do not know how to determine the type by other means. I will take a look at the SDK in the next few days to see if this information is available via other means and let you know, otherwise I can raise a bug/request to see if this can be added. John

@simnutzer1962 If you appreciate my support and product, could you please post a review of this on the SimMarket forums. I would only expect an honest review, and auf Deutsch ist gut / besser. In meinem kostbaren Leben habe ich in Darmstadt gelebt, als ich für die "European Space Agency" (ESA) im ESOC gearbeitet habe. Aber leider habe ich im Laufe der Jahre den größten teil meines deutsche verloren!! 😉 Mit freundlichen Grüßen, John

Please try the attached (with Extras logging): FSUIPC7.exe Not had time to test but should be ok...will review tomorrow, Please attach log or confirm ok if you can test, Regards, John

Yes - this is the exact issue in that bug report I have referenced several times - here are the first few lines: As FSUIPC can be started when the AircraftLoaded system event has already past, it also uses the RequestSystemState call. However, you log does show an issue: The request done at 2nd bold timestamp 87578 should not really occur, but is happening as a flag is being set at timestamp 58110, but not being cleared at 1st bold timestamp 87578, so that request is unnecessary. I will correct this. That is because it cannot open the aircraft.cfg file as the path is relative, so it resets the offsets read from this file. Relative paths may be useful (and these may also get corrected at some point) so I will still add them if that is all that is available, but what I can do is add a check so that when a relative path is received, I can compare it (case-independent) to the end characters held in offset 0x3C00 and only update if they differ. This should preserve the full path when available, and only update to a partial path if that is all that is available. I have to take the dogs out now - will make these changes either later this evening or tomorrow and provide you with an updated version to test.

You could try the ATC TYPE offset 0x3160,

But there is no functional difference in that build - the only difference is that the AircraftLoaded events (both on specific request and via a sim state change) will be logged with the parameter received. There should be no difference in the values received and/or held in offsets. Note, as documented in that link, there is a difference in the value when specifically requested and when received from a sim state update. So I am confused now. Compare both versions with the exact same test (i.e. don't just exit one version of FSUIPC and start the other - exit MSFS and repeat the test). Then compare the values in the offsets - they should be exactly the same if the test was the same. The only difference should be in the log, where the log for the patched version will show the full values received from the AitcradtLoaded events, You can also attach both log files here.

I already did...complete description: C - indicates a compound condition R - indicates repeat while button pressed (+1,11) - this is the compound condition, and indicates that button 11 on device 1 must be pressed (+). This is true when the selection rotary is in the IAS/MACH position C66587 - is the standard ROTOR_BRAKE control 38408 - is the control parameter, where 384 is this custom control: #define EVT_MCP_SPEED_SELECTOR (THIRD_PARTY_EVENT_ID_MIN + 384) and 08 indicates a 'mouse wheel down' operation on the control, which is the speed selector and so will decrement the speed No problem. If you understand those assignments, it should make it easier for you to add your own when you need to... Regards, John

@kingm56 I have looked into this further, and there is an issue with offset 0x0640. That holds 6 *6 character idents, i.e. needs 36 bytes. However, offset 0x0658 is only 24 bytes away, so the full idents for airports 5 & 6 are overwriting 0x0658. The offset are for the full 6 character idents should start at 0x0630, not 0x0640, to prevent this. I have corrected this in the attached version. John FSUIPC7.exe

Delete those settings in bold and try these: Those use the rotor brake custom controls to control the IAS/HDG/ALT using the mouse-wheel down/up codes (on repeat) for inc/dec, (on buttons 15 & 14) with a compound conditional on the position of the selector switch (buttons 11, 12 & 13) Not sure why the previous assignments were for the Microsoft SideWinder Precision Pro....

Did you remove the custom controls being sent in ranges then? Ok, glad its working. Could you attach your working ini file here please.

In the ini you just posted in the other open topic you have, you have the flaps lever axis assigned to Flaps Set, AND are assigning to the custom controls in ranges - that will always be problematic. For now, please assign the axis to Unused, and just use the custom controls. Do you get the same issue? If so, try what I said above, i.e. assign to Flaps (direct) and calibrate with detents.

Ok, although that is strange - I would expect the EVT_CONTROL_STAND_FLAPS_LEVER and Axis Flaps Set controls to do something... You can also try assigning to Flaps Decr when entering the lower range, and Flaps Incr when entering the upper range (may be vica-versa). Does assigning the flaps lever directly to the Flaps control (Send direct to FSUIPC calibration), Flaps Set or Axis Flaps Set controls (both 'Send to FS as normal axis) work? If so, and your flaps lever has detents, then toy can use one of those and then set the detents as shown in the user guide (section CALIBRATING FLAPS WITH SPECIFIC DÉTENTES). It was reported that assigning to Flaps (direct) and calibrating with detents works fine for the PMDG737 in this post (although this is with FSUIPC6 and the Bravi, that should make no difference): It is certainly an issue with the controls, and not the thrustmaster, but this should certainly be possible... Seems like you had this issue before and got it working in September 2023: ? Why did you not report this in the same topic? Is this a new throttle quadrant - were the flaps previously working correctly (as it says in that post), and if so, how did you assign then?

@simnutzer1962 Did you manage to get the selection knob working yet in the PMDG 737? If not, if you attach your latest FSUIPC5.ini I can take a look. I don't have this aircraft for P3D, but I can look into setting this up in MSFS (on a different controller) then it should be possible to map this to P3D and your thrustmaster throttle quadrant.

The latest trial license, valid until 01/02/2025, is now available from the first post in this topic.

I did look at it. I didn't know "Path of Flight Simulator installation" == "InstalledPackegesPath". I meant look at the value in the offset, i.e. log its value. I will update the offset status document to make this clear. Cheers, John