John Dowson

I wouldn't worry about it if it was a one-off and isn't causing any issues.

Are you using an MS Store or Steam installation? In Steam, you can disable Steam Cloud completely, or on a game-by-game basis. I have this disabled in my steam account: There is probably something similar for MS Store installations, but you need to check. What does this mean? John

What do you mean by 'flashing issue'? Can you please explain what this is. Do you still enter/leave full screen mode? Alt+Enter is an MSFS hot-key and I can't see how FSUIPC can be involved. If you exit FSUIPC7 and use Alt+Enter, do you see the same?

Offset 0x2EA0 uses ELEVATOR TRIM POSITION, and is an 8-byte floating point number (FLT64), and is the deflection in radians. Offset 0x0BC0 uses ELEVATOR TRIM PCT, and is a 2-byte integer (S16). You can use either, depending on the units you want to use, Usually you would use 0x0BC0, as this uses a standard axis range (-16383 to + 16383), but you can also use 0x2EA0 if you want to use radians. Just different ways to skin a cat, as you say... although my wife would be very annoyed if/when I use that phrase....! But, as always with MSFS2020, things are not that simple. You may find some aircraft that use/respect one of these simvars but not the other. In such cases, use the one that works, However, I can't think of an aircraft that does this off-hand, but I think there are some that use/respect neither, and are controlled by lvars, input events (aka b-vars) or more complex calculator code (usually implemented via a preset). But you need to look at this on an individual or aircraft basis, and only when standard controls or offsets do not work as expected. John

No apologies necessary!

Ok. Are you using the same FSUIPC6 installation for both P3Dv4 and P3Dv5, or do you use two separate installations, one for each?

The first and second windows calibrate the AXIS_THROTTLE_SET, AXIS_PROPELLER_SET and AXIS_MIXTURE_SET controls, whereas those on pages 3,4,5 calibrate the individual axis controls AXIS_THROTTLEn_SET, AXIS_PROPELLERn_SET, AXIS_MIXTURn_SET. If the aircraft supports the use of both controls, you can assign to either and calibrate in the appropriate section. Some aircraft allow the use of both, but others may only respond to one. The calibration for individual engine controls provide more functionality (ie. w.r.t reverse range) if needed. The THROTTLEn_SET, PROP_PITCHn_SET and MIXTUREn_SET controls are the older controls, and FSUIPC excludes these from calibration by defaultm but you can allow calibration on these controls by unchecking this box. I am not sure why it is like this - it will be for historic reasons way before my time...I would just leave these as is, and not use those controls, unless absolutely needed. MIXTURE_SET is automatically mapped to AXIS_MIXTURE_SET, and PROP_PITCH_SET is mapped to AXIS_PROPELLER_SET (see page 44 of User guide), so no need to exclude these. Not sure about THROTTLE_SET though, as that isn't documented. Not sure if this is mapped or calibrated or not (on page 1) without checking further.... These are just the ini parameters that store the state of the check boxes you mentioned in your last question. They will only have an effect if/when assigned to the older THROTTLEn_SET, PROP_PITCHn_SET and MIXTUREn_SET controls. John

FSUIPC4 only detects a maximum of 32 buttons (0-31) natively in the button assignment panel. To use buttons 32-34, you need to use a lua script to convert these buttons to virtual buttons. Scripts for both the Alpha and Bravo, together with instructions on use, are available here: John

