John Dowson

I asked for WAPI debug logging (Log -> WAPI -> Debug) mot WASM debug logging, but it doesn't matter. You should rename your script - raas_power_switch contains 17 characters, and there is a limit of 16 chars for lua script names. This can cause issues. But the problem is this: It seems that nil is no longer being returned when the lvar doesn't exist. I have no idea why or when this stopped working - I will investigate this next week, For the time being, change that to: Are you sure that lvar name is correct, and its not FS2CREW_RAASPRO_MASTER_SWITCH? John

What do you mean? What happens when you run the uninstaller, either directly or from the windows app management panel? Why do you think this? FSUIPC should not interfere with any other add-on.

The default hot key to open the FSUIPC7 main window is Alt+F.

Please see the README.txt and the Installation and Registration guide for all registration issues. John

What does this mean? Is the problem fixed, or are you asking/telling me to fix this? I still don't understand your issue - did you ask FSLabs support?

Yes - I left it in the standard units provided. I could convert to m\s or ft\min if thats more useful...but the units shouldn't matter as long as you know what they are/are documented. As I am adding this as a new value, I can add in any units.

Both should work, but if you are adding to an offset as UB (Unsigned Byte), then you should use ipc.writeUB, and not ipc.writeUD. Your lua script doesn;t make much sense. Why are you reding the value of offset A000, when that would be passed into the event function, e.g. function ToggleRAASPower(offset, value) ... end And why are you writing to update the lvar, when that event function is being called on the lvar change? With that script running, the lvar will just always stay at the same value, either 0 or 1. But I think your issue is that the lvar is still not being added to the offset. Are you still seeing a message like this: 5437 **** Lvar 'FS2CEW_RAASPRO_MASTER_SWITCH' not found: cannot add to offset 0xA010 ? Can you please set WAPI Debug level logging, as well as logging for Lua Plugins, and show me your FSUIPC7.log file as well as the lua script again if modified..

I don't know if XPUIPC writes the version number to offset 0x3308 or what that version number is if it does - try logging it. You could also check offset 0x3304 (FSUIPC version number) or 0x3124 (FS version).

You could also try offset 0x3BF8 which holds the FLAPS NUM HANDLE POSITIONS simvar, and maybe 0x0BFC (FLAPS HANDLE INDEX) for the current position, Offsets 0x0BE0 and 0x0BE4 are the trailing edge flaps. There are separate offsets for leading/trailing (see 0x30E0-0x30FE), but you can't really use these values to determine the flaps detent: It doesn’t correspond to the equally spaced notches used for the control lever. You could also try offset 0x0BDC (FLAPS HANDLE PERCENT): Flaps control, 0=up, 16383=full. The “notches” for different aircraft are spaced equally across this range: calculate the increment by 16383/(number of positions-1), ignoring fractions. See also offset 3BFA below.

I have added the PLANE TOUCHDOWN NORMAL VELOCITY simvar to offset 0x0654 (as a 4-byte float, in Ft/s) in the attached version if you would like to try this. John FSUIPC7.exe

Please attach your FSUIPC7.ini file. You may need to calibrate with no reverse zone... If you cannot reverse via calibration, you can use FSUIPCs axis scaling facility - see the section Additional parameters to scale input axis values on page 42 of the Advanced User guide. Basically you need to add a scaling factor of ',*-1' to the axis assignment line in the FSUIPC7.ini file. John

Are you sure that was the script that was running? The line numbers in the log don't match that script... There are errors in the ipc.log statements in that script - you need to provide one string argument and cannot provide separate arguments. Try the attached and show me the log again if any errors. John raas_power_switch.lua

That is an error on line 50 of the lua script - please attach that script. No - the offset will be populated when the lvar becomes available,

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