John Dowson

I have added two new (undocumented) controls for the master avionics: Avionics Master 1 Set Avionics Master 2 Set Tested these in the C172 and they seem to operate in the reverse manner than usual, with a parameter of 1 turning the avionics off, and a parameter of 0 turning them on. These new controls are available in the attached version: FSUIPC7.exe

I've performed various tests over the weekend on P3Dv5 and windows 1909 and 2004, with and without various add-ons (ActiveSky, Chaseplane, OrbX, A2A), and cannot reproduce this issue, even with P3Dv5/FSUIPC6 running for over 24hours. Looking at the thread for the same issue over on the LM forums (https://www.prepar3d.com/forum/viewtopic.php?f=6312&t=139856&p=228300&hilit=freeze+after+7+hours#p228300), it seems that some people are also experiencing this issue without FSUIPC6 running. Therefore I really don't see how this can be related to FSUIPC, and must be something internal to P3D, maybe on the SimConnect interface there. Reading the various reports, its also not clear what the actual symptoms are when this occurs. Some people report loss of flight controls, were others also report loss of mouse and keyboard functionality. I think the way forward on this one would be to get LM to investigate this, so I would suggest that you use that LM thread (link above) and try and clarify the issue and how to reproduce there. Sorry I can't be of more help, but I really can't think of anything else I can do with this issue. John

Hi Al, it is not possible to make the axis sensitivity conditional on whether the a/c is on the ground, and calibration slopes can't be changed or adjusted once assigned. Of course, you can always use lua to intercept the axis and do your own calibration (or slope adjustment) there, but you would have to implement this yourself (i.e. you cannot use FSUIPC's built-in slope calibration). For adjusting sensitivity between the rudder and tiller when on the ground, take a look at the MaxSteerSpeed and RudderBlendLowest ini parameters (documented in the Advanced User guide). John

First, you posted in the FAQ sub-forum, where it states : Answers to Frequently Asked Questions.. NOT for support requests.. Please post in the correct forum. There are two ways of doing this: - using Macros: see the Advanced User manual - by editing the ini. To do this, assign your first action. Then open the .ini file and located the entry for that action and copy it. Then, back in FSUIPC, change the assignment to your second control. Then, back to the ini and paste back in the line you copied from the first action, and change the first (index) number to the next free one (usually increment by 1) to make it unique. When editing the ini, you can do this with P3D/FSUIPC running, but need to use the 'reload all buttons' function to reload your assignments once changed.. Also, not that one you have overloaded assignments, when you look at the assignments in the ui panel you will only see one of these and it will be grayed out.

Yes, when it goes on sale. A time-limited license is provided for the time being. There will be a discount for FSUIPC5 and FSUIPC6 license holders. John

Not yet - I'd like to get at least the main documentation (user guide, advanced user guide + offset status) updated before it goes on sale. I was hoping to get this done by the end of the month but looks unlikely, so it will most probably go on sale in mid November (I'll extend the beta license until it goes on sale). John

Sorry, this is incorrect - it was with 5.0HF2. I don't think this can be an issue with FSUIPC6, especially as it occurs when FSUIPC6 is running but not actuallly doing anything. What are these - they don't seem relevant, e.g. the FSUIPC6.log file is for a session lasting around a minute, and certainly not 7 hours+. The SimConnect log file just shows a few exceptions from FSLabs. I did the test on windows 1909. I'll retest on 2004 to see if this is an issue, but doubt it very much. Did you check the event viewer when this issue occurs? Maybe worth checking to see if there are any system events relating to lack of resources. You can also try uninstalling and re-installing the VC C++ redistributables, as sometimes strange things can occur if these are out of date or corrupted. Worth a try at least. Other than that, I'm not sure what more I can do to investigate this issue.

Hi Achoriham, No I haven't. You could try unchecking Auto-Connect to FS. Then, when you "re-sync", manually disconnect and re-connect, to see if that solves your issue. John

I've had P4Dv5 running with FSUIPC6 + Chaseplane for over 24 hours now without an issue. However, I'm currently using the P3Dv5.1 beta. I'll roll back to 5.0HF2 and retest to see if its an issue with that version.

