AlMassimo

Thanks for these hints John, I'll try to apply some of them! Just one question; during testing I often have to add or modify some elements of myoffsets.txt or myevents.txt or Fsuipc.ini... Every time I do I exit Fsuipc and restart it. Is there a faster way to reload the files?

Yes thanks for your reminder... I have built a whole set of folders each with the configuration files for each plane. I mean, Fsuipc.ini, myoffsets, myEvents, lua, Mobiflight, SIOC. With a bat file I copy all the files in their specific dirs ovrewriting the files "lua_active.lua", "MF_active.MCC", "SIOC_active.txt", and so on. This way I have very clean and un-conflicting files, that I change before launching MSFS when I decide to use my simulator with a different plane. This may seem un-effective or complicated, but for me avoids having multiple configurations inside the same files, that is almost impossible with SIOC or MF. I normally don't change aircraft during one session of the simulator, so when I do I restart MSFS and everything is perfectly set for that plane. BTW Fsuipc is the only one that needs to be restarted in order to update the different configurations (apart from lua) but this is a really minor issue for me. Sometimes I stop Fsuipc and restart it when I am doing some test with modified configurations (ini, myevents, myoffsets) to be sure that all is reloaded properly (maybe there are other ways but this seem to be more powerful).

Hi John, I tested your solution and added this section to Fsuipc.ini [InputEventOffsets] 1=INSTRUMENT_HEADING_BUG_LEFT=UW66C8 It works perfectly! And this is a BIG deal! I apologize because I completely missed this section of the advanced manual, but it's absolutely a great goal, I can list all the input events and associate them to custom offsets and control a lot more things. Somehow and somewhere this input event reads and writes the Lvar (L:1:EHSI_1_HDG), but I can read the "INSTRUMENT_HEADING_BUG_LEFT" that is probably a B: var, and now it is available via Fsuipc.ini. The amount of different types of variables is getting quite a mess: A:, B:, L:, O:, H:, K:.... I will now extend the use of this tool, adding more input events to the [InputEventOffsets] section. If I understood correctly, if I add 2=INSTRUMENT_HEADING_BUG_LEFT_IN=UBA001 I do no longer need to call a custom event in Myevents.txt, I can simply write to the offset UBA001, correct ? Looks like a great thing!

OH! Now I understand!!! Sorry, I missed this element. This is very useful and for sure is the most effective solution! I'll test ASAP!

John, reading my previous post I had an idea... what if I could ciclically execute some calculator code in lua (not triggered by a var or offset change) eg: ipc.execCalcCode("(L:1:EHSI_1_HDG) (>A:AUTOPILOT HEADING LOCK DIR,Degrees) ") this will update constantly the A var... probably not the most efficient solution in this case, but could be useful in other situations. Maybe it's already possible, but I can't remember how in lua.

Hi John, I've seen the input event under the list, and I can assigne it to a control, but I have to set a parameter. I can also see this input event under msfs20204 sdk behaviors input events. That being said, I still can't understand how I can use it for reading the current heading value, that is what I find under the scoped Lvar. For me the solution I found (following your suggestion to transfer the scoped var to an A var) works perfectly, since Mobiflight reads this Lvar and allow me to write some code that transfer this value to the "standard" autopilot heading value, that I intercept easily with Fsuipc offset and then in SIOC. OMG now I understand 1 (>B:INSTRUMENT_HEADING_BUG_LEFT_Dec) (L:1:EHSI_1_HDG) (>A:AUTOPILOT HEADING LOCK DIR,Degrees) input events are the B: vars ??? Even so, I can write a custom event to be called by SIOC with the code above, but still I can read the heading value in A:AUTOPILOT HEADING LOCK DIR,Degrees ONLY after I change it. But I cannot display the value on the AP panel before at least one change of the value... I could write this line under LUA as calculator code, and probably works, but since I cannot read the scoped var I cannot trigger the transfer to the A:var when the scoped var changes. Anyway, since I solved the problem and all works, I don't want to bother you with this issue. Handling scoped vars will be useful but I understand it requires a lot of work. Thanks for your deep understanding of the matter and for your explanations that made the thing much clearer to me!

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