John Dowson

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

This is not correct. Multi-line lvar macros have the following format (from p39 of Advanced User Guide): So lvar macros can only operate on one lvar. However, you can overload your assignments by editing the ini file. So you would assign one button to one macro, then identify the line in your in. It will be something like: 9=PT,10,CM4:1,1 -{Macro MU2_Start: L:C441_STARTER1 set}- (although the numbers and button letters will of course be different) To overload your button, you can copy and edit this line, so I would add 10=PT,10,CM4:2,1 -{Macro MU2_Start: L:C441_STARTER2 set}- (where '10' is the next free assignment index number, and 1 changed to 2 to activate the 2nd macro entry in the file). Then, when pressing the button. both macros would be triggered. Note however, when you overload a button press by editing the ini, when you go back to the FSUIPC assignments panel, you will see the controls greyed-out (which indicates an overloaded assignment). Sorry, can't help you with this. Maybe someone else who has this aircraft can help, otherwise try asking on the forum/support for the aircraft. John

Hi David, Macro files, as well as lua files, etc, all go in the FSUIPC6 installation folder. This is the folder you select during the installation process, regardless of whether you use the 'add-on.xml' or not. If you use the 'add-on.xm' install method, then this (i.e. the add-on.xml file itself) will necessarily be created under <your account>\Documents\Prepar3d v5 Add-ons\FSUIPC6 folder, but this is not necessarily the installation folder. This will be the default installation folder for new installations, but it is recommended to change this so the installation folder is distinct from the 'add-on.xml' folder. For existing installations (i.e. when re-installing) , the default installation folder will be the folder that in which you previously had installed FSUIPC6 (or FSUIPC5). In ALL cases, if you don't know where your installation folder is, then you can use the 'Open Folder' button in FSUIPC's Logging tab, which will open Windows Explorer on your installation folder. As I said, people seem to be confused as the installation folder and add-on.xml folder are not necessarily the same, but usually are as the defaults are accepted blindly - and no one bothers to read the Installation guide! John

Hi Tasso, note also that you can also use 'reserved' areas for custom offsets if you are not using the feature they are reserved for. So, for example, if you aren't using Project Magenta, you can use the area starting from 04E0 (88 bytes), if you are not using PMDG aircraft you can use starting from 0x6420 (512 bytes), etc. John

Note also that you can use the IgnoreThese ini parameter (in the [Buttons] section) if its causing issues:

Hi Keith, Check your FSUIPC7.ini file. The [JoyNames] section should contain a list of your devices with both the JoyID number and letter assigned ('M' will be the letter assigned to the device). Then it wasn't pressed or MSFS wasn't running (or FSUIPC7 not connected). However, if you have button logging active when in the buttons & switches assignment panel, you should see a log message like this: In that line, the 1 indicates the joystick id, and the 8 the button number.

But also test with 50% or 75%. If this is graphics only and not affecting the model, then you should either see no change (i.e. <100% = 0) as we suspect, or (maybe) still see the same as if it was 100%.

That's just the graphics/visuals, not the model. I suspect that the model value would still be 0 (as Thomas says) when the graphics show < 100%. Do you notice any affect when you have, say, 50% carb heat? And if so, is this any different from 100%?

It may be possible in an actual Cessna, but as Thomas has stated: MSFS doesn't support for CarbHeat any other than ON or OFF (1 or 0). To support a carb heat axis or values other than on/off, MSFS need to implement this. You therefore need to raise a new feature request with Asobo/MSFS.

Maybe you could also show me your add-on.cfg file, located under <your account>\AppData\Roaming\Lockheed Martin\Prepar3D v5. The P3D auto-discovery should pick-up the FSUIPC add-on.xml file and update this file accordingly.

Hi Mario, ok, glad its working via the dll.xml install method. Do you have any other add-ons installed? I can only think that there must be some sort of ordering issue during the loading of the dlls. You could try (temporarily) switching back top the add-on.xml install method (just re-run the installer). If you could activate SimConnect logging, as shown in this post: Then start P3D, and show me the SimConnect log file produced. Thanks, John P.S. Also, when you re-install via add-on.xml method, please choose an installation folder outside of both your Documents folder (especially if using OneDrive) ) and your P3Dv5 installation.