AlMassimo

Thanks John, an extraordinarily clear and exhaustive explanation and let say "tutorial". I learnt a lot of things, and now all seems a lot clearer (or I hope so). My cockpit is now working at 99.5%, after a lot of years I decided to buy an FMC and since the one procuced by Winwing is more than affordable I bought one and it was delivered in less than a week. With SimAppPro it works like a charm. It is a big step forward for me. In the next months I will try to use it for different planes. I have no idea if the keypresses can be captured and handled outside SimAppPro, maybe by Fsuipc... but for sure the display is a totally different story! Anyway, thanks for your great support. It is a pleause seeing how deep is your knowledge and understanding of how MSFS and many other programs work and interact with or by Fsuipc, lua, etc. Have a good day. Massimo

Yes I agree completely! Since events.txt is subject to continuous updates, and so you can't rely on static addressing, at least myevents is totally under user control, and it would be great if it was always on the same address/offset. I have a subfolder for each plane containing an Fsuipc.ini, a plane_name.lua, a myevents.txt and myoffsets.txt, a Mobiflight config file and a SIOC file. I replace all the files when I decide to fly with a different plane, and for some time I reconfig the simulator for the current plane. This is pretty satisfactory, since each file is pretty clear and contains no other planes parameters or code. No, the code was the following : Var 0175, name E_HDG, Link IOCARD_ENCODER, Input 6, Aceleration 1, Type 2 { IF &E_HDG = 1 { &FS_PAR = 39008 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_HDG = -1 { &FS_PAR = 39007 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } } } so I think I'm setting the parameter BEFORE calling the control, in this case 66587. 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. Anyway as I wrote, I am gradually transferring the lua code into SIOC code using Lvar offsets and myevents, and things are going faster now!

I read all the SIOC manual and apparently it can't handle text variables. So it is not possible for me to activate events via event name, that's a pity but calling by number works perfectly so that's good. 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). Now I'm testing a combination of Fsuipc.ini lvars offsets and myevents.txt events. Seems great. Probably I'll be able to replace all lua code and increase reaction speed.

Hi John, 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). 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. No need for slow/fast selection. If I rotate the knob slowly the value changes slowly, but if I rotate the encoder as fast as I can still the value follows perfectly the detents per cycle and in a few seconds I can change, eg, speed from 180 to 310 Kts or heading from 30 to 210 without affecting any other parameter. I'm so happy with that! Now the MCP is fully working, fast and reliable as far as I could test it for the moment. Lua is Ok for all other controls, maybe the displays could be updated faster, so I will try to use Lvars in Fsuipc.ini to make the SPD. HDG, ALT and VS values available to SIOC without passing through lua. This should make the MCP controls even more reactive and fast. 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) I will also do some testing using strings to call directly the event via event name, that would be fantastic (if SIOC can handle strings but I think it does). Please let me know if you want me to send you the code I used, but I think you already figured it out. Thanks for your support! Massimo

OMG!!! Thanks John, fantastic research and testing! I'll be able to do some testing on saturday since at the moment I am away from home, and of course I'll report the result. I am pretty optimistic that something of this will work. I have a wide set of SIOC/LUA/Mobiflight code for almost all the B737, and of course the MCP is an essential part of that. With Mobiflight all encoders would work perfectly since I tested them on "test" encoders that I use for cockpit flooding or for other secondary tasks. So the issue is with SIOC and maybe the 0x3110 command offset. 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. Increasing the reaction speed of lua would also solve the problem, since as accuracy and precision lua is unbeatable. Thanks again

