John Dowson

First, offset 0x0352 is for Nav2 active frequency - Nav1 active is at 0x0350 and Nav1 standby is at 0x311E.. To debug the script, you can use FSUIPCs lua plugin debug logging facilities, and also log offsets 0x0350/0x0352 as hex values

Yes

Why do you keep mentioning WideFS in this topic? Did you not read my previous post? Or my post before that? Please re-read my previous posts...and to be very clear: IF YOU WANT HELP WITH THIS, USE THIS THREAD If you actually looked at those logs, why did you bother posting/attaching them? They are both the same file, and show that FSUIPC7 was stopped after 45 seconds and never even connected to MSFS. How are they supposed to help?

I can see why you have multiple WASM menu entries - I will correct this for the next release, but it shouldn't cause any issues, Multiple menu items are being added as there are multiple simconnection attempts being made. Your log shows that you manually started FSUIPC7, but didn't start MSFS until over 14 hours later, and it then took another 3 minutes or so to obtain a stable connection, with many failed attempts before this was done. If you are going to manually start FSUIPC7 before the simulator, you should disable auto-connect and connect manually once MSFS has started and arrived to the main menu. Alternatively, start FSUIPC7 after MSFS has started (and arrived to the main menu), or use the auto-start facility. John

The license has been updated, now valid until 1st March 2025. John

That is very strange...please show me / attach your FSUIPC7.log file.

As I said, you raised another support topic for this and I responded there - why don't you try what I suggested, and use that topic for that issue, not this one. What changed? If FSUIPC was updated, you can try adding the following to the [General] section of your FSUIPC7.ini file: Init3308=13 Also try setting logging for IPC Reads and attach another log file showing your issue. First, run just FSUIPC7, set that logging, then exit, Then run MSFS and FSUIPC and reproduce your issue, then exit FSUIPC7 before attaching your FSUIPC7.log file.

You can send separate key down and key up events via offset 0x3200, Are you using @Paul Henty's .Net client dll? If so, better to post in the .Net client dll sub-forum - I can move this post... John

Then the WASM is installed. You will not see the WASM entry under the Add-ons menu until FSUIPC7 has connected to MSFS, as the WASM facilities are not available until MSFS is running.

If the WASM didn't install, check the InstallFSUIPC7.log for errors - you can also attach that file here. It is better to correct any errors and re-install than install manually, but to install manually you just need to extract the file fsuipc-lvar-module.zip from the FSUIPC-WASM.zip (under the SDK folder of your FSUIPC installation), extract the fsuipc-lvar-module folder from that zip and copy/move it to your Community folder. John

Yes - you raised that issue here: I provided assistance but you never responded. Is that now working? What was the issue? If that is now working, can you please respond to that post to explain what the issue was and what fixed it. This will help others who have the same issue and find that post. It is very frustrating for me when I provide support and the OP goes silent... What issue? Your log file shows that FSUIPC connected to MSFS ok. However, the log file stops after 49 seconds, and seems to have been attached while FSUIPC7 was still running (ALWAYS exit FSUIPC before attaching files!). Can you explain what happened please, and what your actual issue is. Saying 'not working' is pretty meaningless. If your issue is that the ACARS won't connect, why don't you just use that as a title, and maybe check one of the other several hundred topics where this has previously been reported... Are there any error messages from your ACARS program? The usual issue for FSUIPC client programs not being able to connect is that they are being ran at a different privilege level. FSUIPC and all clients must be ran at the same level. John

Sorry, but this doesn't make much sense... Offsets are for holding data, such as the value of a simvar or an lvar, or any data that you would like to store there. So how can you assign encoder buttons to an offset? That just doesn't make any sense. You assign encoder buttons to actions, such as to send and event/control or preset. If you want to assign one of the rotary buttons to write/update an offset, then you can do this by assigning to one if the offset controls (e.g. Offset Byte Set) - see page 34 of the Advanced User guide You can read/write to all offsets in an external program using the FSUIPC SDK or one of its wrappers, I have no idea what that function is, but if it is from one of the FSUIPC wrapper libraries then I don't see why not (although that looks to be a callback function that is called when an offset value changes). John

It is expected (if the lua thread does not exit of its own accord in the required time limit) and it is forced / unclean shutdown, but nothing to worry about. You can try increasing the TimeForLuaClosing ini parameter, but this may not help either. But it really is nothing to worry about. A lua termination handler should only be used to free any windows resources acquired.

An ipc.exit() call will not do anything when called in a shutdown handler as the thread is already exiting. A shutdown handler is only needed to close any opened resources really - files, ports (com), pipes, etc. No need to cancel events. John

