John Dowson
-
Posts
13,544 -
Joined
-
Last visited
-
Days Won
283
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
This is an FSUIPC issue. Successive axis control events that are masked (i.e. can be calibrated in FSUIPC) using the same parameter are currently ignored. I am not sure why this is (probably for performance issues with some devices), but I have removed this in the attached version. So please try the attached version, 7.5.5e.
John
-
8 hours ago, Tutmeister said:
I have tested with multiple aircraft (PMDG 737, 777, default 747, multiple GA propellor aircraft) in msfs2020 and 2024 and even simplified the testing by setting up 2 buttons, one sets the throttle to a specific parameter (2000) and the other sets throttle cut. If you cycle between these 2 then the throttle should move from idle to 2000 and then back to idle. After pressing throttle cut you cannot use the throttle set again without cycling the axis lever.
I know this is quite a specific problem but does anyone know why this might be? It is needed for a very specific hardware setup I have. Could someone verify by using 2 buttons to switch back and forth between throttle cut and a set value?
I have looked into this and can confirm this issue. It looks to be an issue with MSFS, but I will investigate further and report back, and will also raise an issue with Asobo.
However, there is a workaround - you can use presets instead. I have tested this in a few aircraft and it works with presets - I have only tested in MSFS2020 but should also work in MSFS2024. Define two presets in your myevents.txt file (create this file if you do not have one):
Quote//General
Throttle_Set#$Param (>K:THROTTLE_SET)
Throttle_Cut#(>K:THROTTLE_CUT)Then assign to these, giving the required parameter to the Throttle Set preset.
Note that I have moved your post to the FSUIPC7 / MSFS subforum.
John
-
Those files make no sense. Both are from MSFS2020, and the FSUIPC7.log was attached when FSUIPC7 was still running.
Your ini file shows that you have no assignments at all, just some strange calibration entries:QuoteThrottle1=0,0,0,0
Throttle=-8859,3914You should delete those and try again. Both log files also show strange device scanning activity.
What are you trying to do with FSUIPC? As I asked before, if using both MSFS2020 and MSFS2024, are you using the same FSUIPC7 installation for both, or distinct installations? Why are you calibrating in FSUIPC but not assigning? This can work in many aircraft, but not recommended for any advanced aircraft.
-
47 minutes ago, kaha said:
John, this one gets deleted by Defender.
This happens due to a Windows virus definition update causing a false positive, and its continually happening. It happened in an update a few days ago, but another definition update the same day fixed the issue. If they don't update to fix this in a day or two, I report it and it tends to get fixed in a subsequent update a day or 2 later.
I have just checked and I also now get that here - and there have been 2 updates today. You can use the attached, which isn't compressed (its the compression of the exe that seems to trigger this): FSUIPC7.exe
If this isn't fixed by Microsoft in a day or two I will report (again).
John
-
These crashes were related to the logging of the parameter type for input events. According to the documentation, this can be either Float64 or String, but, as far as I know, only Float64 types have currently been implemented/are available. I request the parameter types for all input events received, but it looks like I am only getting a response for some of these, leaving the other unitialised. It is these uninitialised ones thar are causing a memory error/exception due to a buffer overrun.
I have corrected this in the attached (by setting the default parameter type to 'Unknown'). As the parameter type is also not really useful for end users (it is always a number!), I have removed the logging for this, unless you have set logging for Extras or Input Events.
Please find the updated version attached.
Regards,
John
-
Could you please post in the FSUIPC7 sub-forum for all issues and questions regarding FSUIPC7 for MSFS2020 and MSFS2024. I have moved your post.
Are you using the same FSUIPC7 installation for both MSFS2020 and MSFS2024 or separate installations? If using the same installation, I can't see how the calibration values can be different in the same profile. Your calibrated values are also very strange - why do you have such a low upper value set (3312 / 3931)? The lower value is also quite high in the second screenshot.
Can you show me / attach your FSUIPC7.ini file please, and your FSUIPC7.log files from MSFS2024 and MSFS2020 (if you run one then the other, you can then attach the FSUIPC7.log and the FSUIPC7_prev.log).
-
The FSUIPC WASM crash is a known and ongoing issue and has been reported many times, and also seems to be more common in MSFS2024. This is related to the scanning for the new lvars which must be disabled - see the following FAQ entry:
I have previously looked into this in detail and there are no memory issues in the WASM itself and I am at a loss as to what is causing this. I have also reported to Asobo but have received no response. However, I haven't checked this for quite a while now, and will look into it again at some point (when time permits).
If the current crash you are reporting is not related to the scanning for lvars, I will need to see your FSUIPC_WASM.log file, with Debug level logging enabled in the WASM. For all WASM crash reports you should attach this file. Note that, as a new forum member, your attachment limit will be very low. You should compress/zip the file, but if it is too large to attach you can deliver it via one of the free file transfer websites (e.g. https://filetransfer.io/)
John
-
I'm not sure why its using 3 hex digits instead of 6, but try this: https://borderleft.com/toolbox/hex/
John
-
Ah, I see the documentation says 3 hexadecimal digits (not bytes). I will check this...
-
This has previously been reported see here:
I have reported this to Asobo. https://devsupport.flightsimulator.com/t/cannot-receive-function-keys-f13-f22/13023
There isn't anything I can do about this I'm afraid - it needs to be fixed by Asobo.
John
-
They should be standard hex colour codes.N.B. 3 byes are 6 hex digits.
-
1 hour ago, imperial321 said:
Can FSUIPC use H events and if so how can I assign buttons etc
Do you mean Hvars? And if so why is the title of this topic 'Lvars'? K-type variables are events, B-type Input Events, etc.
You can use both H (HTML) and L (local) type vars in FSUIPC7, either directly or using presets / calculator code.
The easiest way to use hvars is via calculator code really. There is no actual way to discover the available hvars for the loaded aircraft, as there is with lvars, so the way this works in FSUIPC7 is that you have to let FSUIPC7 know which hvars you want to use by providing a *.hvar file (some are included as an example). This is documented in the Advanced User guide, under the WASM section. Once a hvar is known to FSUIPC7, you can use it either in a macro or a lua script.But these days almost everybody uses hvars via presets (calculator code). You can define your own preset to trigger a hvar: in the myevents.txt file, e.g.
Trigger_My_Hvar#(>H:hvarName)
Then assigning to the preset 'Trigger My Hvar' would trigger/set the hvar ' H:hvarName'.See the documentation for further information. Also take a look at the available presets in the events.txt file as many of these will use hvars. You can find available presets by pressing the Find Preset button in the assignments windows once Select for Preset is selected/checked.
John
-
1
-
-
@DaveSCUSA Also, to get an event notification on a restart, you can use the event.sim function - you will get a FLIGHTLOAD event notification followed by an AIRCRAFTCHANGE event notification on a restart, the same as when you initially start a flight.
-
9 minutes ago, Kimchi said:
Would it be possible to create a "mode" button?
Mode button = button 10
Button 1 = function A
Mode button (10) + button 1 = function B
You do this by using 'compound conditions'. See the Advanced User guide, page 22.
QuoteCOMPOUND BUTTON CONDITIONS
Facilities are included to allow you to specify actions for one button which are dependent on the state of another button (or more likely, switch). This by using what I call “Compound” button programming—though it could equally be “Conditional” or “Co-operative”...
John
-
1 hour ago, DaveSCUSA said:
Obviously in a while ... do ... end until on the ground.
Why don't you just keep the lua running until you go back to the main menu? Do you really need to stop/exit this and then restart?
As I said, you can also use offset 0x026D to determine the camera state, with values:
Quote2 = Cockpit
3 = External/Chase
4 = Drone
5 = Fixed on Plane
6 = Environment
7 = Six DoF
8 = Gameplay
9 = Showcase
10 = Drone Aircraft
11 = Waiting
12 = World Map
13 = Hangar RTC
14 = Hangar Custom
15 = Menu RTC
16 = In-Game RTC
17 = Replay
19 = Drone Top-Down
21 = Hangar
24 = Ground
25 = Follow Traffic AircraftNote that not ALL possible enum values are shown, since some values are internal only, and some values will do nothing, but have been reserved for future expansion of the camera system.
1 hour ago, DaveSCUSA said:I just can't figure out how to reenter the loop. Must I put it inside a function?
If the lua has terminated, it needs to be restarted. You can also just start/restart it on a button press (or from another lua) and if its currently running it will be killed.
How is this lua started? Maybe you can also attach this lua script so I can take a look.
-
11 minutes ago, kaha said:
I understand. But I'm not pressing any buttons before the flight is loaded. Maybe some USB devices send some button states anyway?
Maybe - could be due to the initial button state scan...
12 minutes ago, kaha said:This never happened before 7.5.5d September 7th.
Then I think this is because of the change I made to allow repeated LuaValue calls with the same parameter - but I'm not sure how this change could cause this error!
I have disabled Button actions before everything is initialized in the attached version.John
-
This looks to be because you are pressing a button that starts a lua thread far too early - well before the aircraft is loaded and before FSUIPC is fully initialized. This looks to be confusing SimConnect and interfering with the initialization. You should really not be doing anything until AFTER you have pressed the Ready-to-Fly button.
I also don't think this is related to any of the recent changes.
FSUIPC should really ignore such early button presses. Not sure why it is actioning those button presses when they should be ignored. I will take a look to see if I can prevent this.
But you should wait until the aircraft is fully loaded and after you have pressed the ready-to-fly button before doing anything, and really it is better to wait until all lvars have loaded, which will be several seconds after you the cockpit view is loaded.John
-
39 minutes ago, kaha said:
I used my normal camera views that I always use. Nothing special.
The camera state is not just the views, it is what is displayed in the MSFS main window, so can be Menu, World Map, Hanger, Waiting, etc As I said, 32 is undocumented (internal only) so just wondered why it hit that state when you were (probably) in a cockpit view (state 2). Its not important - just wondered if you had noticed anything in MSFS, apart from FSUIPC becoming unresponsive (as it was killing the luas).
-
6 minutes ago, kaha said:
I didn't do anything wired when this happened. I'll try to reproduce.
Just wondered what you saw when the camera state when to 32. Anyway, I have removed this now in that last exe.
There is another camera state of 36 that will also cause luas to be killed which might also need removing. As I said, I will do some testing later today - I haven't looked at this since the latest SU update and these things tend to change on each release...John
-
Check you are looking in the correct place - use the File->Open Installation Folder in FSUIPC.
Also check that you have not set windows Explorer to 'Hide extensions of known file types'. If you don't know what this means, see the Addendum in the Installation and Registration guide (last page).John
-
12 minutes ago, kaha said:
I was about to test the C-130 Beta by Blackbird
The aircraft name logged was "Dirty 30 Short Configuration" which seems very strange...
14 minutes ago, kaha said:FSUIPC suddenly got unresponsive for some time. It didn't crash, but after it responded again some inputs didn't work. Looking at the log it turned out that it had terminated my autostarted scripts. Buttons again worked. This happened at 348594 in the log file.
What actually happened in MSFS at this time? Your log indicates that FSUIPC killed the lua scripts as the camera state changed to 32 (which is an undocumented/internal camera state).
In MSFS2020, the 'plane in parking state' variab1e is used to determine when a flight is ended and luas need to be killed (as well as performing other tasks needed when an flight is ended). But this is not reliable in MSFS2024, and so an additional check on the camera state was added specifically for MSFS2024, and when certain camera states are received, FSUIPC thinks the flight is ended and will stop the luas. The camera state values were determined by trial and error, and 32 was one of these (even though the exact meaning of this state is unknown). I will do some more tests on this, but I will remove 32 from the list that determine a flight has ended. I have done this in the attached version.
John
-
Stick woth writing to the offset and using event.offset.Thats the standard way to use axes values in a lua script.
-
The only anomaly in that log is when trying to set/execute an input event that doesn't exist:
Quote...
92563 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
92563 **** Cannot execute empty Input Event
...
1148578 Button changed: bRef=0, Joy=5 (P), Btn=0, Released
1148578 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
1148578 **** Cannot execute empty Input Event
...
1318375 Button changed: bRef=0, Joy=5 (P), Btn=0, Pressed
1318375 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
1318375 **** Cannot execute empty Input Event
...
7838813 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
7838813 **** Cannot execute empty Input Event
7839219 Button changed: bRef=0, Joy=5 (P), Btn=0, Pressed
7839219 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
7839219 **** Cannot execute empty Input Event
7839625 Button changed: bRef=0, Joy=5 (P), Btn=0, Released
7839625 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
7839625 **** Cannot execute empty Input Event
... -
1 minute ago, kaha said:
In the meantime I autostart the script and use "CL16:R". Should still be better than not autostarting the script?
Thee is no point auto-starting the script if its not waiting for an event - it will just run and exit, and maybe adjust the trim when not needed.
But please try the attached version. As well as the logging issue (hopefully) being fixed, this should allow repeated LuaValue calls using the same value.
John
Problem using throttle set values
in FSUIPC7 MSFS
Posted
Yes, this will be included as default in the next release, hopefully mid-October or before.
As the code that caused this must be for some reason (but well before my time and difficult to deduce why), I tthink I will also add an ini parameter that, when set, will revert to previous behavior.
Please also let me know about your product. I am currently working on a new FSUIPC website and support forums (as these will be closing soon). I would like to add a page, with links, to all software that uses/relies/depends on FSUIPC, but that will come post-launch.
Cheers,
John