John Dowson

Profile settings are automatically loaded, you don't need to do anything. Make sure that you are using substrings for the aircraft name in your profile section (needs manual editing of your FSUIPC7.ini file) so that it catches all different versions/liveries of the aircraft. See Appendix 2 (About the Aircraft Specific option and “ShortAircraftNameOK” ) in the Advanced User guide for details. If you think that a profile is not being automatically loaded for a particular aircraft, activate logging for Buttons and Keypresses + Events, load the aircraft, press a button that you think should be assigned, exit and show me your FSUIPC7.ini and FSUIPC7.log files. John

The log you posted looks reasonable with the N1 values starting at 4401 and then reducing to 0. Did SLC show the same? As I have said, the FSUIPC offsets are just holding the values as received from the FS. If they are different in SLC, then it is an issue with SLC. If the N1 values reported in those offsets are not correct, then it is a an issue with the aircraft. John

The spoiler controls are being logged ok. I don't know why those controls aren't having any affect. You have assigned to 'Direct to FSUIPC Calibration'. You could try switching to using the FS control instead, and remove the spoiler calibration line under [JoystickCalibration.787]: Spoilers=-11903,-7168,-512,12223/24 The calibration looks a but strange in any case - you have a very large null zone set.

No. The scan returns all available lvars at the time of the scan. The issue is that some lvars, especially in complex aircraft such as the FBW A32NX, are created quite a while after the initial scan is performed. You can delay the time the scan starts in the WASM module, by setting the WASM ini parameter LvarScanDelay. From the Advanced User guide P45: I would suggest a value of around 45seconds, but try varying it until you get all the variables you need. Note that you can also issue a WASMPtr->reload() call at any time which will re-scan for available lvars (as well as reloading hvar files). John

If you activate event logging and move the switches in the UI, do you see any events logged (in your FSUIPC4.log file)? If so, try assigning to them. You could also try looking to see if there are any lvars that look applicable - try listing the available using the List Local Panel Vars control. Do you mean the box where you enter the macro name (see P37 of the User Guide)? If so, you need to give the macro a name, and once you have finished creating macros, end the macro session. Please see the User guide for details. Mouse macros should work, if there are no standard controls. I don't have the Aerosoft A321 for FSX, but I do for P3Dv5. I can take a look at that to see what that uses, but I can't be sure it will be the same for the FSX version.

Yes, you just need the one section: Delete the other.

I think there are issues using the TCA Quadrant with FSUIPC. See this thread: The last posts from @Jetdriver50are interesting but we never got a response from the OP: John

You still have not changed your ini as recommended...never mind, but there is no point sending me the same ini each time if you are not going to change it. I only want to see it if you have changed anything. And you will have issues with the profile not being loaded for some aircraft - any not currently specified in your profile section. I don't understand why you do not change this. Your log shows the assigned control being sent each time you press a button. However, there are lots of other events that are being seen not related to button presses. This may be normal for the QW, I don't know - some add-ons do seem to continuously emit certain events, but they do look strange (especially so many PAN_* events...). As for the spoilers, there are quite a few spoiler controls being sent upon start-up: I don't know where these are coming from, but its not FSUIPC. Ok, lets see what they have to say. It does look like something the aircraft is doing. The aircraft also seems to take a long time to load. You should give it more time before you try to do anything. And as your spoilers are on an axis, you need to activate logging for Axes controls, not buttons, sorry. Could you try that - produce a short log file where you load the aircraft (wait until fully loaded...), operate your spoiler axis, then exit and show me the log file.

To run FSUIPC6, you have to run P3D, as its an embedded dll, so I don't see how this can help...you will also get the weather/radar.bin from P3D... John

This is no longer possible, as ActiveSky is NOT compatible with FSUIPC7. FSUIPC6 (and earlier) use a dll provided by ActiveSky to achieve this - either the as_connect_v5.dll or the as_connect_64.dll (depending upon AS and FSUIPC version). But these dlls are no longer loaded by the FS, and if they were FSUIPC7 would still have no access to these as FSUIPC7 is a separate executable and is no longer embedded into the sim. It is therefore no longer possible for such images to be created in FSUIPC7, sorry. John

No, but you are logging the values incorrectly. You are logging them as U8, an unsigned byte, whereas they are in fact two byte unsigned shorts, so should be logged as U16. This is why you are only seeing values in the 0-255 range (the range for a U8). So, change your logging to U16 and repeat your tests - and you do not need IPC read logging activated. You can also see the log in real-time if you open the logging console. Look at the logged values and compare to what you see in SLC. If they are different, then report this to SLC, You could also log the N1 %age values, held as 8-byte floating point values in offsets 0x2000 and 0x2100. john

Your image shows the values logged as 107. on a scale of 0-16384, this is .007%, which is basically zero.....I don't know where SLC is getting those numbers from...

