John Dowson

If you get this issue again. post again, and try and catch it with appropriate logging... If there is no problem, why add another option? Everything is already very complicated as FSYUPC can be started in carious sim states, I would rather not add additional functionality for no perceived benefit... And this functionality has been around for many years and this hasn't been requested before, so I doubt it is that useful... Would this be to delay the starting further (until simconnect is ready)? If so, why not just add a delay?

From the Advanced User guide: You said: So READY obviously wasn't working as it should, and is why it has been corrected. If you want the programs to be started earlier, remove the READY. No - remove the READY, you don't seem to want to use this, so just remove it. John

Yes - the READY parameter wasn't working correctly, and this has been corrected in the latest beta. It does list the other changes in the beta release note: If you want it to start earlier, remove the READY. The beta version you are using (7.3.26e) has some issues - please update to the latest beta, 7.3.26g, and test with that. John

Are you using Project Magenta? These offsets are in the reserved area for PM. A cannot help with this, sorry. This offset is in an area free for general use. It is therefore not controlled directly by FSUIPC, and myst be written/read by some other tools you are using. As these offsets are controlled by other software, I cannot really help you any further with this. Try PM support. You should also mention that you are using PM in your description and in the title, as that may then attract other PM users whi may be able to help. I have no knowledge or experience with PM (and very little with FSX!), so am unable to help any further with this, sorry. John

Ok. Looking at the script you posted (always better to attach than paste!), why are you doing this: ? You should use the event.timer function.. Using that, you shouldn't need to sleep, but if you do want to add a random delay, use ipc.sleep and not os.execute.

First, using a prop. aircraft, you should use offsets 0x3B70 and 0x3AB0, as the comments in the FSUIPC offset document states: Those offsets are two-byte ints - I am not sure if they are signed or not (i.e. can they be negative?). If signed, you would use the function ipc.writeSW(offset, value), and if unsigned, you would use ipc.writeUW(offset, value). I suspect they are signed, so try that first. Note that a value of 16384 - 860 C, so you would need to scale your values of -9 to + 9 to the range temperatures that you want (e.g. -16384 to + 16384). If using offsets 0x3B70 and 0x3AB0, these hold 64bit/8-byte floating point numbers, so you would use ipc.writeDBL(offset, value). These offsets are in degrees Rankine, so you should also convert your -9 to +9 value to the variation range toy want to see in these units. John

That log file was attached when FSUIPC7 was running and ends after 31 seconds. Always exit FSUIPC7 before attaching log or ini files. It does however show that all your controllers are recognised and matches your ini. What do you mean by 'FSUIPC 7 does not recognize any of my controllers'? What do you see, for example, when you open the button assignments panel and press a button on one of your controllers - is that not registered?

Why? That does nothing at all....the ini file (containing your assignments) will still be the same - or did you delete this? If you delete this, you will have to re-assign and re-calibrate. Try the attached ini - just save it to your FSUIPC installation folder: FSUIPC6 ini Any issues, please re-attach both your .log and .ini files.

What do you mean by 'no longer recognises my numbers'? Id you have already validated yout license once and generated your FSUIPC7.key file, there is no need to validate again, although doing this should do no harm. Yes - read the section on Invalid Key Problems in the Installation and Registration guide. If that doesn't solve your issue, please explain why you need to re-register and let me know your FSUIPC7 order number and I can check the details here. But if has previously worked, it should still work. You are either entering the details incorrectly or you need to install/update your VC++ combined redistibutable package (if this is a new PC), John

Dvar isn't defined anywhere, so when you declare it in a function I suspect it will be local to that function - try defining DVar at the top of your script, e.g. local DVar = "no value" the variable val used in function UpdateWnd() is also never declared and will always be nil.

No it has not...I don't understand why you would think that. Please post ALL issues/comments/requests relating to the beta in the beta announcement thread. Yes, the DA62 is continually firing this input event for some reason. FSUIPC7 just logs what it sees. This is similar to the way many aircraft continually emit standard events/controls. For standard events, you can use the DontLogThese ini parameter to stop such events being logged. I will add something similar for Input Events at some point. but not sure when I will have time for this - it mat be after the initial release. John

Yes, sorry "not equals" in lua is '~=' not '!=' - that is C/C++, getting my languages confused... using '>0' is just as good. No problem - glad its now working and help with your issue. Regards, John

Please try the attach script. I have not tested this but its pretty simple. Make sure its running - best to add to the [Auto] (or a profile-specific [Auto.xxx]) section of your FSUIPC7.ini file, e.g. Any issues, please activate logging for Lua Plugins (only!) and show me your FSUIPC7.log and FSUIPC7.ini files. centerTankFuel.lua

Ok, thanks. I will provide you with a lua script to try - it is pretty straightforward and I may get a chance later today, but I will post again when ready. John

