John Dowson

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?

But you said: ! There is no Asobo 737 as far as I am aware, so which aircraft are you using? Id the standard controls/offsets don't work, you will have to look into each aircraft to see what works for that aircraft. For the PMDG 737, there are these presets for the cut-off: They are potentiometer presets (i.e. for an axis) and should not be used directly in FSUIPC, but if you look at the calc code for those presets you should be able to define your own presets either to be used on an axis or you can define presets for cut-off and idle to be used on buttons. I can help further with this if you want to go down this route. For other aircraft, you need to use FSUIPCs logging facilities to determine how to control the cut-off, i.e. set the logging options, open the logging console and cut-off in the VC and see what, if anything, is logged, and then use that, Or you can inspect the aircraft code to try and determine how this can be assigned - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ That uses "Set Mixture Lean" which also won't work for many add-ons. You need to determine what actually works for your aircraft. John

Sorry - that is in the latest README.txt and is not in the current released version. Note that this issue was previously reported here: John

Then either you need to tune FSUIPC7s start-up parameters, or there is an issue with another add-on taking up all connections. What other add-ons are you using? Please attach your FSUIPC7.log file, and also your MSFS' EXE.xml file (look in the InstallFSUIPC7.log file if you don't know where that is located - it will be logged there). The following article describes how to tune FSUIPC7 start-up parameters, but it should really auto-tune itself in most circumstances:

No need to be sorry - you can still tag me, its just that its generally not necessary as I read all posts on these forums anyway! John