But as the standard controls are not used, they will be empty. Have you tried logging those? Great!

No. If you want to calibrate, you would have to do this yourself before sending the value to the sim. You can do this in the RPN/preset code if you know advanced RPN, Otherwise, you would need to write the axis value to an FSUIPC offset and have a lua script that monitored the offset, calibrates the value to the lvar range (plus any further calibration you want to apply) and then send the new lvar value to the sim. Calibration for null zones is straightforward, but adding a slope more complicated (you need to determine the function to use). John

I am not familiar with the SDK you are using, but this: Offset 0x0D70 is only 128 bytes, not 256. This also doesn't seem correct: To update an lvar, the value must first be written to offset 0x0D6C. But I am not familiar with the SDK you are using, or which FS you are using (there is probably an easier API to access lvars if using MSFS). Maybe @Paul Henty could comment as I presume this is using his dll.

Well, you have configured it to log events, and if you don't want to see them you can always turn off Event logging. With Event logging, FSUIPC logs all (non-axes) events seen by FSUIPC (which should be all events applied in the FS). Many aircraft in MSFS continually emit certain events, and these events differ with each aircraft. If you want to ignore such events when Event logging is set, you can use the DontLogThese ini parameter. This can go in the [General] section, which will then apply to all aircraft, but it is better to add this to the profile section (i.e. under [Profile.xxx]) as the events to ignore are always aircraft specific, e.g. DontLogThese=65957,66519 ,66068 Such logging really shouldn't give performance issues though on most modern systems... Excessive logging in MSFS can cause performance issues, so also check the MSFS logging console.

Which SDK are you using? If using Paul Henty's client dll then you should post in that forum (I can move this post id you like). Other than that, the error should be obvious (as indicated by the message), but as your process calls are in the loop and process one read/write at a time, I don't know why the data limit is exceeded. But I am not familiar with the SDK you are using. Pete retired more than 5 years ago now. There are various wrappers around the basic FSUIPC SDK, some of which provide an event-driven interface. with Pai; Henty's dll being the most advanced.

No, axes assigned to presets are not calibrated - only the standard FS controls go through calibration. You can also reset any calibration entries to stop calibration by FSUIPC if required..

Why is it not compatible? As I said, for PMDG panels you need to look at the provided custom controls and use them. Isn't that possible via the CDU/FMC software? If that can write to FSUIPC offsets, you should be able to configure to do that if you cannot assign to custom controls or presets directly. Do you mean the 787- Dreamliner? There is no Asobo 737... If so, logging reveals this: So you can try assigning to FUELSYSTEM_VALVE_TOGGLE with a param of 1 or 2 (for engines 1 & 2 respectively) to toggle, or assign to the Input Events FUEL_Valve_L and FUEL_Valve_R with parameters 0 and 1 for assignments to fixed positions. Is that from Bredok3d or Asobo? As I did with the 787-10 dreamliner, try using the logging facilities to see what is being used. John

Here's the DA42 bindings file: DA42 LVAR bindings.txt

Are any other controls/events logged for this, or just the Aileron Set? That is very strange...assigning in FSUIPC should not affect assignments any where else, although calibration can affect controls assigned outside of FSUIPC. Ate you sure that this was not for other reasons, such as the window focus not being with MSFS (with the xbox controller being an XINPUT device, MSFS needs the focus to receive the xbox controls)? Also strange. Take a look at the COWS discord server - there are reports there of similar issues. For aileron, rudder and elevator, you need to assign to use the following lvars: L:INPUT_AILERON, percent; -100 - +100 L:INPUT_RUDDER, percent; -100 - +100 L:INPUT_ELEVATOR, percent; -100 - +100 You can assign an axis to control an lvar by defining your own preset and assigning to that. Take a look at the following FAQ entry on how to do this: John Later: found this: DA40 LVAR bindings.txt Thats for the DA40, but the COWS DA40 will share the same LVARs as the COWS DA42, so also applies.

Please also check/confirm that all your computers are in the same windows Workgroup. As your issues started after a windows update, it must be due to config of that machine, which would either be the workgroup or the firewall. Did you also download and install the latest windows VC++ redistributables after the update? This may also be needed and does no harm, so if not done already please also try that. John

Better to stop/disable the firewalls, and also check the firewall in your router. You should also add "Protocol=TCP" to your WideClient.ini. Why did you not include your WideServer.log file? As I said to the previous poster, I need to see all 5 files from the same session. Remove those and stick to TCP defined by the client(s). No idea what could cause that...Do you see the FSUIPC icon in the system tray when it is closed?