Please stop with pasting images. I need to see your files - I will not look at images.... If the logged values are different than those shown in SLC, you need to contact SLC to find out why... If the logged values are not correct, then ask on the PMDG support forums. FSUIPC just requests these values and stores them in offsets for access by 3rd party programs, such as SLC. John

You could try reading the documentation on logging.... You need to select where to log the information. Check 'Normal log file' and the values will be written to your FSUIPC6.log file. You can attach that here so that I can see the values. I am only suggesting you check this for the values you need....maybe PMDG implement their own systems for this. However, if it was previoulsy working ok, O suspect that something else must have changed.... This is why I have suggested logging those offsets, so we can see what FSUIPC is holding for those values. Nor am I! How can SLC be displaying such values if its an unsigned int...only SLC can answer this question... But it will help if you can log those offset so we can actually see what the source of those values actually is... John

You could start by taking a look at the PMDG 737NGXu offset document Offset Mapping for PMDG 737NGX and 737NGXu.pdf. You should also try with a different/stock aircraft/jet. John

Using FSUIPC's offset monitoring facility. Take a look at the Logging tab. John

The description for offset 0x0898 reads as follows: Engine 1 Jet N1 as 0 – 16384 (100%), or Prop RPM (derive RPM by multiplying this value by the RPM Scaler (see 08C8) and dividing by 65536). Note that Prop RPM is signed and negative for counter-rotating propellers. In FS2004 this also now gives the Robinson model’s RPM, when scaled by the RPM scaler. and simply holds the value of the indexed simvar TURB ENG N1:1. Therefore any values you see in this offset will be coming from P3D. So the readings used to be ok? What has changed on your system? You could try logging those offsets in FSUIPC to see if the values match those shown in SLC. Many complex add-ons implement their own subsytems and dont use the default P3D simvars. PMDG, for instance, provide their own SDK and have a dedicated offset area. Have you checked this to see if the information you need is available in the PMDG offset area? Also, as the offset description says 'as 0 – 16384 (100%)', I don't see how you can be getting a value of -33300000, as that is outside of the range of a short int (-32768 to 32767 unsigned or 0-65535 signed).... John

No you haven't! Both zips you attached earlier only contain FSUIPC6.ini files, and both show that you still have NOT updated your ini file as suggested: Please change that to: And I am still waiting to see an FSUIPC6.log file with the appropriate logging added (Buttons and keypresses + Events) that shows me your issue. I cannot help you unless you show me this file. And also show me your updated FSUIPC6.ini file. John

That image doesn't help me at all - I have no idea what that is! I need to know what offsets you are getting the data from. John

Where are you reading this data from? From the PMDG offset area (via the PMDG SDK) or are you using standard offsets? Please let me know the offsets being used (or how you are getting these values) and I will take a look. John

Any line starting with a semicolon (';') or double slash ('//') is ignored, so you can use these for full line comments. Hvars themselves cannot contain spaces, so the hvar name is read up to the first space, and anything after that is ignored. So you can add comments after a space. Probably a good idea to use your own designator though, e.g. '//' or '--'. John

But Active Sky is not yet compatible with MSFS2020 is it? As Pete has said, once Active Sky release a version compatible with MSFS, we would then need to look into integrate this functionality back into FSUIPC7. John

Keystrokes sent to MSFS (when that has the focus) should be forwarded to FSUIPC7 via SimConnect, so FSUIPC7 should also receive keystrokes when MSFS has the focus. If this is not happening, it could be that you are using keystrokes not accepted by SimConnect - not all key strikes are propogated. What key strokes are you using? But it must be a HID joystick type device if you are assigning to it in FSUIPC, as FSUIPC only recognises such device types for direct assignments. Are you sure it is not an XINPUT type device? Maybe you can show/attach your FSUIPC7.log and FSUIPC7.ini files. John

You gave the title of your post as your user name. This does not help anyone - please give your posts an appropriate title relating to your actual issue. This helps others who may encounter the same issue. I have updated the title for you. The only problem with not being able to determine the location of your MSFS UserCfg.opt file is that the WASM module cannot be installed, and also the auto-start component. Both of these can be installed manually, if needed. As you have q steam install, your UserCfg.opt file should be installed under the following folder: [your user account]\AppData\Microsoft Flight Simulator\UserCfg.opt Can you check that it is there? If so, then the issue is that your $APPDATA environment variable isn't being set correctly. Can you check if this is set, and if so what value it has. It may need setting correctly - lots of info on google on how to do this, e.g. https://liquidwarelabs.zendesk.com/hc/en-us/articles/210634163-How-To-Make-APPDATA-and-LOCALAPPDATA-Environment-Variables-Follow-The-Registry-Keys Again, sounds like this is due to your environment not being set-up correctly. But where do you see this message? John

This occurs for XInput devices, such as the Xbox One and Xbox 360 controllers. Are you using one of these, or another XInput-type device? FSUIPC will only get input from such devices when it has the focus. To get around this, you can use a free conversion utility called XInput Plus. From the FSUIPC7 README.txt file: John