John Dowson

Yes, I know, but this topic is for your ACARS not connecting. You already raised a topic for WideFS not connecting, so use that for the WideFS connection issue.

Yes, I know, but this topic is for your ACARS not connecting. You already raised a topic for WideFS not connecting, so use that for the WideFS connection issue.

I guess it makes sense that the WHOLE / FRACT events control the standby, as there are no stnby equivalents...sorry about that. To set the active frequency directly, you would need to use the NAV1_RADIO_SET control, or write the new frequency (in BCD format) to offset 0x0350.

As I said, please check what it is assigned to. For ALT select in the 737max, you need to use the input event FCC_ALTITUDE_SEL. Have you tried assigning to this, as advised? Well, I think the strange thing is that the other encoders actually work! The default assignments will be to the standard FS controls - these do not work for many aircraft functions in MSFS2020, and even less in MSFS2024. The encoders that are working must be because the aircraft is using the standard controls for those functions, but not for the Altitude select, where it is using that input event.

Have you configured FSUIPC to handle your VRInsight MCP? Can FSUIPC see the (rotary) buttons of the alt select knob in the buttons assignment panel? And if so, what is this assigned to? To control the altitude selection in the 737max in MSFS2024 you need to use the input event FCC_ALTITUDE_SEL, which takes the altitude as a parameter. To use this, add this input event to a spare/free FSUIPC offset and assign to one of the offset increment/decrement controls.

Not via FSUIPC. Only one of those ini parameters will be read. Normally you would write the file to a networked drive if you wanted it to be accessed from multiple PCs. If you wanted it copied to multiple locations, you could maybe trigger a lua script after the file was generated which could call the OS to copy the file.

Of course there are events for active frequencies, e.g. 65707 COM_RADIO_SET 65708 NAV1_RADIO_SET 65636 COM_RADIO_WHOLE_DEC 65637 COM_RADIO_WHOLE_INC 65638 COM_RADIO_FRACT_DEC 65639 COM_RADIO_FRACT_INC 65640 NAV1_RADIO_WHOLE_DEC 65641 NAV1_RADIO_WHOLE_INC 65642 NAV1_RADIO_FRACT_DEC 65643 NAV1_RADIO_FRACT_INC 66434 COM_RADIO_FRACT_DEC_CARRY 66435 COM_RADIO_FRACT_INC_CARRY 66445 NAV1_RADIO_FRACT_DEC_CARRY 66446 NAV1_RADIO_FRACT_INC_CARRY 67361 COM1_RADIO_HZ_SET 68064 COM1_8333HZ_MODE_TOGGLE 68065 COM1_8333HZ_MODE_SET etc Basically you have all the same events on active frequencies as with standby.

WideFS only supports FSUIPC client programs. I think the only way to move MSFS pop-ups to a networked PC would be to use something like WideView. There may be other solutions - probably better to ask on the Asobo forums.

Isn't the error obvious? BCD for 109.20 would be 0x0920 (leading 1 omitted). You are converting the value to hex, not BCD.

This really depends on the function/control. Generally you would use logging - set logging for Events (Log -> Events) and open the logging console (Log -> Open Console). If you see lots of events logged when not doing anything (many MSFS aircraft continually emit certain events) then you should use the DontLogThese ini parameter to stop such events being logged (see Advanced User guide). Then click the button/switch/etc in the VC and see if anything is logged, and if so you can use that. You can also log Input Events with a corresponding ini parameter of DontLogTheseIE. If standard (or known custom) controls are not used, then you can try inspecting the model behavior to see how how button/switch is implemented - see the following on how to do this: MSFS2020: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ MSFS2024: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ What aircraft/avionics system? There are many presets for this, e.g. for the G1000 in MSFS2020: AS1000_MFD_RANGE_DEC and AS1000_MFD_RANGE_INC for the G1000 in MSFS2024: MFD RANGE ZOOM - Dec and MFD RANGE ZOOM - Inc for the ATR: MSATR MFD CPT RANGE INC + and MSATR MFD CPT RANGE DEC - etc So it really depend on the aircraft / avionics system being used.

Calibrating when assigned with 'Send to FS as normal axis' can be problematic, and this depends on the aircraft. When assigned this way, the uncalibrated values are sent to the sim. and then the value is calibrated once it is received back with the event, and it is masked (i.e. original value blocked) and then calibrate value is then sent. This can cause issues with some aircraft due to priority levels. And it is not clear to me when any MSFS calibration is applied - if this is on the initial value sent, or on the 2nd calibrated value sent. Basically if calibrating when assigned with 'Send to FS as normal axis' causes issues, you will not be able to use FSUIPC's calibration facilities. If you wanted to calibrate such an axis, you can write the axis value to an FSUIPC offset and read that value and perform any calibration needed in a lua script and then send the event on from the lua script with the calibrated value. You could possible try changing the event priority values to see if this helps, but I wouldn't recommend this. John

What does this mean? The 2nd image shows that FSUIPC is receiving a value of 16242 when the lever is at the 20% position. What In/Out values do you see in the Axes Assignment tab? What is the value there at the 20% position, and how does that increase as you move the lever further? How does this axis look in the windows game controllers app? Have you tried calibrating it there?

Remove the calibration for this in FSUIPC (click the Reset button on page 3 of the calibration panel). Not sure why, but something strange seems to be happening when these axes are calibrated in FSUIPC. Not sure if its the aircraft or the _EX1 controls. I will make a note and look into it sometime.

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