Sorry, I'm getting confused again! LogCustom is FSUIPC7, for FSUIPC6, please use: Debug=Please LogExtras=x4 Later: unfortunately saved files or errors saving files aren't currently logged - I will add for the next release. However, the additional logging will still show when autosave is activated and file deletions and errors thereof. Currently 4h30mins into a flight....

The WideServer.log file is created when the WideServer component, embedded in FSUIPC6, is started. Note that the WideServer component is only started once 'ready-to-fly'. Can you check what is in FSUIPC7's WideFS menu - do you see an 'Enable' entry or a 'Disable' entry? If the latter, the WideServer component is running, and you should see the status in the MSFS title bar. If its 'Enable', then it could either be grayed (in-active) or active. If its grayed, then you are not 'ready-to-fly'. Load an aircraft and get ready-to-fly and you should see this made active. Then select to enable if it does not do this automatically. Note also that. when FSUIPC7 starts, it will only automatically start WideServer if it was previously enabled. If you close down with WideFS (manually) disabled, it will also be disabled the next time you restart. So, first check that the WideServer component is running when it fails to connect please, and a WideServer.log file has been created. I've also recently made a few changes to the starting of the WideServer component (not yet released), but these relate to restarting WideServer when MSFS is closed and restarted, so I don't think these would help. Later: ok, just checked your ini and you do have WideFS enabled: WideFSenabled=Yes So the WideServer component should start automatically once 'ready-to-fly, and any clients will not connect before this. As Thomas says, check your address config.

Ah, sorry -previous instructions were for FSUIPC7! For FSUIPC6, you need to add the following to the [General] section of your FSUIPC6.ini:

As I said, this looks to be due to the old files being deleted but new ones not being created. Please add the additional logging flag I gave to log autosave to verify this. However, something strange is certainly going on as I would expect to see continual errors (every 600 seconds) on deleting autosave files if not present, which is strange.

Are you using the dll.xml install method (and not the add-on.xml method)? I ask as this is normally due to the dll method being used, with two entries for FSUIPC6. There was an issue with an earlier version of FSUIPC6 (before 6.0.8 I think) that failed to remove this entry in certain situations. Even though this has been corrected in the later installer, there can still be issues. Check your dll.xml file under ...\AppData\Roaming\Lockheed Martin\Prepar3D v5, and if there are two entries, remove one. If you are using the add-on.xml method, check that file (if it exits) to make sure that there are no entries for FSUIPC6. John

@Nikolaj.Delaney I'm sorry, this is confusing me... are you saying that you only get the freeze after 7 hours if you have an assignment in FSUIPC7, but otherwise not? Or that the freeze occurs (the moment) when you try to add an assignment (after 7 hours?) ? Thats just a spreadsheet that I don't really understand - FSUIPC is mentioned twice (Ok for reinstall, blank for reset to defaults), and not mentioned when the result is freeze. Anyway, I must admit that I've never done a flight over 7 hours. I'll see if I can set one up over the weekend and if I can reproduce the issue.

Why do you think this? You are only now keeping 2 autosave files. When it comes to create the 3rd, it will delete the oldest one. So it looks like the oldest one is being deleted, but the new one isn't being created. So, once this happens twice, you will have no autsave files left, although FSUIPC thinks that there are two files. And the next time it comes to save a file, it tries to delete the oldest which doesn't exist, hence the error in your log. You can log autosave activity by going into Log->Custom, and entering x4. Try this to see what it reports. If you've got the file, then its correct. It is a large file. I'm not really interested in the contents, unless you can see any errors there around the time you lose control. Can you see anything? It should increment and start a new log file on each connection, but it doesn't look like this is working correctly in MSFS. Don't worry about it. The autosave error is timed at 5647891, i.e. just over 1h 34mins into your session. You then have a 'Sim Stopped' event 4 hours 37 minutes into session, then another at 7 hours 46 minutes into the session. When exactly did the sim stop responding? Is it related to any of these events? If the autosave issue is occuring such a long time before you lose control, I don't think these issues are related, but lets wait until I see your log with the autosave logging activated. Btw, did you use FSUIPC5 (with P3Dv4), and if so did you experience the same issue? Later: when the issue occurs, if you close FSUIPC do you then regain control? What if you restart FSUIPC?

