
John Dowson
-
Posts
13,242 -
Joined
-
Last visited
-
Days Won
270
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
3 minutes ago, kaha said:
Maybe there's a way to check if a specific input event is valid for the aircraft loaded?
No, but I could add such a function.
3 minutes ago, kaha said:The script does not end, so that's fine.
So there is no real issue - just ignore the message!
2 minutes ago, kaha said:Hmmm... I could read the .log file and parse the input events FSUIPC found.
Sounds like overkill - a lot of work for no real benefit.
-
@Reco I see you posted over on Avsim for the dodsim *.evt used in the P3D version. Does this also work in the FSX version?
If so, maybe you could attach it here for other dodsim users who come across this post.Cheers,
John
-
1 hour ago, kaha said:
I get errors logged if I send input events that are not subscribed. Here's an example:
646938 *** LUA Error: C:\FSUIPC7\l_kaha_lua.lua:706: Error sending Input Event 'AS530_COM_VLOC_Khz'
Does the lua continue or exit with that error?
1 hour ago, kaha said:Can I switch error logging off for this?
No.
1 hour ago, kaha said:Sometimes I send multipüle input events so it works for different aircraft.
Input Events, like lvars, are aircraft specific. However, input event names may be shared between aircraft (although they will be different Input Events, and maybe with different values.
1 hour ago, kaha said:Else I would need to have an if else construct which means I have to touch the Lua file for each new aircraft.
That is what you have to do... If you want to use the same script with multiple aircraft, different Input Events, then just check the aircraft name (offset 0x3D00) and then use/set the name of the appropriate Input Event to use. You can always have a default Input Event to use if the aircraft is not known by the lua script, but if that doesn't work then you would have to edit the lua to add another condition to set the Input Event name for the new aircraft.
Note I have had a severe crash on my development PC (after a Windows Insider Upgrade) and I currently have no access to the FSUIPC source or development environment. Therefore support will be limited for the next week or two while I rebuild my systems.
John
-
46 minutes ago, Dutch60 said:
5125 Failed on SimConnect_CallDispatch for Message, return = 0xC000014B
5125 Failed on SimConnect_CallDispatch for Traffic Message, return = 0xC000014B
5578 MSFS no longer running - trying to find...These errors are due to the fact that MSFS has crashed and is no longer available.
As I keep telling you, there is nothing wrong with FSUIPC7. This needs to be fixed by Asobo.
-
You could maybe try removing the FSUIPC WASM from your community folder. You won't have access to lvars or presets, but that would test if its the WASM thats the issue, not FSUIPC7 itself. There was a report/comment on that link I posted that said this fixed the issue.
-
7 minutes ago, Dutch60 said:
so please take the time to fix it.
There is nothing wrong with FSUIPC and there is no fix, unless SimConnect is no longer backwards-compatible (which I very much doubt!). This needs to be fixed by Asobo.
This has happened on previously beta releases and is usually fixed in a subsequent beta update.
As I said, there is no way I can fix or investigate a sim CTD, only report this to Asobo.
-
...and are you sure this is related to FSUIPC7? i.e. does it run normally without FSUIPC7 running?
There are lots of reports of CTDs in this beta version - see https://forums.flightsimulator.com/t/ctd-loading-into-1-5-10-0/727551And I cannot investigate MSFS crashes - you need to report to Asobo.
Even if the SimConnect API has changed, it should be backwards-compatible, so I am confident, even if this issue is provoked by FSUIPC7, it is an issue for Asobo and must be fixed by them.John
-
As this is in the beta, you should wait for a fix in the beta. FSUIPC7 is an external app and in no way should it crash the FS.
Maybe check the Asobo beta forums to see if anything has been reported there regarding simconnect apps.
I have had a severe crash on my development PC during a windows update and cannot look into anything at the moment until I have repaired this.
John
-
As long as windows recognises the card as an HID joystick type device, and revognises the buttons, then FSUIPC will see them.
I have no direct experience with such cards, but many people use them with FSUIPC so I don't think it will be an issue.John
-
13 hours ago, DaveSCUSA said:
I can't find the discussion in the Advanced Users. Could you please provide a step-by-step or at least a page number.
Its in the Using Lvars section - see page 48, under Logging Lvar Updates.
John
-
5 hours ago, daniellljose said:
I have gone through the offset documentation..., but I am either missing something or not applying it correctly
For controls, you should start with the standard controls, not offsets. For example, the standard control for AP altitude hold would be the AP Alt Hold control (65726).
Note that the standard way to determine what control to use is for any button or switch to set logging for Events (Log->Events), open the logging console (Log->Open Console) and then toggle/set the switch in the virtual cockpit and see what is logged. If anything is logged, use that.Note that many MSFS aircraft continually emit certain events, and these are different for each aircraft. These can make using the log difficult, so best to ignore these by setting the DontLogThese ini parameter (see the Advanced User guide for details).
Many MSFS aircraft, especially third party/add-ons, do not use the standard controls/events. For such aircraft, check to see if an MF preset is available - you can use the search interface on the MF HubHop site: https://hubhop.mobiflight.com/presets/. All MF presets should be available for use in FSUIPC7.
Some aircraft also use their own custom controls (e.g. PMDG, FSLabs, etc). For such aircraft, check the documentation - and there is a FAQ entry on using custom controls with PMDG aircraft.If there are no standard events, presets or custom controls that work, you can look at the available lvars or preset events, or examine the switch/button behavior to see what it is using - see the following article: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/
If you require any further help, please let me know the aircraft you are using.
John
-
Listing lvars shows the currently held value by FSUIPC, which is a max of 166ms or so out of date (using the default update rate of 6Hz).
There is already a facility to log lvar updates, either to the log or a separate ext window. This is done via an ini file section (at the moment) - see the Advanced User guide.
John
-
There may be an lvar that you could use - try listing them to see if any look applicable.
John
-
Just received further information: if you press tab to check and nothing happens, this means the mouse macro facility can't be used.
The whole thing about mouse macros is that it’s all a code hack, especially in FSX, and some parts of the FS code just aren’t constructed in the manner where they do work. The test offered at the creation phase is to check that, and if it doesn’t work other methods have to be used to action the function desired as mouse macros won't work.
A lot of later add-ons did not use the original library-provided methods for implementing their controls. And that is where the problems are, and there is nothing that can be done in FSUIPC to get around this
John
-
15 hours ago, Reco said:
I have include images of what I get when I press the Wrn mute button and dir gyro toggle
No point attaching images - they don't tell me anything that you have not already told me.
15 hours ago, Reco said:I had a read through the documentation on Macros and when I press the tab to check if the macro is working nothing happens.
Did you try my recommendations? Maybe also leave the Module line in as it looks like this is needed (although I have never seen this before!).
I have never seen parameters 23 and 24 used before - I though these should be in the 1-17 range, as the documentation states.
But if it doesn't work, there is not much I can do about this. FSUIPC4 has been closed for further development for many years. And I don't have much experience with FSX and certainly don't have the dodosims 206, which also doesn't seem to be available anywhere either.
My PC has also now died after the latest windows (insider) update, so cannot do anything at the moment or until I have sorted this out...
Sorry I can't be of more assistance.
John
-
The log you attached shows that FSUIPC7 did not connect, and was still running when you attached the log file. Please ALWAYS exit FSUIPC before attaching files.
And please leave FSUIPC7 running at least until MSFS arrives at the main menu.
Your issue is almost certainly due to the auto-start parameters not being tuned correctly. I cannot advise what to use with that log file you attached for the reasons already stated. Try tuning the auto-start parameters yourself (see the documentation or that FAQ entry I referenced) or provide me with a better log file and I can advise what to try.
Also check your EXE.xml (location is logged in the InstallFSUIPC7.log file if you don't know where that is. If there are multiple entries for other apps, then you can also try making sure FSUIPC7 is started first. You can also attach this and I can take a look.
John
-
The logging I requested would just confirm that the auto-brake threshold wasn't being used, but I think that was added in a later version of FSUIPC 7 than the one you are using anyway. You should update to the latest version of FSUIPC7.
John
-
Did you not read my previous comment:
1 hour ago, John Dowson said:Looks like you are using the PM 737. The brake release threshold is only applicable to airbuses, as these are the only aircraft that use this brake release mechanism (although I see in the documentation that this is omitted!).
You are not using an airbus, so this parameter has no effect. If you want to mimic this in airliners, then you would need to use a lua script.
Note that you are using a very old version of FSUIPC - 7.4.17. I only support the latest release, which is 7.5.3. Please update if you require further support:
Quote********* FSUIPC7, Version 7.4.17 (4th September 2024) by John Dowson *********
**** New version available: version 7.5.3 is available ****
43 minutes ago, chasbruce said:opened fsuipc and set the 3 log flags, loaded MSFS
You need to set the logging flags then exit FSUIPC and let MSFS auto-start it, as then I can see/check the logging.
John
-
Looks like you are using the PM 737. The brake release threshold is only applicable to airbuses, as these are the only aircraft that use this brake release mechanism (although I see in the documentation that this is omitted!).
Try setting the logging for Extras before the aircraft is loaded - this should then log a message indicating if the brake release threshold is applied or reset.
John
-
10 minutes ago, bobsk8 said:
I forgot that I use FSUIPC to set a couple of controls to TrackIR from my joystick, and that's what doesn't work, not track IR itself.
Ok, that makes more sense then, and it will be because FSUIPC is not connecting to the FS. The log file should reveal why.
John
-
On 6/21/2025 at 7:20 AM, JelleFS said:
Since yesterday my ACARS system Pegasus is not working anymore.
What has changed?
Can you show me / attach your FSUIPC5.log file showing this issue.
If there are any log files from Pegasus, please also attach them.John
-
18 hours ago, bobsk8 said:
This issue just started a few weeks ago.
Did anything change to cause this issue? If it was an FSUIPC update, and you were previously using was pre 7.5.0, then it could possibly be due to the late population of offset 0x3308 that was introduced in v7.5.0, which is needed for compatibility with MSFS2024. If that is the issue, you can use/add the ini parameter Init3308 in the [General] section of your FSUIPC7.ini file to to 13, eg.
Init3308=13Otherwise, this is usually due to the auto-start parameters that need tuning. This is described in the Advanced User guide, or in the following FAQ entry:
If you can show me/ attach your FSUIPC.log file when FSUIPC7 is auto-started and your clients won't connect I can take a look.
Btw, I don't think Track IR needs or uses FSUIPC these days (if it ever did), although I don't have this for MSFS2020.
John
-
1 hour ago, Reco said:
The 23 was at the end of the RX746f0*X55cc. So didn't edit the file
That is strange - I don't know how that could get there...
What are the mouse operations that you need? Was it a middle-single (2) click together (or followed by) with a left single click (3)?
Even then, that should be:[Macros] 1=Warning mute 1.1=RX746f0*X55cc,2 1.2=RX746f0*X55cc,3 2=DIR GYRO 2.1=RX79ee0*X55c3,2 2.2=RX79ee0*X55c3,3
1 hour ago, Reco said:I am using the 2d panel when I run the macro
They will only work in whatever view they were created in (otherwise the mouse-rectangle will not be available).
1 hour ago, Reco said:I will report back tomorrow to let you know how I get on.
Ok. Cheers,
John
-
What aircraft are you using? Can you please set logging for axes controls (Log->Axes Controls), Events (Log->Events) and Extras (Log->Extras) and show me/attach your FSUIPC7.log file showing the issue. Try and keep the session as showrt as possible - just load the aircraft, replicate the issue, then exit FSUIPC7 before attaching the file.
John
LUA Error in log file - can it be switched off?
in FSUIPC7 MSFS
Posted
Ok, but this may take a while...I have other series issues I need to look into, besides rebuilding my PC, before I can look into any further changes to FSUIPC7.
John