John Dowson

Please try logging the offsets using FSUIPC's offset logging facilities (Log -> Offsets) to check what they actually hold. Also check that you have them enabled in your FSUIPC7.ini with the following line under the [General] section: PMDG737offsets=Auto Also check for the following line in your FSUIPC7.log file: 65985 PMDG 737 offsets enabled If that is all correct then it is an issue in your code - please use Paul Henty's sub-forum of using his dll client for .Net: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ John

Sounds like you have calibrated in FSUIPC, or have a general calibration section that is being applied to the DC6. If you are using fsuipc profiles for the DC6, which you should be, go into the calibration tab of the Axis assignment dialog box and chexk the Profile-specific box (if not already checked), and then reset or re-calibrate your throttles there. If you still get the same issue, please show me/attach your FSUIPC7.ini and an FSUIPC7.log file, generated with logging for Axes controls activated and showing your issue, i.e. load rthe aircraft, and move the throttles through its full range and back again, and then exit FSUIPC7 before attaching your files. John

In the current released version, when lvars are received they are given a default value of 0 and then the actual value is received a short time layer, < 1s. In the latest beta, I have delayed the sending of the lvars by 1 second and so this should hopefully resolve this issue. Please try the latest beta, available here: If you get the same issue then please let me know - I have other ideas that can prevent this in the next official release, but was hoping that the delay introduced in this version should prevent this. John

What has your issue got to do with the topic you posted in - FSUIPC7 and MSFS Steam no connection with vAMSYS? Please do not hijack unrelated topics - start a new one if you cannot find a relevant topic. I have no idea what your issue is - please explain this better. Your log file just shows that FSUIPC7 exited after 13 seconds as MSFS was no longer available - it had either crashed or exited. MSFS asks this question if it had crashed in start-up the last time it was ran. No connection was established with FSUIPC as FSUIPC exited after 13seconds due to an MSFS crash. I cannot help with MSFS crashes - see the Asobo forums for this. John

Ok, thanks for the update. If I remember correctly, there have always been some issues with a plane being loaded from a default flight, but this was mainly reported from using more complex add-on aircraft, You could try switching aircraft after the default flight is loaded, and then switching back to the preferred one - I think this was the recommended solution as I remember, or switching to the preferred aircraft after a default flight is loaded with a different aircraft. But use whatever method works best for you! Cheers, John

Done.

👍

I see you have already posted there - wait for Andrew to reply, but I think support for the VRinsight CDU2 (and CDU3) panels was only added in LINDA 3.3.5 which is no longer compatible with 32-bit sims and FSUIPC4/5 - see https://www.avsim.com/forums/topic/573578-linda-335-p3dv5fsuipc6-compatible-5-jun-2022/ John

I am sorry but I cannot help you if you are using LINDA- you need LINDAsupport: https://www.avsim.com/forums/forum/429-linda-support/ John

Hi Ken, so it seems that the only thing not working correctly is the AP altitude hold. This is set with the write to offset 07D4, and only occurs in two places in your log: This is why the altitude is being held at 2800, not at 2000 as the panel shows, so it looks like it is out of sync. Rather than just switching alt hold on/off, maybe try changing the value to see if it then syncs correctly with the FS (turn off, change value, turn on). However, note that the comment on 07D4 (in the FSUIPC7 Offset Status document) says this: Autopilot constrained altitude value (limited by Flight Plan and flight profile as in SID), as metres*65536. Also see offset 0x0798 for target altitude value So maybe this value is being constrained by the flight plan? You can try logging both offsets 07D4 and 0798 using FSUIPC's offset logging facility (Log->Offsets, log as U32 and check Display to - Normal log file) to see what they are holding, although you will need to divide the logged value by 65536 to get the displayed value in meters. This would show you what the target value and constrained value is as held by the FS, and not what the radio panel is displaying - but hopefully at least one should match! But there certainly doesn't seem to be any issues with FSUIPC. Maybe fsRadioPanel should be using the target altitude offset and not the constrained one, but I am not sure. I am by no means an expert in AP systems - you would be better of asking about this on the avsim forums, or using the fsRadioPanel support. For the vertical speed, this is using offset 07F2 which has the following comment: Autopilot vertical speed value, as ft/min: Write reported as working but only after sending an AP VS SET control (only once) No AP VS SET control is being sent, so maybe this could be why this isn't working, and would (probably) need an update to fsRadioPanel to fix. However, as the target altitude is set at 2800 (and not 2000), which is basically the altitude you are flying at, the VS will be ignored anyway as you are at the target altitude - according to the FS, not the display panel. John

That is just how MSFS / Asobo document functions that are not working or fully reliable. There will be no elsewhere....it is up to Asobo to fix this. John