It looks like this is due to an expected event (position changed) not being received in this start-up situation, due to a change I implemented a few weeks ago in an attempt to clear the in-dialog flag at the last possible minute. However, as it seems I can't rely on this event in all situations, I will revert to the previous behavior. Please try the attached version: FSUIPC7.exe

Are you sure it didn't save any? You session started at 22/10/2020 00:00:50, and the first autosave delete failure was for the file created at 061140, so 5hours 20mins into the session. I suspect that autosave files were created before this, but have all been deleted - especially as you are only keeping 1 autosave file. As autosave is also done by a simconnect call (and you have plenty of disk space), I suspect that it is simconnect that is failing. Not sure why there are no errors reported though, which is strange. I'll get back to you (tomorrow) with some additional logging flags that you can add. However, as all your controls are handled by P3D and not FSUIPC, I don't understand how this could affect you controls...

It may be an issue with SimConnect if it only occurs when using add-ons. Try logging SimConnect, and see if that tells you anything when this occurs. To activate SimConnect logging, see Maybe also worth checking the windows event viewer to see if anything is reported there (although there won't be a CTD report). Can you also please confirm that it only occurs with FSUIPC running, i.e. a vanilla (without add-ons) P3D is ok, and P4D with ONLY FSUIPC installed gives this issue? I'm sorry, but is this a separate issue? Are you saying that autosave isn't working for you? I can see you have errors in your log: Thats due to an error with FSUIPC6 trying to delete files previously saved? Do you have any auto-save files? Note that when using complex add-ons such as PMDG, the autosave files can get quite large. Can you also check your disk space - especially when you experience your issue. Anyway, please clarify your issue with AutoSave and we can add some logging flags to see whats happening. John

No - as your event function reacts to changes to 0x3D00: Why not use that, i.e. event.offset(0x3D00, "STR", "onload") The value will then also be passed to your function, so no need to read it.

Could you activate logging of Axes Controls, start a session that shows your issue, then post again attaching your FSUIPC7.log and .ini files. Also check that you don't have the co-pilot handover activated when this occurs (or autothrottle if the TBM 930 has one). Does this only occur when starting a session on approach? What happens if you start on the runway ready for take-off?

I'm not sure why this is - what is the FLT file loaded when this occurs (check your FSUIPC7.log)? Yes, a flight file called flights\other\MainMenu.FLT is sent when MSFS enters the menus. I guess I could add some code to ignore this FLT file, and not update the offsets when this changes. However, as your script acts on the value of offset 0x3D00 (the name of the current aircraft), why don't you just use that for your event? Your script would then fire only when the aircraft name changes.

Please read the release note or the README.txt provided:

That is because FSUIPC6 licenses are not valid for FSUIPC7. FSUIPC7 is still in beta and comes with a free time-limited license (until the end of this month), so use that. I had intended to get FSUIPC7 ready for sale by the end of the month, but I don't think I'll be able to complete the documentation updates by then. If not, I'll provide a new extended time-limited license valid until it goes on sale. When it goes on sale, there will be a reduction for FSUIPC5 or 6 license holders. John

Hi Mario, I see that you are using the ActiveSky beta for P3Dv5 and am wondering if this is the issue. Could you re-install FSUIPC6 using the add-on.xml method (using the same installation folder, i.e. C:\Users\Admin\Documents\Prepar3D v5 Add-ons\FSUIPC6), then, before starting P3D, use the attached add-ons.cfg to replace the one you have in your <your account>\AppData\Roaming\Lockheed Martin\Prepar3D v5 folder: add-ons.cfg This file will try to load FSUIPC6 after ActiveSkyP5. Let me know how that goes. If it doesn't work, close P3Dv5 and try re-ordering by editing that file and changing: to and then starting P3Dv5. This will then try to load FSUIPC6 before ActiveSkyP5. I have ActiveSky but have not tried the new beta yet with P3Dv5 (although I did register for this). I'll try myself later in the week, when time permits, to see if I need yo update the installation procedure for this. Thanks, John