AlMassimo

Er... sorry but I couldn't figure out what is INSTRUMENT_HEADING_BUG_LEFT. It's not listed under variables, neither under events nor hvars... I simply cannot find it. If it is an input event how can I extract a value? I feel stupid, sorry...!

Hi John, sorry for the delay in my answer but I had no access to my pc for some days. Before leaving I tried to read the 1: Lvar from lua but, as you wrote, the current wasm didn't get it. So I modified the command line in mobiflight reading the Lvar and assigning it to the standard autopilot heading value, that is then handled easily in SIOC using the offset : in Mobiflight I set an input code as (L:1:EHSI_1_HDG) (>A:AUTOPILOT HEADING LOCK DIR,Degrees) then I added to myoffsets.txt 0x66C8, 2, AUTOPILOT HEADING LOCK DIR, I32, Degrees, w I prefer this solution instead of 07CC that requires calculations (Autopilot heading value, as degrees*65536/360) I just wonder why making things so uselessly complicated instead of using the common A:AUTOPILOT HEADING LOCK DIR, Degrees !!! But since I saw these scoped lvars in other planes I think it will be useful to have a future wasm release handling also these vars. I haven't tested yet the INSTRUMENT_HEADING_BUG_LEFT, I'll do that asap!

Hi John, the plane is the Asobo CL 415 "Canadair", for fire fighting. I found the Lvar under fs 2024 developers menu using the tool "behaviors" and copying the code. The Lvar is exactly how I wrote it, and without the 1: before the name it doesn't work in MF. Modifying THIS Lvar I get the heading pointer moving properly on the HSI.

I tried to figure out how to read some Lvars that have a number before, eg. the AP heading of the default Canadair is 1=1:EHSI_1_HDG I can't understand what is this format... maybe is an array? I can read it on Mobiflight, and I added the events inside the myevents.txt file to change it with my Opencockpits MCP that uses SIOC, so I added CANADAIR_HDG_BUG_DEC#1 (>B:INSTRUMENT_HEADING_BUG_LEFT_Dec) CANADAIR_HDG_BUG_INC#1 (>B:INSTRUMENT_HEADING_BUG_LEFT_Inc) calling these events I see the Lvar changing properly, but only on Mobiflight. If I add this Lvar to Fsuipc.ini like this : 1=1:EHSI_1_HDG=UWA030 nothing is written in A030. This Lvar isn't even visible under wasm list Lvars. How can it be reached? I tried to search for this but I can't find a search key that gives some result, so sorry if I'm asking something already explained...

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.