Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About AlMassimo

  • Rank

Profile Information

  • Gender
  • Location
  1. Thanks, I saw that post, but I don't know how to create the pokeysdevice object without luacom. I could try to compile it in 64 bit environment, but I think I'd rather work on Arduino if it is less complicated that this solution. It was a really powerful and easy to use combination, it's a pity it was abandoned (at least seems abandoned).
  2. No, I installed the most recent luacom.dll I could find, compiled in 2020 and compatible with lua 5.1, in the lua dir under FSUIPC7 dir. Then i set my lua code for the pokeys inside the ipcready lua. These are the first rows of my mip.lua code (that worked fine with fsx when I last used it) require "luacom" poKeys = luacom.CreateObject("poKeysDevice_DLL.poKeysDevice") if poKeys == nil then ipc.log("Error: poKeysDevice_DLL object creation failed.") ipc.display("NO POKEYS - QUIT PROGRAM") ipc.exit() end When I launch MSFS nothing happens, but when I look in the log file I find this : 149422 LUA.1: beginning "C:\FSTools\FSUIPC7\ipcReady.lua" 149422 LUA.1: C:\FSTools\FSUIPC7\ipcReady.lua:1 149438 LUA.1: Global: ipcPARAM = 0 149578 LUA.2: beginning "C:\FSTools\FSUIPC7\mip.lua" 149578 LUA.2: C:\FSTools\FSUIPC7\mip.lua:1 149594 LUA.2: Global: ipcPARAM = 0 149656 *** LUA Error: error loading module 'luacom' from file 'C:\FSTools\FSUIPC7\lua\luacom.dll': %1 non è un'applicazione di Win32 valida. I tested both the luacom supplied with the lua for windows precompiled package (and luacom.dll is dated may 2008...) and the most recent luacom.dll that I found on the net, but none of the two worked (if the error is caused by the specific version of luacom). Currently I am exploring many other territories, form MobiFlight to Python libraries that seem to work directly with simconnect and could be interfaced with arduino, but of course if I could make my Pokeys to work with LUA and FSUIPC I would feel much more "comfortably at home" let me say...!
  3. Looking on the console, the parameter 1 is not received apparently; when I press the button, on the console the row with control 68065 shows a parameter = 0, nevertheless the autopilot knob works, but the Var 0442 should issue a value 1 to the control parameter... This function in SIOC/FSUIPC could be used for improving the old fsx drivers for MCP and even EFIS. My next test will be on the EFIS side, to see if sending controls work on the NAV display or the GPS. I'm also working on interaction between FSUIPC, MobiFlight and Arduino, but I miss my LUA interface with my Pokeys (currently still connected to all my overhead...) Is there any hope that LUACOM will be working again ?
  4. Hello, I found a good solution with this option available in SIOC through a powerful function in FSUIPC : Var 0441 name FS_CONTROL Link FSUIPC_OUT Offset $3110 Length 4 Var 0442 name FS_PAR Link FSUIPC_OUT Offset $3114 Length 4 Var 0426, name I_HDGSEL, Link IOCARD_SW, Input 28 { IF &I_HDGSEL = 1 { &FS_PAR = 1 &FS_CONTROL = 68065 &FS_CONTROL = DELAY 0 10 So pressing the heading lock button I also send the command to commute HDG SLOT to 1, and that work. The first idea (sending an fsuipc virtual joystick button) is very interesting, but worked randomly, sometimes the button press was detected, many other times no. Probably something has to be fixed... Anyway FSUIPC is really a great tool, and the more you know it the more you discover how poweful it is!
  5. Hi John and Pete, I found in sioc manual that sioc can simulate a button action on one of FSUIPC virtual joystick. This way I could use the button of the MCP AP MASTER to do also a simulated button press for the VJ : Var 1 Link IOCARD_SW Input 116 Type I { &FO_JoyStick64 = CHANGEBIT 0 v1 // toggle bit 0 of joystick 64 } Var 2 name FO_JoyStick64 Link FSUIPC_OUT Offset $3340 Length 4 SO I could assign this button the action of setting the hdg slot to 1. That should work in theory... and this opens a lot of possibilities also! I'll try and report the result.
  6. Thanks a lot John!!!! THAT WORKS! The control was set to FMC, capturing the current heading value. Setting the slot to 1 the control is passed to MCP heading value as set with the HDG knob. This is very good, and the same thing can be applied to altitude and speed. Now the ideal thing would be to send this control automatically when I push the AP button, is there some way I could send this command from sioc, when I press the AP button ? or maybe I could write some LUA code ? What do you suggest John ? I understand that this could be a problem when using the FMC. I wonder why they do this passage to the FMC if no flight plan whatsoever was set... To answer to Spokes2112 (thank you first of all) I agree with you that somewhere in cfg somewhat should be this setting, but the aircraft.cfg seems to be locked (".fsarchive) if you can find some other path to reach the autopilot configuration, I can't find it... As I said I checked many files under instruments, I also found the 787 FCU.js and other, but all attempts to modify those files didn't work.
  7. I have found this possibly interesting post on MSFS forums : "There are no commands that are visible in control settings GUI. But you can control the FCU authority with these Sim Connect sim events; HEADING_SLOT_INDEX_SET SPEED_SLOT_INDEX_SET ALTITUDE_SLOT_INDEX_SET VS_SLOT_INDEX_SET Sending these with parameter 2 gives the authority to FCU, and sending with parameter 1 activates selected mode for each knob. You’ll need to use a 3rd party controller interface software that use sim connect; ....." Maybe that these "SLOT_INDEX" variables or controls set to 1 allow normal operations for the knobs of MCP ? I cannot send them directly to simconnect... never even tried to do this directly, only used FSUIPC.
  8. Disaster.... (for me at least) 747 is completely different from B787, it uses other variables (and maybe other commands) for the autopilot, autothrottles, etc, so, given that 787 was almost partly controlled by old fsx AP variables and commands (left apart heading hold mode and vertical speed mode, level change mode, etc...), that means that the 747 has mostly custom new variables... I hoped that at least 2 Boeing airplanes could share the same Autopilot controls... but seems not to be the case. I just wonder, if no SDK updates will be released before october 2020, how will you be able to release the commercial version of FSUIPC if essential offsets won't work... For sure I will buy the license as soon as it will be available, but will it work for the autopilot variables used in default planes ? I am a MSFS 2020 enthusiast from day 1, no doubt about that, graphics level is awesome, but after some weeks I must have to agree with those who said that too many things were not ready for an offical release... hope that your creativity and strong technical skills will overcome somehow these problems, at least for essential part of the avionics as the FCU or MCP, EFIS and so on.
  9. No way, nothing works. I tested probably all the available commands related to autopilot heading, but no one worked for the "Hold" function of the 787 panel. I was wrong when I said that the console recognizes the command sent when I press the center of the HDG knob in VC. When I press the HOLD button under the knob the console report the event "AP_HDG_HOLD_ON" and when I press the button on the OC MCP it displays "AP PANEL HEADING HOLD ON" or OFF, but nothing appears when I press the VC knob button, that is currently the only way to remove this sturdy and stubborn "HDG HOLD" function. I have explored the HTML code of the gauges under aircraft dir, there are many of them related to 787 or airliners or generic panels, but is difficult for me to understand where the heading hold control is activated in conjunction with AP master activation. I don't know if in the real 787 the AP master does this, but MS/Asobo could at least have provided a command configurable to switch this off from the keyboard. Probably is a new variable, maybe only on 787, and nothing can turn it off from outside the simulator itself. It's quite annoying for me. I've installed the last update patch today, but even so the problem still remain exactly as before. At least on XPlane 737 specific datarefs were listed on documents and I could interact with them just using the right syntax, here for the moment I can found nothing in the SDK.
  10. Hi Pete, thanks, I'll try as soon as I get back home this evening. I was thinking only in terms of offsets since I can't remember if SIOC allows sending commands, I always see only offsets in the code. Years ago I wrote a lot of code with lua and fsuipc offsets, for all my cockpit, but I am no longer able to have luacom working so I have to leave my Pokeys and use Arduino instead. For the heading issue, do you mean that I can assign an action to the OC MCP button ? This is what I am trying to do, because otherwise I will have a fictional operation to do pressing a key on the keyboard or on the yoke just to be able to disengage this heading lock that wasn't present in fsx 737. Or can I associate an action in fsuipc triggered by a button in my MCP ? I don't think is possible... I will alse check if the same problem is present on the 747 autopilot.
  11. Hi Thomas, thanks! I am a bit rusty about FSUIPC menus and controls (for the last 3-4 years I only used XPlane), so I apologize for not having checked this option before. This seems to be the solution, I can assign a key to this action and (if it works) deselect the AP HDG hold just after pressing the AP master button. The ideal thing would be to send this command automatically when I press the AP button, maybe through sioc or even a lua script or else... I'll try if the key assignment works, and at least I can avoid to go on VC mode and click a spot on the screen!
  12. Ok essentially the question is: is there any way to send an AP_HDG_HOLD_OFF through FSUIPC ? I cant' find that, and apparently no configurable control is present in MSFS menu to assign a key combination in order to send this command, so at the moment no way to get rid of this unwanted AP_HDG_HOLD function that locks the operations of my MCP otherwise working well.
  13. Sorry Pete, I repeated things you said in your answer. I will do some more testing tomorrow and I will report if I have any success...
  14. Regarding the heading values, let's suppose that I set the heading to 230 degrees with my MCP knob, both the MCP and VC displays show "230". Good. The plane current heading is, let say, 200 degrees. I push the AP master button. On the VC, the "led" on the HDG button becomes green, and the plane starts follwing the 200 heading, but on the displays (on VC and on my MCP) I read 230, while the plane is holding 200. Only when I switch off the heading hold function pressing the VC knob, the plane starts aligning with 230° and then I can control the heading setting it with the HDG knob on AP.
  15. Thanks a lot Pete, it's not easy for me to explain accurately the problem. I opened the console in order to see what happened when I pushed the HDG HOLD on the virtual cockpit. To set this on I push the button under the knob, and the "led" comes green (this happens automatically if I activate the AP master from my OC MCP master button). In this situation the plane hold the current heading, and I can do nothing from my MCP to change it, only for a split of a second when I turn the knob the plane turns but after that it goes back to previous heading. To turn it off the only thing I can do is to press the button on top of the VC heading knob, and then everyting on my MCP work fine. So, having the console opened, I selected "events" and I can see the rows showing the operations carried out, eg. "AP HDG HOLD" and - on the left - other numbers that I can't identify for what they are (sorry - I surely missed some part of the instructions for the console). The only thing that I find significant is that pressing the button on the VC the events are different from those coming out when I press the button on the MCP; the offsets in the sioc code are those well documented for the autopilot, and they work perfectly, but ONLY if the VC heading hold is turned off (and this can be done only from the VC, and I need something to avoid this). I remember from FSX that there were 2 set of controls KEY_AP_HDG_HOLD_ON AP_HDG_HOLD_ON Turns heading hold mode on Shared Cockpit and KEY_AP_PANEL_HEADING_ON AP_PANEL_HEADING_ON Turns heading mode on (without capturing current heading) Shared Cockpit KEY_AP_PANEL_HEADING_OFF AP_PANEL_HEADING_OFF Turns heading mode off Shared Cockpit KEY_AP_PANEL_HEADING_SET AP_PANEL_HEADING_SET Set heading mode on/off (1,0) Shared Cockpit To what I understand is that the VC button sends the first command (locking the current heading until I turn it off whatever else I did) and the OC MCP via sioc and the offsets you reported (07C8, 07CC) send the second kind of commands (with "_PANEL_") that work only if the hold mode is previously disengaged. Tomorrow (now is very late) I will try to capture some screenshots with the row displayed on the console. Thanks again for your help.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.