John Dowson
-
Posts
13,546 -
Joined
-
Last visited
-
Days Won
283
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
Btw, the calc code for FNX320_APU_START_SWITCH is:
(L:S_OH_ELEC_APU_START) 2 + (>L:S_OH_ELEC_APU_START)i.e. it is incrementing the lvar by 2, not 1. So maybe try:
- Toggle APU Start Button
local val = ipc.readLvar("S_OH_ELEC_APU_START")if val == 0 then
ipc.writeLvar("S_OH_ELEC_APU_START", 2)
else
ipc.writeLvar("S_OH_ELEC_APU_START", 0)
endThe calc code for the press/release presets looks rather strange to me, as it seems to be sending two values to the lvar, which I didn't think possible:
push: 1 (L:S_OH_ELEC_APU_START) ++ (>L:S_OH_ELEC_APU_START)
release: 0 (L:S_OH_ELEC_APU_START) ++ (>L:S_OH_ELEC_APU_START)
If the presets are not working, you can ask about this on the MF support discord server (MSFS2020 channel).John
-
16 minutes ago, Jacques Balayla said:
Do you have the APU Start Button Push and APU Start Button Release l:var functions for the fenix?
They are MF presets, and there is also FNX320_APU_START_SWITCH.
You can assign to presets directly (check the select fir Preset checkbox), or in lua you can use ipc.execPreset function.I don't have the fenix to check these.
John
-
Does the lvar change values? Ifthe script is sunning as expected and the lvar is changing values, then you need something more than just to set that lvar.
Why not try the presets instead: APU Start Button Push and APU Start Button ReleaseUse logging to see if the script is running and the lvar is being updated: set logging for Lua Plugins and WAPI debug level logging.
-
21 minutes ago, John Fee said:
The FSUIPC6.dll, .ini, .Joyscan.csv, .key, .log and _prev.log are installed singly in the P3Dv5 main folder.
In an attempt to correct things I created a Modules folder containing those files in the main P3Dv5 folder. This didn't work either.
Your FSUPC6 installation is here:
QuoteReading options from "G:\Lockheed Martin\P3Dv5\FSUIPC6.ini"
So all FSUIPC related files should be under that folder. However, you should NOT use the P3D installation folder. If yuo have installed there, then uninstall and re-install in a different (non windows-protected) folder. Don't foget to copy/move your FSUIPC6.ini and FSUIPC6.key files across to the new location to preserve your settings and registration, as well as any other files (*.lua, *.dll) that you are using.
24 minutes ago, John Fee said:For some reason the axis assignments are lost between sessions. I tried 'Reloading all Assignments' without success.
Are the button assignments working? If the ini file you attached is the one being read, I cannot see how just the axis assignments are lost.
Can you set logging for Axes Controls and show me another log file, if you get the same issue after re-installation. Note that you should also always exit P3D/FSUIPC before attaching log files - the one you attached shows that FSUIPC was still running.Are you sure that this is not because the system is paused? There are a few messages indicating that the sim pause is turned on, but non indicating that it was turned off:
Quote61125 ### Mode: PAUSE on
...
1124656 ### Mode: PAUSE on
Note that you also have controllers turned on in P3D:
Quote328 Controllers are set to ON, using RawInput within P3D
when assigning in FSUIPC, best to turn off controllers in P3D. If controllers are on, make sure that any axes/button that is assigned in FSUIPC is not assigne in P3D. And be-aware that sometimes P3D can automatically re-assign a button or axis, so you may need to check regulary if you get issues.
John
-
Is APLv2 using offset 0x0BCC to detect if the spoilers are armed or not? Can you try logging that offset (Log->Offsets. as U32) to see if the value in that offset changes to 1 when armed.
If not, then that will be the issue. You would need to determine what is holding the spoilers armed state if it is not the simvar SPOILERS ARMED, and add that to a spare offset and then spoof the reading from offset 0x0BCC to the new offset. I can help with this if needed.First, log offset 0x0BCC and see if it changes or not. If it changes, then you need to contact support for APL.
If it doesn't, then look at the available lvars to see if any of them look appropriate (Add-ons->WASM->List Lvars), and if so check the value (i.e. arm/disarm and see if the value changes)
If you find an lvar that holds this state, you can then add that to a spare/free FSUIPC offset - to do this, see the Advanced User guide, section Adding Lvars to Offsets on page 47.
Once it is in an offset, you can then write a lua script (which should be auto-ran in your MD-11 profile) to spoof offset 0x0BCC to the one holding the actual armed value, via writing to offset 0x0024, There is a sample script provided that shows how to do this (liar.lua), which you can use and modify for your own needs.John
-
12 hours ago, John Fee said:
If anyone wants to use P3Dv5 or P3Dv4 with Sky Demon in a LAN I would be happy to post details under User Contributions. I did this some years ago for FSX-SE.
Yes, please create a User Contribution for this - I think that would be useful!
John
-
15 hours ago, AlMassimo said:
Looking for a better Autobrake knob handling (apparently PMDG provided controls only for decreasing and increasing, not to set a value from a rotary switch)
I found that some events are available and they work very fine, thanks to a post on avsim of Lorby_SI"If you want to set the auto brake selector to specific positions, use the PDMG SDK Events instead. In this case #70092: EVT_MPM_AUTOBRAKE_SELECTOR. Values 0-5 will set the selector to the desired position. You can do that directly on the button assignment, by assigning #70092 as the Key Down event and then dialling in the number that you want to send to it in the value box to the right. Or use a script "n (>K:#70092)" n is the number to send, 0-5"
So I configured MF to send an FSUIPC event 70092 with the parameter 0, 1, 2, ... 5 for each AB level, and that worked perfectly.
I can't find were these events are located and what means the address 70092. Maybe you can understand what is.
Probably there are many other events not available among HubHop presets. They should be located under PMDG 737 sdk somewhere. I found some, but not the address 70092.There are two methods to use the PMDG custom controls: one is via the Rotor Brake Control, and the 2nd method is to use the custom control number. EVT_MPM_AUTOBRAKE_SELECTOR is defined in the PMDG SDK header file PMDG_NG3_SDK.h:
Quote#define EVT_MPM_AUTOBRAKE_SELECTOR (THIRD_PARTY_EVENT_ID_MIN + 460)
So the custom control number would be 69632 + 460 = 70092. For the values the control takes, you need to see what the associated variables holds:
Quoteunsigned char MAIN_AutobrakeSelector; // 0: RTO 1: OFF ... 5: MAX
Generally you would use custom controls via the Rotor Brake method to emulate mouse clicks, and the custom control methos can send actual values (as well as emulate mouse clicks).
See the followinf FAQ entries on using both methods, and on how to determine the control number/parameter to use"
Note that there also special offsets for PMDG aircraft, so, for example, the current value of MAIN_AutobrakeSelector would be held in offset 0x6607 (if/when PMDG offsets are enabled and data broadcasting has been activated):Quote6607 1 BYTE MAIN_AutobrakeSelector 0: RTO 1: OFF ... 5: MAX John
-
15 minutes ago, kaha said:
From the FSUIPC manual I learned that I need to have a file named myOffsets.txt. This is my try:
// offset, size, simvar, type, units [, w] 0x66C0, 4, object_class, S16, NumberTwo things wrong here:
- there is no such type as S16 - use S32. And 4 bytes is too small - that should probably be 16
- the simvar name is AIRCRAFT OBJECT CLASS, not object_class22 minutes ago, kaha said:I found a simvar CATEGORY
https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Miscellaneous_Variables.htm
If I use that one there are no errors in the console but the string is empty.
Ah, missed that one, and that one is better as it also exists in MSFS2020.
Just tried this in both MSFS2020 and MSFS2024 with the following entry in the myOffsets.txt file:Quote// offset, size, simvar, type, units [, w]
0x66C0, 16, CATEGORY, S32, Numberand this seems to work in both MSFS2020 and MSFS2024:
Quote15344 WAPI enabled
15344 Initialising SimConnect data requests now
15360 Adding simvar 'CATEGORY' to offset 66C0 (size 16, type 'S32') for read-only access
...
17657 Monitor IPC:66C0 (AsciiZ) = [8]"Airplane"
17657 SimRead: 66C0="CATEGORY"
STR32: "Airplane"
19875 Aircraft="Cessna Skyhawk Asobo"
...Quote47547 WAPI enabled
47562 Generating controls file list: 'C:\Users\jldow\OneDrive\Documents\FSUIPC7\Controls List for MSFS Build 121.txt'
47609 Initialising SimConnect data requests now
...
77484 Monitor IPC:66C0 (AsciiZ) = [10]"Helicopter"
77484 SimRead: 66C0="CATEGORY"
STR32: "Helicopter"
79687 Aircraft="Bell 407"
John
-
2 hours ago, AlMassimo said:
By the way I wonder what happens if I delete "events.txt" and use the content of myevents.txt renaming it to events.txt ?
Probably if I call events.txt the only issue is that it will be overwritten by newer events.txt whil myevents.txt is more "safe".
Is this the only difference? (Just to understand).You could do that, but that is an issue - you would have to remember to not install that file each time you updated. I don't see any advatantage in doing this.
Really I should process the myevents.txt file first, so the control numbers for the presets always start from that file. I could change this in the next release I guess, as anyone who is using the control numbers for presets is most probably not using the events.txt file for this reason.12 hours ago, AlMassimo said:I tested the updated Fsuipc7.exe with the previous SIOC code (that changed the parameter and sent the rotor_brake command via 3110
but the former control was sent as before, so I switched to the SIOC code with myevents.txt removing the events.txt file (renaming).I think this is because you are writing the parameter AFTER the control number to offset 0x3110. As I said, you should write the parameter first, then write the control number to offst 0x3110 after the parameter has been written.
The change in that version was to allow the same control number written to 0x3110 to still trigger the events. I will do some more testing on this next week,12 hours ago, AlMassimo said:And... VOILA', everything worked perfectly. All 3 encoders, speed, hdg and Alt sent the correct "myevent" with 1 as param and,
as I (greatly) hoped the event is triggered properly and very quickly.Well, that is surprising as the preset/calc code should be the same as sending the Rotor Brake control. I will also test this next week.
12 hours ago, AlMassimo said:So probably the issue was only when a different parameter is sent from SIOC to the same control via 0x3110,
while changing the control sent there are no issues (the parameter is always 1 but I think that even changing it would have no issues
since the control is different)Yes - this is what hat patched version was supposed to address, so I am not sure why it isn't working.
I will get back to you sometime next week when I have had time to test a bit more.
John
-
Maybe better to send a fixed number of events on a short press rather than using the time, where the number of events could vary. To do this, use a counter instead of elapsed time: initialse the counter to zero before the loop, increment the counter in the loop and the loop condition should exit when the flag is cleared and the counter is above the minimum needed.
-
Here's an updated script with that added:
local trimUpControl = 65615 local trimDownControl = 65607 function trimControl(flag) startTime = ipc.elapsedtime() nowTime = startTime if flag == 0 then -- trim up while ipc.testFlag(0) or nowTime - startTime < 100 do ipc.control(trimUpControl) nowTime = ipc.elapsedtime() end elseif flag == 1 then -- trim down while ipc.testFlag(1) or nowTime - startTime < 100 do ipc.control(trimDownControl) nowTime = ipc.elapsedtime() end end end event.flag(0, "trimControl") -- trim up event.flag(1, "trimControl") -- trim down ipc.log("*** lua elevator Trim (repeat) script now running") -
Just now, kaha said:
So the button release:
release to 'LuaClear <luaScriptName>' with parameter 0
doesn't immediately quit the script?
Yes - and I corrected my previous post.
-
2 hours ago, kaha said:
I want to implement that the script sends the control continuously for at least 100 milliseconds (or some adjustable value), even if I let go of the button. With your example the script will end as soon as I release the button, though.
Use the ipc.elapsedtime function just before the loop starts (startTime) , and again after the control has been sent (nowTime). Then change the condition in the while loop to only exit the loop when the flag is not set or the difference between the two times is > 100 (i.e. ipc.testFlag(1) or nowTime - startTime < 100).
-
29 minutes ago, John Dowson said:
Why are you testing/checking the aircraft name - are you running the script for all aircraft? Much better to just have the lua script auto-started in a profile for the aircraft that need it.
Note also that all auto-ran lua scripts are killed and restarted when you go back to the main menu. If you are having the script auto-ran from the general [Auto] section (as opposed to a profile [Auto.xxx] section, you can just exit the script if you don't want to use it with the loaded aircraft, as this would save resources.
I would not recommend changing aircraft without going back to the main menu (e.g. via devmode aircraft selector or other means) as this method is not fully supported by FSUIPC.John
-
18 minutes ago, kaha said:
I will also take a look at yours.
The script I provided will be a lot more efficient as there is no timer running and it just re-acts to the flag-change events.
Why are you testing/checking the aircraft name - are you running the script for all aircraft? Much better to just have the lua script auto-started in a profile for the aircraft that need it.
John
-
1 hour ago, kaha said:
I'll let you know about the Lua script.
Try the following:
local trimUpControl = 65615 local trimDownControl = 65607 function trimControl(flag) if flag == 0 then -- trim up while ipc.testFlag(0) do ipc.control(trimUpControl) end elseif flag == 1 then -- trim down while ipc.testFlag(1) do ipc.control(trimDownControl) end end end event.flag(0, "trimControl") -- trim up event.flag(1, "trimControl") -- trim down ipc.log("*** lua elevator Trim (repeat) script now running")Have that script auto-ran via your profile [Auto.xxx] section, then assign your trim buttons to:
trim Up: press to 'LuaSet <luaScriptName>' with parameter 0, release to 'LuaClear <luaScriptName>' with parameter 0
trim Down: press to 'LuaSet <luaScriptName>' with parameter 1, release to 'LuaClear <luaScriptName>' with parameter 1if its too fast, add an ipc.sleep(n) (where n is the number of ms to sleep, start with 10 and adjust as needed) after the ipc.control calls.
John
-
First, you posted in the main support forum - please use the FSUIPC7 sub-forum for all issues/questions on using FSUIPC7 with MSFS2020/MSFS2024. I have moved your post.
12 hours ago, igorekDE said:I need help! In MSFS 2024, none of the aircraft presets are working.
Looking at your log file, this is because the WASM module is not installed:
Quote369703 *** FSUIPC WASM module not detected - not adding WASM menu
Presets, lvars. hvars and calculator code will not work without the WASM.
So please re-install and make sure the WASM is installed. If there are issues instaling the WASM, please show me / attach your InstallFSUIPC7.log file.Your log file also showa connection issue with quite a few connection attempts. You manually started FSUIPC7 before starting MSFS. If manually starting FSUIPC7, then it is always better to do this after FSUIPC has started. If you wnt to start FSUIPC7 before MSFS, then you need to set the ini parameter DetectToConnectDelay to the same value as DetectToConnectDelayAuto to prevent too many connection attempts once MSFS has started. It is generally better to use the auto-start facility, but if starting FSUIPC7 manually then do this once MSFS has started and arrived at the main menu (or adjust that parameter appropriately).
John
-
30 minutes ago, John Dowson said:41 minutes ago, kaha said:
I will look into using a Lua script.
Ok, let me know how it goes or if you have any issues/further questions.
Thinking about this, it won't be that straight forward, as you need to repeat sending the control while the button is held down, and stop sending them when the button is released.
This can be tricky in lua. Off-hand, I can think of a couple of ways of doing this, but each may have issues and will need testing:1. Use event.button and have the script auto-run (in the profile). The event.button handling function should loop forever sending the control.
To stop the controls being sent, you need to assign the same button, but on release, to restart the lua script. This will then kill the existing script (and
end the forever loop) and restart it ready for the next button press.
The downside of this solution is that there may be a small delay after releasing before pressing will work again, as the script needs to be restarted (and recompiled first).
2. Again, have the script auto-ran (in the profile), but use event.flag instead, and assign the button press to LuaSet <luaScript> and the release to LuaClear <luaScript> (or maybe just both to LuaToggle), with the parameter for both being any flag number (0-255). In the event.flag handling function, you would either:
- start an event.timer, which would call a handing function at regular intervals which sends the appropriate inc/dec control
- cancel the existing timer using event.cancel.
The downside of this solution maybe the speed/throughput, which will need testing.Note also you could either use one script for both in/dec, or have separate scripts.
Let me know how it goes, I could maybe take a deeper look over the weekend (or next week) and see what works best, and provide you with a lua template script if needed.
John
-
The log file you attached shows that FSUIPC could not connect to MSFS. Nothing is going to work if it cannot connect.
Try tuning your start-up parameters (namely the DetectToConnectDelayAuto ini parameter which may need updating/increasing) - see the Asvanced User guide for details, or the following FAQ entry:7 minutes ago, Jermaine said:Specifically, the propeller is not feathering (both levers), even though they worked fine previously with my fsuipc settings.
But the ini file you attached shows you do not have any axes/levers assigned in the general section of FSUIPC - your [Axes] config section is empty. You only have 10 button assignments, to prop pitch, throttle and elevator trim. So the axes must be assigned in MSFS, so check there.
You also have one profile defined for the 'FSS Embraer E170 American', but this is empty (i.e. no assignments).
-
6 minutes ago, kaha said:
And reading from 0BC0 will not read the real trim but just what I wrote to it.
That is interesting, as this means that what you wrote to the offset was actually applied, as the read values are populated from what is received from the FS, not what is written (there are separate memory addresses for read and write).. Strange this has no effect then. Do you see the (read) values change in that offset when you actually change the trim?
7 minutes ago, kaha said:I will look into using a Lua script.
Ok, let me know how it goes or if you have any issues/further questions.
John
-
Setting the ButtonRepeat ini parameter will apply to all buttons, as you say.
If you want to change for a single button, you could try using a lua script (using event.button) instead of a direct assignment.
But if this is for trim, doesn't the standard method of setting up trim work? i.e. rather than sending more/repeated inc/dec controls, set the elevator trim percent via offset 0BC0? You can also use different inc/dec deltas to have a fast and a slow increase/decrease. This is the standard method of assigning to replicate a trim wheel.
For example, these are the assignments I use on a rotary to control the trim (for most aircraft):Quote78=P174,10,Cx32000BC0,x3FFF0060 -{offset sword increment, offset 0BC0 (Incr=96, Limit=16383)}-
79=P174,8,Cx42000BC0,xC00100C0 -{offset sword decrement, offset 0BC0 (Decr=192, Limit=-16383)}-
80=U174,8,Cx42000BC0,xC00100C0 -{offset sword decrement, offset 0BC0 (Decr=192, Limit=-16383)}-
81=P174,11,Cx32000BC0,x3FFF00C0 -{offset sword increment, offset 0BC0 (Incr=192, Limit=16383)}-
82=U174,11,Cx32000BC0,x3FFF00C0 -{offset sword increment, offset 0BC0 (Incr=192, Limit=16383)}-
83=P174,9,Cx42000BC0,xC0010060 -{offset sword decrement, offset 0BC0 (Decr=96, Limit=-16383)}-There are also some more advanced lua solutions in this FAQ entry:
John
-
2 hours ago, Reco said:
So my question is, should I set all my other helicopters to : send to FS as normal.axis. And is there any advantages or disadvantages to doing so
No. It is generally better to assign with Send direct to FSUIPC calibration (and calibrating). Only use Send to FS as normal axis if sending to calibration causes issues or doesn't work, which can happen with some aircraft. Note that, by default, axes assigned using Send to FS as normal axis are still calibrated in FSUIPC (if a calibration section exists), but this is performed after the event has been received back from the FS (which is masked/blocked).
John
-
1 hour ago, kaha said:
How can I achieve that a button, if I hold it down,, is immediately and continuously visible as pressed in the sim?
What has this got to do with FSUIPC? You can control how FSUIPC sees/reacts to button presses/holds/releases, but FSUIPC cannot do anything with what any other application, including the FS, receives/reacts to these button events. FSUIPC only sees and reacts to button press/releases, it does not send them on to other applications (that is windows' job!).
1 hour ago, kaha said:The BlackBird T-6A has a trim system that needs a button to be pressedcontinuously and in the tablet it can be adjusted how fast the trim will develop. I want this only for the buttons that are bound to the trims, so using "ButtonRepeat" probably is not appropriate.
The ButtonRepeat ini parameter controls how FSUIPC reacts to a held button press, and specifies the time between the button press and the first repeat, and the time for subsequent repeats, AS SEEN by FSUIPC. Changing this effects the button handling in FSUIPC only, not how other applications see/react to the button press.
Note that FSUIPC does have a 'hold' action on button presses:
Quote<Action> is a single letter denoting the action being defined:
P Pulse the key press or control: i.e. do not hold the keys down whilst the button is held down. This is always the case for controls, and should always be the case for any key presses involving ALT key usage, because once the FS Menu is entered FSUIPC cannot supply further changes like key releases. H Hold the specified keys down until the button is released. (This doesn’t apply to Controls and will be treated like P in their case). Do not use this with key presses involving ALT, for the reason just given.
R Repeat the key press or control whilst the button is kept held down. The repeat rate is approximately 6 per second and is not adjustable. Do not use this with key presses involving ALT, for the reason already given U Pulse the key press or control when the button is released.
However, I am not exactly sure what this does - looks like it is used when assigning a button to send a key press and will then hold the assigned keypress until the button is released.
So if that is what you are looking for, you could try that.Normally you would just use repeat (R), i.e. the assigned control is continually sent while the button is held down, and set by checking the 'Control to repeat while held' checkbox in the assignments panel.
John
-
1 minute ago, AlMassimo said:
So the issue is with SIOC and maybe the 0x3110 command offset.
Yes. Hopefully that modified version I attached above will allow the same control yo be resent via 0x3110 - let me know if that works.
And as I said, I can't really help with SIOC. However, I do see that you had similar issues sending presets via SIOC 3+years ago, which you reported in this thread:3 minutes ago, AlMassimo said:I'll also test lua mods, but with encoders I normally never react to 0 value that is used only to reset the offset in order
to detect the following -1 or 1.Understandable - and that is why I was using parameters > 0, and just setting back to 0 in the event handler rather than in the client after sending the proper parameter, as you seem to be doing when using SIOC.
5 minutes ago, AlMassimo said:Increasing the reaction speed of lua would also solve the problem, since as accuracy and precision lua is unbeatable.
I have looked at this several times now and just don't understand why lua executes so much slower in FSUIPC7 compared to previous versions of FSUIPC. There has been no real change in the lua engine or how this runs in FSUIPC7 (threads, etc) compared to previous versions, just updates to the additional lua library functions. So I don't understand the performance difference in FSUIPC7. I will look at this again when time permits, but as well as not having the time/resources for this at moment, I am not sure even where to start...
John
MSFS not communicating with PFC's Cirrus II console.
in FSUIPC7 MSFS
Posted
Sorry, but I have no idea.
Are you saying that you previously had it connected via a COM cable to COM ports, and are now using a serial-to-USB cable and it is connected to a USB port?
Why are you configuring COM ports if it is a HID/USB connection? Why do you need to set a baud rate if it is connected via USB?
Have you tried using the PFC hid driver rather than the com driver?
I have no PFC equipment and have never even seen or used any. All my knowledge on this comes from the documentation and existing support requests, so I suggest you start there (i.e. read the documentation).