It is in the drop-down list of controls for button/key assignments when you Select for FS control. As stated in many posts on this issue, FSUIPC just calls the provided SimConnect SDK function to save a flight and it is this that is taking the time - there is nothing I can do about this. Note also that the SimConnect_FlightSave function is still documented as: NOTE: The current status of this function is NO ERROR, NO RESPONSE. which implies that it is still not 100% reliable. So I would recommend not to purchase FSUIPC7 if you only want to use it for this feature. John

Please attach your FSUIPC4.log file, not screenshots. This is as expected, as you are using an unregistered version and don't have any assignments in FSUIPC. However, if the G key is assigned in FSX, you should see the event (with Event (non-axis controls) activated) once processed by FSX. This seems strange, but does seem to be related to your default scenario. Try deleting that and saving a new scenario and make that the default, to see if this resolves the problem. John

Well, its not finally solved - this is just an interim fix that removes the request of simvars from the new fuel system. I will look into a proper fix so that these simvars are requested only when the new fuel system is actually being used.... John

Can you please also attach your FSUIPC7.ini file (although your panel isn't assigned in FSUIPC). Also please disable logging for Axes Controls - you only need Event logging activated, and the axes events are just noise in the log file for this issue. Keep IPC Write logging activated, as it looks like the FsPanelServer is writing to offsets to control things. I will check the offsets that it is using to see if these are writeable and working in MSFS, but a cleaner log file (without axes logging) would help. I will look into this further tomorrow. John

I really can't see how a key assignment can work at some locations and not others - this just doesn't make sense. I cannot really advise as I don't have this aircraft, although other posts indicate that landing gear assignments work for this aircraft, e.g. see You can also use FSUIPC's logging facilities to see what events are being sent - activate logging for Events (non-axis controls) and open the logging console, and see what, if any, events are logged when you retract the landing gear using the VC. Then see if you get the same event with your key assignment (you can also activate logging for Buttons & Keys). John

Those offsets are maintained based upon the AI traffic data received from MSFS via SimConnected. I suspect that MSFS isn't providing the traffic information for traffic injected by FSLTL for some reason. You can log AI traffic data (what FSUIPC is seeing) by using a Log->Custom value of x10000 or x50000 (for all AI data). John

You should NOT manually update the [LuaFiles] section. This section is maintained by FSUIPC and is the list of the lua files in your installation folder, or in the folder specified by the LuaPath ini parameter (which goes under [LuaFiles]). All your lua files must be in the same folder, not under sub-folders, or they will not be recognised by FSUIPC. They will, however, be auto-started, but they should really not be in a sub-folder. The log file you attached is incomplete (i.e. FSUIPC was still running) - please always exit FSUIPC before attaching logs. You are using a very old version of FSUIPC7 - 7.3.10. The latest and only supported version is 7.3.17 - please update and try again. There was a fix for this issue in the 7.3.11 update: John

I don't know how FsRadioPanel is using FSUIPC, so it is difficult to advise. You can try activating logging for Events as well as Buttons & Keys, open the logging console window (Log -> Open Console) and see what events/controls are being sent. You can also attach your FSUIPC7.log (generated with that logging enabled) and FSUIPC7.ini files here and I can take a look. Have you tried with various aircraft? Does this apply to all aircraft or only with specific ones? John

No - a purchased license is the same as the trial license, except that it doesn't expire. A short pause when saving a flight is common, especially when using complex aircraft. There are now many reports about this - see Check that the flight-save folder is excluded from any anti-virus scanning - this can improve the time taken to save the flight. John

Yes - don't know how that happened (cut and paste or auto-correct...) - I gave corrected that now, thanks. John

There is an issue...a mismatch between the loop that calculates the number of lines and the one that populates the presets. This has been corrected in the attached - blank lines should be ignored. lines starting with '//' and also lines that do not contain a '# character'. Can you please try with the attached version: FSUIPC7.exe John

No - each version of FSUIPC (4, 5, 6 & 7) requires its own license.

Can you try the attached version with the following added to the [General] section of your FSUIPC7.ini file: NumberOfPumps=0 This should prevent all simvars from the new/modern fuel system from being requested, and so stop the console log messages: FSUIPC7.exe Note that this is only a build to test to see if it is indeed these console messages that are causing the issue. If you still get micro-stutters, please let me know if this is aircraft specific all for all aircraft (i.e. try various aircraft), and if aircraft specific please let me know what aircraft you are using. Also, if you have changed the LvarUpdateFrequency in the FSUIPC_WASM.ini from its default of 6Hz, please change back to the default to see if that improves matters. Thanks, John

Both ComWriteLoopTime and ComReadLoopTime should now have a default value of 10, so you shouldn't need to set these values in your ini file. Thanks for the update. John