Hi John, as usual you go beyond any expectation in getting deeper and deeper into an issue, and you find solutions that I couldn't even imagine... I'm so grateful to you for this excellent support you grant to the users of your beautiful software! I can't understand why this issue with old control called by a new one seems to appear only with B737 "rotor_brake" command. Normally I send different controls for different encoders, so this problem doesn't appear. In this case I send a different parameter to the SAME control. EG for increasing or decreasing AP HDG normally you have 2 different control codes, not 2 parameters for the same control... Maybe I could send a fictional (unused) control after each real control, so the next will change the unused variable and not the one changed before the new encoder is triggered. The fast option in lua sounds very interesting. If I could change the HDG by 5 or 10 instead of 1 it should be OK after to have a slower 1 step for fine tuning. It would be fantastic if you could do some experiment!

Interesting! That could be, since probably core 0/1 are most stressed by MSFS 2024. I remember a parameter on lua that sets the maximum frequency of updates (can't remember where) and it was aboyut 10 times per second, should be enough to follow an encoder even if I rotate it pretty fast... Sorry if I'm creating some confusion, because as I said I tested many different solutions. The SIOC code is the bridge between OC modules and Fsuipc --> MSFS so I use it in 3 ways : 1 - change an offset and let LUA do what is needed (working perfectly but slow for encoders and displays) I use this for altitude that has lower delta (I can use 1000 ft steps) 2 - call a control by setting a parameter and then activating offset 0x3110 with the command 66587 (K:ROTOR_BRAKE) : works but replies the last command I think it's critical this line : &FS_CONTROL = DELAY 0 10 that means send param 0 to FS_CONTROL (0x3110) after 10 milliseconds (I think) in order to free it for the next command; apparently this could be the issue. Perhaps the time is not enough or doesn't work properly. In LUA isn't needed any delay. 3 - call a custom event that activates the ROTOR_BRAKE command with the needed parameter (to be tested after deleting events.txt hoping to find proper addresses) (4) - set the 0x7C50 with a string containing the name of the preset (still to be tested) currently I am testing a mix of these methods, so I'm sorry this can be confusing!

Hello, all clear now, thanks. As soon as possible I'll test if removing events.txt all works fine. As for lua, I configured ipcready to launch B737,lua so it should be running all the time and not be called by the specific command. My workflow is this : - I change a button or encoder position on my OC MCP or radio panel - in SIOC I detect the change of the input and I set to 1 or 0 a custom offset (or to -1 or 1 for encoders) eg A001 - in LUA I monitor the offset A001 and when changed lua calls the function "ENC_HDG" - the function ENC_HDG checks if A001 is -1 and execute a line of calculator code, or if it's 1 and then execute another line of calculator code - another function in lua checks the value of the MSFS autopilot heading value (via offset, or LVAR or whatever) and writes the value to a custom offset eg "A020" - the offset is read by SIOC and sent to the hdg display All works fine (and could solve all the problems) but when I rotate the encoder fast to change hdg eg from 100 to 270 it takes a lot of time, since hdg value changes very slowly and many ticks are missed. If I do the same calling directly the command (ROTOR_BRAKE) using the 0x3110 control offset all works very fast but as I said changing parameter (moving another encoder) the first action still changes the previous control... I hope that calling an event instead of sending a control could solve this issue (but I'm not sure it is different after all, probably the previous event will be called as well). If lua were faster I would solve completely all problems. I will try to see if starting fsuipc manually changes something. Is it ok to shutdown fsuipc and then restart it manually without modifying the "auto-start with MSFS" feature ? Last thing : I cannot detect the hardware buttons or encoders out of SIOC, afaik there is no way to see the controls in OpenCockpits modules neither in Mobiflight not in Fsuipc, this is a pity but as I said the OC panels are pretty old now (10 years maybe...)!

Hi John, thankyou, I suspected that I had to remove events.txt but I thought that myevents were always found starting from the address 4194304, but I was wrong. I knew that using events.txt I had to follow your instruction to reach the address of a specific event, and seemed too complicated and variable updating events list. I will also try the string offset 0x7C50 procedure, but I must check how to do that in SIOC, probably is simple but at the moment I have never tried that. I see events list in fsuipc.log even if I haven't se debug in WAPI, but I cannot see myevents ? Odd to me, but that's no problem. So probably it will be all ok after I remove events.txt. Sorry I wrote myoffsets instead of myevents, but I meant myevents. I also use myoffsets to import specific A vars that seems not have an offset assigned. I use lvars inside fsuipc.ini, your software has so many powerful features! I'm sorry I cannot use it directly, since I have to deal with SIOC programming... but fsuipc allows to keep on using this outdated software even with most of the new features of MSFS 2020 and 2024, included the extremely powerful calculator code. I just wonder if it's possible to speed up lua, because it seems strange to have this lag, seems like if it updates 1-2 times per second, is this correct ? Thanks for your invaluable support,

Hi John, thanks a lot for your patience. Here you find myevents.txt and log file, I can see no trace of my presets in the log... I used myoffsets in the past and they worked fine, surely I'm doing something wrong. Massimo FSUIPC7.log FSUIPC7.ini myevents.txt

Thanks John, I started using the code you suggested, but for some reason every time I act on a different encoder, the last command is sent, and only after that the new encoder sends the new command. So eg. if I have set the altitude to 10000 ft and then try to set the speed from 190 to 200, when I rotate the speed the first impulse still changes the altitude (eg to 10100), and only after I can modify the speed, as if the old par was still in memory and not substituted by the new parameter. The same happens when I change dir of rotation, after some increases the first counterclockwise tick still increases the value, and only the second starts decreasing. This is pretty annoying. With lua this doesn't happen, but as I said it has a lag much too big for an encoder (it's Ok for switches and buttons) so I tried other ways. What I cannot understand is why fsuipc is ignoring the content of myevents.txt (is it Ok to place it under the same directory of fsuipc?) apparently it could solve the issues since probably the replicated old command is a bug of SIOC as far as I can say.

All controls for PMDG 737 are sent by a parameter associated to the K:ROTOR_BRAKE command, that was "free" since the 737 doesn't have a rotor. The problem is that I can't see any effect by adding the file myevents.txt, I suppose I should see something in fsuicp.log file, or in the console, but nothing happens. Probably I did something wrong. I'll try with other events, like parking brake or other common commands...

Hello, I am trying to use the calculator code in myevents.txt in order to write the controls for pmdg 737. I created a simple myevents.txt under the FSUIPC directory. This is the content of the file : B737SPDDEC#38408 (>K:ROTOR_BRAKE) B737SPDINC#38407 (>K:ROTOR_BRAKE) B737HDGDEC#39008 (>K:ROTOR_BRAKE) B737HDGINC#39007 (>K:ROTOR_BRAKE) I have an (old!) opencockpits MCP V3, so I must use SIOC to control its functions. This is the part of the code that should activate the first 2 events // AP ENCODERS -------------------------------------------------------- var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 1 &FS_CONTROL = 4194304 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 1 &FS_CONTROL = 4194305 &FS_CONTROL = DELAY 0 10 } } } But when I move the SPD encoder nothing happens. The same for the HDG encoder. I opened the .log file and I can find nothing about myevents.txt, and also the console doesn't show any activity when rotating the encoders (I activate logging of the events and I can see all other events). What am I doing wrong ? Did I miss something ? I hope that someone can help me. (BTW I solved the problem using LUA, but it seem to have a great lag so it's a pain to set the values rotating the encoders, maybe this also can be improved setting some params but I have no clue) Thanks for helping me Massimo

Yes they are for FBW A320 (or "A32NX") that has different controls for left and right seat switches. Most of FBW variables are "A32NX_something" but probably the first added were still "A320_something" and this causes some confusion, since they are difficult to distinguish from default A320 variables. It could be a good thing to have different hvar files for A320 and FBW A32NX.

Ok very interesting. I fixed the Hvar issue following your indications 1) updated with lates beta 3.9 2) added to A320.hvar under "modules" folder these 2 lines : H:A320_Neo_MFD_BTN_ARPT H:A320_Neo_PFD_BTN_LS And now also ipc.activateHvar works perfectly.