Hmm, strange. The splash-screen size/position is controlled by the following in the MSFS.bat file (under your FSUIPC7 installation folder), and should be sized/positioned to your screen size: if (w == 0) w = screen.width / 2; if (h == 0) h = screen.height / 2; window.resizeTo(w, h); window.moveTo(screen.width / 2 - w / 2, screen.height / 2 - h / 2); You could try manually setting a size instead, on lines 15 and 16 of the same file: Or maybe the image is being cropped to that size rather than reduced, I will take a look when I have more time.... You could also move the text further to the left, by changing this on line 73 (e.g. try 50%😞 left: 55%; John

Ok, great! Ok, so that makes sense (i.e. no assignments). Ah, ok - I wasn't sure which of your throttles the assignments were using. Seems like you have no assignments to L (Throttle - HOTAS Warthog) then. For future reference, you could have switched these by just switching around the L/M letters in the [JoyNames] section, rather than changing the letter in each assignment. Anyway, your files look good - glad its all now working again! Cheers, John

But what is loading that dll and what is giving that message? It is not FSUIPC. I can only help with FSUIPC. And there is no point responding without answering the questions I have, especially when I have no idea what you are talking about.. Please respond to my questions if you want assistance with this. John

Btw, I haven't changed anything yet for your 'VPC Panel #1' devices (2 of them) or your 'Landing Gear Lever' - do you have any assignments to these, and if so what (i.e. which letter or id were they using)? FYI, I mapped the devices as: D & G: rudders A & F: yokes C & K: tillers L: throttle B & H: stick If any if that looks incorrect, let me know.

Can you try with the following ini. Using this, start FSUIPC7 and check each device, and let me know any devices not recognised, and the device number/letter of any device without its correct assignments. Also attach all 3 files again please. FSUIPC7.ini

I keep spending time analyzing and changing your files, and then you post new ones and I have to start again... Can you please do nothing until I have had time to post you some files to test.... What do you mean by this? There is no pointing attaching just an ini, I need to see all 3 files together. Anyway, I will ignore this file - I need to sort this out in a file with your assignments, if you want your assignments to work.... Please hold off on posting further until I report back....

FSUIPC is just receiving and storing the value of the associated simvar (GENERAL ENG EXHAUST GAS TEMPERATURE), after conversion. If this is not correct, then you need to raise this with PMDG support. I cannot really help with this, sorry. However, maybe this is not the same value that is displayed on the DU. There is also ENG EXHAUST GAS TEMPERATURE (see https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_Engine_Variables.htm) - maybe this holds the correct value. I do not know the difference between these two simvars, and the documentation does not say much. You can add this to a spare/free FSUIPC7 offset and see if this matches. Also, you can add GENERAL ENG EXHAUST GAS TEMPERATURE again to a different offset, and also log this to see if the unadulterated/unconverted value matches. See the Advanced User guide on how to add simvars to free offsets.

What did you actually do with this? Looking at your ini, looks like all your GUIDs/Names don't match... I think I also need to update your FSUIPC7.ini....but to do this I need to know how you have assigned anything. It may be worth cleaning the registry of all devices, disconnecting everything and starting again....But if you are using assignments somehere, I need to know the ids or letters you are using for each device so I can update your ini file.....

But this is detected with id of 2 and joyletter B: Can you not see this device in the button/axes assignments dialog boxes? What do you see in the assignment panels when you press a button or move an axis on this device? Your log is quite strange in that it shows a lot of device scanning going on - what were you doing? Your files do show a conflict, but between your throttleTek 3 and Fulcrum One Yoke, with both being assigned the same id: and also between the throttleTek 3 and one of your T-Pendular-Rudder: To correct this, you should disconnect the throttleTek 3, remove the registry entries for this device, reboot and then reconnect it. To remove the registry entries, first run regedit and take a back-up of your registry, You can then run the attached script which should remove the entries for that device. Once you have rebooted and reconnected, start FSUIPC7 and exit, then show me your log, ini and JoyScan.csv files again. Your ini file also shows that you have no assignments (button, key or axis) to any device, and no lua scripts are started (except ipcReady). removeDevices.reg LATER: don't do this yet!! See below....

Ok. Yes, it was a bug. John

Use it to replace your current FSUIPC7.exe. That is because you have not copied it to the correct location,,,,

I'm not 100% sure on what you are trying to say, but this is your key assignment to the 'Y' key: 56=89,8,PFNX320_MainPanel_Standby_Attitude_Cage_Press,1,PFNX320_MainPanel_Standby_Attitude_Cage_Press,0 -{Y: Press=Preset Control, Release=Preset Control }- i.e. it is saving the press control for both the press and release. IIs this what you mean? I have corrected this in the attached version if you would like to try it. ok, then the attached should fix this. Please also note that for such key assignments, you should really also check the No repeats! checkbox. You can also put an N in the ini file to do this, e.g. 56=N89,8,PFNX320_MainPanel_Standby_Attitude_Cage_Press,1,PFNX320_MainPanel_Standby_Attitude_Cage_Release,0 -{Y: Press=Preset Control, Release=Preset Control }- Before attaching log/ini files, can you also pleasee always exit FSUIPC7 first - the log file you attached shows FSUIPC7 was still running when it was attached. Thanks, John FSUIPC7.exe P.S. Also, always Confirm key press assignments before clicking Ok, otherwise the parameters and no repeat flag will not be saved. Also, most of the available presets do not actual take parameters, so you can leave these boxes empty.

i am sorry but I do not understand what your issue has to do with FSUIPC. Can you please provide more details, and explain why you think this is related to FSUIPC. Are you using FSUIPC6 for both P3dV4 and P3Dv5? Are you using the same installation of FSUIPC6 for both, or are you using separate installations? Whare do you get that message, i.e. from which software?

So the issue is that the installer is not determining the correct path for your DLL.xml file? If so, please attach your FSUIPC4 Install.log file. Don't worry about those other message discrepancies - they are normal and are for historic reasons. Don't read anything into them, they are for me for analytic purposes. I can look into why the correct location of your DLL.xml file was not located, but FSUIPC4 and its installer has been closed for development/updates for many years now, and so I will not be making any changes. John

Yes, you can use (most) reserved offsets assigned to other programs if not using those....although maybe leave the ActiveSky ones that trigger file (radar image) generation, You can certainly use the PM ones, the PMDG ones, and probably most others, although I cannot confirm 100% without checking. John

No point if its working, but your logs show that you are still trying to control things before everything is ready: You should really wait longer before trying to do anything. I don't think so....but, as I said, I need to see your files (generated when you have the issue) to diagnose. I have been testing 7.4.6 most of the day here and cannot find any issues.... I always run in DevMode and do not see this. Do you still have the same issue? FSUIPC is not involved in this at all, unless you assign alt+enter also in FSUIPC... John

Strange... is the window not like this image (without the added text), or is it cropped: The 'Preparing the cabin...' text is superimposed on this. It really isn't a problem if the full text is not displayed. just ignore... Such issues have previously been reported and I have adjusted, and this is the first report on this for several years. It is not worth me changing this again on one report, as it may affect more users. John