Which offsets? Offsets only hold data, they do not send anything. I have no idea as I do not fully understand your issue. Can you try logging some offsets (up to 4) using FSUIPC's offset logging facilities. ones which you think are holding invalid data. Try in both situations to see what the difference is. There are no 'offset processes', except the main simconnect thread that requests the data from the FS and then receives this and uses it to populate the offsets. Offsets that hold simvars are only updated from values received from the FS - they will be cleared/updated when any new value is received. I don't understand this and don't have the FSLabs A320 so I am not sure I can help that much, but if you can identify what offsets are holding incorrect data, we can go from there... Also, can you attach your FSUIPC4,ini file. John

The one that has the extension .log! You have windows Explorer set to Hide extensions for known file types. Uncheck this option (under Options->View->Advanced settings) and you can then see the extensions.

I have moved your post to the FSUIPC7 / MSFS sub-forum - please use that for all support requests when using FSUIPC7. This should be possible using a lua script. First you have to determine what holds the centre tank fuel quantity. First, try monitoring/logging offset 0x0B74 (FUEL TANK CENTER LEVEL) using FSUIPC's offset logging facilities (log as U32). This should hold the % left (*128*65536). If that looks correct, also log offset 0x0B78 to get the centre tank capacity - you will need this to determine the % value in offset 0x0B74 for 30Kg of fuel. You will also need to convert this from US gallons to kilos. Once you have determined what offset 0x0B74 holds when the centre tank is at 30kg, you can then monitor that offset in a lua script (using event.offset), and when the offset value is equal or is less that the 30Kg %age (that you have determined), you can write 0 to the same offset. If you let me know which aircraft you are using, and I have access to that aircraft, I can help you further. Otherwise, if you can confirm that offsets 0x0B74 and 0x0B78 are used by the aircraft, and let me know what offset 0x0B78 holds, I can provide you with a lua script you can try and customise. Probably next week now though as I have no time this weekend. If those offsets are not being used by the aircraft, you will need to determine what holds the capacity and current quantity. This could be held in other simvars or possibly in lvars. Again, if you let me know the aircraft, I can take a look. John

Further details from @Ray Proudfoot: Settings required to minimise / eliminate the delay when Autosave is enabled for the PMDG aircraft in Prepar3D all versions. In Windows 11 select Start - Settings. On the left menu select Privacy and security. At the top of the list select Windows Security. Select Virus and threat protection. Under Virus and threat protection settings select Manage settings. Scroll down to Exclusions. Select Add or remove exclusions Click "+ Add an exclusion" Add the following choosing File from the drop-down. Prepar3d.exe Add the following choosing Folder from the drop-down The folder containing FSUIPC6.dll The following folder. Your initial path may differ. C:\P3Dv5\PMDG\PMDG737NGXu\PanelState C:\Users\[username]\Documents\Prepar3D v5 Files Add the following choosing File Type from the drop-down. FXML PLN WX After adding those and with Autosave enabled I looked very closely for the autosave action. I barely noticed the save routine and there was no noticeable pause or stutter in P3D. My thanks to @Yakpilot for his post giving this extra info.

You only have the aileron axis assigned in one profile: Your log shows that you were using this aircraft: which is in this profile: i.e. you have no assignments to the aileron om the profile for that aircraft. I do not understand why you have different profiles for the same aircraft, different liveries. You should use one profile, and change the aircraft name in that profile to catch all variants, e.g. And make sure you have the aileron assigned and calibrated in that profile. John

As I said, no - it is not possible to read the status of a button flag from an offset. There is a "hot button" facility, where you can register to detect joystick button presses (see offset 0x2910), but not to read the status of a button flag. These are kept in internal data structures.

Ah, so it is a FAQ entry already! Maybe you could add those details to the FAQ entry for others? Cheers Ray - take care, John

No - going to post the new version now....

Thats good - if I remember correctly, most folks seem to still get a pause of a second or more, even after excluding files/folders from anti-virus scanning... Can you post the link here please - I may create a FAQ entry for this.... Yes, but it is even worse...and the flight save function is still not documented as working (although flight load is!) and so the auto-save is still noy 100% reliable. Some folks seem to have more luck with this than others....no idea why! Cheers Ray, John

Yes, this is a well know issue with auto-save and complex aircraft, such as the PMDG 737. The only thing that can be done to reduce pause times is to exclude the folder where the files are saved from any anti-virus software, but you may still get pauses lasting several seconds. There is also an autosave enable/disable control, which can be used to enable/disable autosave when it has been activated. Some folks use this to disable autosave on take-off and landing to prevent such pauses during critical moments. You could even have a lua script that enables/disables autosave automatically, maybe using the aircraft altitude above ground. Cheers, John

This is because you are using an unregistered/unlicensed version. If you have a license, you need to enter the details and validate them at the end of the installation process. If you do not have a license but would like to try the registered facilities, post in the trial license topic (at the top of this forum) and I will PM you a trial license (time-limited). John