John Dowson
-
Posts
13,253 -
Joined
-
Last visited
-
Days Won
270
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
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
-
1 hour ago, vieira12 said:
it didn’t save any files at all wich is strange
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?
On 10/22/2020 at 12:32 PM, vieira12 said:the auto save that’s what it supposed to do save the flights correct ? It’s not saving as it says in the log it happens with any aircraft
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:
Quote4264859 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Wed 014928" (error 2/2)
22850171 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Thu 061140" (error 2/2)
23449718 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Thu 062140" (error 2/2)
24049250 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Thu 063139" (error 2/2)
24648781 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Thu 064139" (error 2/2)
25248343 *** ERROR: Autosave couldn't delete "C:\Users\duart\Documents\Prepar3D v5 Files\AutoSave Thu 065138" (error 2/2)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
-
2 hours ago, pilotjohn said:
You mean use 0x3F02 for the event trigger instead?
No - as your event function reacts to changes to 0x3D00:
17 hours ago, pilotjohn said:acft = ipc.readSTR(0x3D00, 256)
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.
-
14 hours ago, drave said:
if I fancy practicing some landings and start the session on approach then the throttle lever has no effect ??
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?
-
11 hours ago, pilotjohn said:
However it also seems to trigger after I'm in the aircraft (as I started a takeoff roll for example).
I'm not sure why this is - what is the FLT file loaded when this occurs (check your FSUIPC7.log)?
11 hours ago, pilotjohn said:It also triggers on return to the main menu.
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:
QuoteMissing Functionality
The following functionality is not currently available in FSUIPC7. We may look at re-instating some of these
items at a later date, if and when such facilities are provided by the MSFS SDK:1. Mouse Macros (and other mouse functionality, e.g “mouse look”, etc): pending facilities to be provided
-
40 minutes ago, Aman Lulo said:
when trying to validate it, my FSUIPC v 6 name and Address hasn't been accepted
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:
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:
Quote[Package.5]
PATH=C:\Users\Admin\Documents\Prepar3D v5 Add-ons\ActiveSkyP5
ACTIVE=true
[Package.6]
PATH=C:\Users\Admin\Documents\Prepar3D v5 Add-ons\FSUIPC6
ACTIVE=true
REQUIRED=falseto
Quote[Package.5]
PATH=C:\Users\Admin\Documents\Prepar3D v5 Add-ons\FSUIPC6
ACTIVE=true
REQUIRED=false
[Package.6]
PATH=C:\Users\Admin\Documents\Prepar3D v5 Add-ons\ActiveSkyP5
ACTIVE=trueand 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
-
3 hours ago, dwbarnett said:
[Macros]
1=MU2_Run
1.1=L:ENG1_RUN=SET
1.2=L:ENG2_RUN=SETThis is not correct. Multi-line lvar macros have the following format (from p39 of Advanced User Guide):
QuoteThe multi-line macro format can still be used with the Lvar macros, as follows:
N=L:name
N.1=action1
N.2=action2
...etc
However, unlike the usual multi-line macros, those using an L:Var cannot be mixed with any other parameter types or other L:Vars.
The single L:Var identifier is the actual macro name as well, so this prevents such complexity.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).
3 hours ago, dwbarnett said:However, there is no animation of the switch. It appears as there is another L:var used called l/R_RCS_SW. Apparently this controls the animation of the switch. Not sure how I would utilize this in my macro.
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,
3 hours ago, dwbarnett said:s the macro in the correct place, i.e. in your installation folder (P3D v5 Addons) not in /FSUIPC6?
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:
QuoteIgnoreThese: This can be used to list a number of buttons which are to be ignored by FSUIPC in the Buttons &
Switches tab. This is to deal with faulty button signals which are repeating without control and thus preventing the
others from being registered on the screen ready to program. The parameter takes this form:
IgnoreThese= j.b, j.b, ...
listing the joystick number (j) and button number (b) of each button to be ignored. To make it easy, you can edit the INI
file whilst in the Button assignments dialogue and simply press “reload all buttons” to activate the changes.
Note that the action of ignoring buttons only applies to those numbered 0–31 on each possible joystick (not any “POV”
hats), and they are only ignored in the dialogue—if they are already assigned the assignment will still be effective.
This parameter can also be used in the [Axes] section of the FSUIPC7.INI, using the axes letter instead of the button
number (see later)
-
Hi Keith,
21 minutes ago, Stinger2k3 said:The button is numbered M7 in FSUIPC7 but I cannot find which switch this relates to on my cockpit
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).
17 minutes ago, Stinger2k3 said:I did a buttons and keys console log but it does not show M7 operating in there ?
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:
Quote221000 9220 FirstButtonChange res=00000108 (0.1, 8 )
In that line, the 1 indicates the joystick id, and the 8 the button number.
-
1 minute ago, nantelp said:
If it is well simulated I should see a impact on the power with 100%, according to the manual I should loss about 10% . I will test this on my next flight.
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%.
-
1 minute ago, nantelp said:
Something I do not understand is, I can use the mouse to pull and push the cab heat. The mouse doesn't use an axis?
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.
-
Can you also check if you have any ant-virus software running that is maybe preventing the dll from being loaded?
Let me know how it goes when you install using the other (i.e. dll.xml) install method.I don't think activating SimConnect logging would help at the moment.
-
10 hours ago, mario.rosati@mclink.it said:
How can I install not as add-on ?
Its always installed as an add-on. However, there are two install methods - add-on.xml (the default) and via the dll.xml. To use the second method, just re-run the installer and de-select the 'add-on.xml' checkbox when choosing the items to install.
10 hours ago, mario.rosati@mclink.it said:where can I find my P3Dv5 loading logs to show you ?
I'll let you know shortly...
-
2 hours ago, mario.rosati@mclink.it said:
no file with this name is in Prepar3D v5 Add-on/FSUIPC6 folde
Ok, then FSUIPC isn't even starting.
2 hours ago, mario.rosati@mclink.it said:Could it be better to install not as add-on ?
You could try this. But I would like to know why its not loading it via the add-on.xml method. I''ll need to see your P3Dv5 loading logs...I'll get back to you on this.
-
1 hour ago, mario.rosati@mclink.it said:
P3D v5 doesn't work, it freezes immediately (before asking me to accept the add-on)
Do you have an FSUIPC6.log file (in your installation folder: C:\Users\Admin\Documents\Prepar3D v5 Add-ons\FSUIPC6)? If so, can you please show me that.
1 hour ago, mario.rosati@mclink.it said:Do I need to buy a new complete version?
No. Its the same version, you just get a discount as you have already purchased a license for FSUIPC5.
1 hour ago, mario.rosati@mclink.it said:In attache my .log file
That's your installation log which just shows a successful install.
You could also try re-installing the P3Dv5 client - no need to uninstall or re-install FSUIPC6.
John
-
There are no standard offsets for COM3 active/standby, but check the PMDG 777 SDK documentation to see if they hold the information there.
sim stops responding after 7 hours
in FSUIPC Support Pete Dowson Modules
Posted
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?