Jump to content
The simFlight Network Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by aua668

  1. Hi, One observation from my setup: I tried once to combine my dedicated modules in a single LUA file. If they use a lot of event triggers (radio knobs with GoFlight hardware typically produce 8 different button actions) the performance was worse compared to the single LUA modules. Therefore I stayed with smaller modules with fewer event.button triggers. Rgds Reinhard
  2. Hi, That's how I run my programs without any problems: [Programs] RunIf1=AM=2,READY,CLOSE,"C:\Users\Reinhard\AppData\Local\vPilot\vPilot.exe -host" RunIf2=AM=2,READY,DELAY,"C:\AviaServer\AviaServer.exe" I enclose my command including parameters completely by quotes. Rgds Reinhard
  3. Hi, Have you already tried to run it with quotes arround the command? Run2=READY,CLOSE,"C:\Users\NAME\AppData\Local\FS-Keypad\FS-Keypad.exe C:\Users\NAME\AppData\Local\FS-Keypad\Keypads\303df744-c367-4681-a409-4ac2f187b39e.json" Error 267 = directory name invalid (I assume) Rgds Reinhard
  4. John, Yes these modules are running (partially). I have for example a LUA module for handling NAV1 on a GF module. Most of the events are handled correctly (inc/dec frequency for example) and few events in that module are not reacting (e.g. swapping frequencies). And the real strange thing is, that if I check via the FSUIPC UI on the button page, the same button is recognized. I run this code already very long from FSX over several P3D versions. Until my upgrade to 5.2 (and 5.2 with HF1) it worked without any problem. And another strange thing: One time it's NAV1, the other time it might be another button from a completely other module. I know, that you don't have any chance to reproduce - even I am not able to have a scenarion, where it always happens. My hope is, that others might experience the same and that we can come to a pattern. Rgds Reinhard
  5. Hi, I am running P3D 5.2 HF 1 (version and FSUIPC 6.1.2 on WIN 10 with the latest updates. I have connected to my simulator several GoFlight hardware devices. I use them since already FSX days. I handle the input from these devices via LUA modules using the event.button function. Since switching to 5.2 from 5.1 I have the problem, that few of the registered event.button functions (and sometimes also the event.offset functions) don't fire. Most of the buttons are working normally. The buttons themselves are recognized by FSUIPC, which I can check on the buttons page in the FSUIPC UI. And there are always some different buttons, where the events are not detected by LUA. Completely random. The FSUIPC logfile shows no errors and I didn't change anything during the upgrade. If I manually restart the single module, where one or more event.button functions are not firing, via ipc.runlua(), the module works then as expected. I start all my modules per ipc.runlua() out of a loop in a start module. This always worked fine in the past. The table AC.GF holds the specific modules for the current aircraft. local k=0 local j=0 local v="" for k in pairs(AC.GF) do for j,v in ipairs(AC.GF[k]) do ipc.runlua ( v ) ipc.sleep(1000) ipc.log (v.." initialized") end end As the error is randomly occuring, I have no idea, how to find the reason. The only common thing is, that it has todo with the handling of events in LUA. When I upgraded to P3D 5.2 there was also a WIN 10 update provided at the same time (2021-06 Windows 10 21H1). Not sure if it is P3D 5.2 or maybe the WIN 10 update producing this random errors. . Anyhow since that time I can't be sure, that all of my programmed events are really working. And it's independent of the plane I am using. Maybe you have an idea, what might have changed with the event handling in 5.2. Best regards Reinhard FSUIPC6.log
  6. Hi, You could check this posting in the A2A forum: https://a2asimulations.com/forum/viewtopic.php?t=39914 At the the end there are mentioned two variables reflecting the transponder mode. With a little bit of LUA code monitoring these variables you could trigger the right vPilot actions. Rgds Reinhard
  7. I did not mean you Joe, but the user rustam, whom I quoted... Rgds Reinhard
  8. Hi, I think you missed that simple solution, which I also use if I just have to set LVars by buttons. The macros mentioned by Paul are NOT mouse macros (which don't work in your aircraft) but just simple LVar macros, which ALWAYS work. You will find more details in the Advanced User Manual. The MCRO file looks like this example: [Macros] 1=L:idle eng=Set 2=L:idlebit=Set 3=L:B407_Eng_Start_Switch=Set Adding such a macro file to your FSUIPC directory allows you then to simply assign these commands to any button. Beside the Set function there are several others too (Toggle, etc.). Using this method simply needs no programming, if you just have to set some LVars. Rgds Reinhard
  9. Hi, Just one hint for your implementation: I found out some time ago, that having more smaller LUA programs handling button and other events is a lot better in terms of performance than packing all your functions into one large LUA. And as a side efect: A smaller LUA program is much easier to read and maintain, than a loooong LUA script. Rgds Reinhard
  10. Dear John, It works perfectly again. Thanks for fixing this so quick! I did run it with EnableExtraButtons=Yes and it's working again from LUA with the event.button triggers. Best regards Reinhard
  11. Hi, Thanks for checking my problem. I did a quick test with EnableExtraButtons=No . It does not change the behavior. The POV buttons are recognized in the button assignment tab of the FSUIPC UI but not within LUA using the event.button trigger. So as I could stay on 6.0.13, there is no problem for me, until you find the reason. Following the thread about the beta pre-release of the 6.1.0 version, there are a lot of references, that some adjustments in the code have been made for the POV buttons. Maybe the LUA part also has to be adopted accordingly. Rgds Reinhard
  12. Hi, I upgraded from FSUIPC 6.0.13 to 6.1.0 (Win 10, P3D 5.1 latest HF) and suddenly my coolie on my Saitek yoke, which I use to switch camera settings via LUA code, did not work anymore. Other buttons on the yoke work normally. The buttons are also recognized, if you check them in the FSUIPC UI (button assignments). Only in LUA programs using the event.button trigger the buttons are not trapped anymore. The buttons, which are not recognized, are buttons 32 to 39. I stepped back to 6.0.13 and everything was working again. Upgrading to 6.1.0 and functionality is broken. So I reverted back to 6.0.13 at the moment. The strange thing is, that this only happens in LUA programs. And it's independent from the plane I am using. I checked the FSUIPC6.log file and both detected my hardware completely identically.No errors are shown. Maybe you could check this. Rgds Reinhard FSUIPC6_1_0.logFSUIPC6_0_13.log
  13. If you want to check your USB devices I recommend to use USBDevView: https://www.nirsoft.net/utils/usb_devices_view.html Rgds Reinhard
  14. Definitely - I use GF-Modules since many years always with the latest FSUIPC version. And it works with the versions mentioned by John. RGDS Reinhard
  15. Hi, LUA scripts are not executed automatically per default. You have to put a line into the [Auto] section of the INI file or you have to start the LUA procedure by assigning it to a button or key. Details are found in the manual for advanced users. Rgds Reinhard
  16. Hi, One question, which might be stupid, as I am not aware about the hardware you are using: Why are you not using four simple button assignments triggering the controls with the desired parameter? Rgds Reinhard
  17. Hi, You should look for LINDA, which provides out-of-the box functionality for most buttons. If you are an advanced programmer, you can check the coding of LINDA for the relevant mapping of buttons to LVars. A list of all LVars can be produced via the LUA sample code provided with FSUIPC. I enclosed the list for your reference. Here you find a small function toggling the APPR button: -- APPR function APPRToggle (joynum, button, downup) -- toggle APPR ipc.writeLvar("L:AB_AP_LOC2", 1 - ipc.readLvar("L:AB_AP_LOC2") ) ipc.writeLvar("SmallOverheadPushButtons", 1) end Rgds Reinhard LVar_AS_A3xx_Pro.txt
  18. Hi, Just to add: In the meanwhile I make it much easier: I have the LUA files per aircraft in a separate directory: <FSUIPC folder>\LUA\A320 <FSUIPC folder>\LUA\DH8D : In my master start routine I first determine the aircraft type out of the name read out of the FSUIPC offset. Then I start the necessary modules directly out of the subdirectory: ipc.runlua ( "LUA\\A320\\A320_GF_EmergLt" ) Attention: use the double \\ for subdirectories ! In fact I have a LUA table defined in a profile module and run each module out of a loop: -- init all GF functions defined in the AC profile local k=0 local j=0 local v="" for k in pairs(AC.GF) do for j,v in ipairs(AC.GF[k]) do ipc.runlua ( v ) ipc.sleep(500) ipc.log (v.." initialized") end end Profile: -- init GF tables AC.GF = {} -- GF-RP48 Unit 0 AC.GF.RP48_0 = { "LUA\\A320\\A320_GF_TOConf" , "LUA\\A320\\A320_GF_ASkid" , "LUA\\A320\\A320_GF_ECAM" , "LUA\\A320\\A320_GF_EmergLt" , "LUA\\A320\\A320_GF_SeatBelt" , "LUA\\A320\\A320_GF_NoSmoke" , "LUA\\A320\\A320_GF_WxrBright" , "LUA\\A320\\A320_GF_WxrTilt" , } -- GF-RP48 Unit 1 AC.GF.RP48_1 = { "LUA\\A320\\A320_GF_Bat" , "LUA\\A320\\A320_GF_Altern" , "LUA\\A320\\A320_GF_Avionics" , "LUA\\A320\\A320_GF_BusTie" , "LUA\\A320\\A320_GF_FuelPump" , "LUA\\P3D\\P3D_GF_ParkB" , "LUA\\A320\\A320_GF_APU" , "LUA\\A320\\A320_GF_IGN" , "LUA\\A320\\A320_GF_ABRK" , } Rgds Reinhard
  19. Hi Al, As my solution was mentioned: I had a similar problem like you with coupling several aircraft types to my GoFlight hardware. But by moving the necessary routines to sub directories per aircraft and by having a generic startup routine, which starts the necessary modules depending on the aircraft type loaded out of the respective subdirectory, the limit was no problem anymore. So I can definitely recommend to go for that approach. Rgds Reinhard
  20. Hi Rhys, The MD530F from Milviz only has a VC. But defining views with dedicated cockpit cameras (showing only the interior) is a very simple task. So if you have a separated outside view (what I assume that you have, as you are building a small cockpit), then you can arrange your camera views on your cockpit monitor(s). I am Using a Samsung ultra-wide 32:9 screen for the outside view and below two touch screens for the cockpit view (pilot/copilot) beside some GoFlight hardware. Here you find the manual: https://milviz.com/Online_products/Manuals/MV_MD530F_rev.pdf An here a review: http://www.raysaviation.mono.net/upl/11588/MilvizMVMD530LittleBird.pdf Rgds Reinhard
  21. Hi, Which helicopter add-on are you using as a base for your implementation? I own the Milviz MD500 and in that product the start procedure is exactly implemented according to the video. Rgds Reinhard
  22. Hi, In the documentation folder of the Aerosoft Airbus you will find a document "Vol7-Thrust Lever Setup.pdf". In that document two methods of setting up your controls are described: Without and with FSUIPC. Follow these instructions and it will work. The most important sentence: Rgds Reinhard
  23. Hi, I think, you clicked on the tag instead of going into the subsection of the useful programs and download the latest ZIP from there. I have just tested it and it works as planned. Rgds Reinhard
  24. Hi, Some things you might check, if you have an ON/OFF switch but only found a toggle command in the command list: Check, if there is an corresponding offset available, which you could use to invoke set/clear instead toggling If the offset is read-only, you might consider offset conditions in your button programming Check if there are Lvars available in the specific plane, which you could use to set/clear the respective switch If nothing else worked, you could check, if there are distinct click spots available in the gauge for on/off. Or if on/off is triggered by different mouse buttons. In that case you could use mouse macros, if the gauge is supporting it. A good starting point is also to check, if there is a LINDA module available for that specific plane. Maybe you get there a hint, how to operate the specific switch. Rgds Reinhard
  25. Hi, A better way to toggle these switches is by setting the following Lvars to 0 or 1: L:AB_PDS_Eng1Master L:AB_PDS_Eng2Master You can do this either by a small LUA script or by creating a "normal" macro toggling these variables. See page 39 in the Advanced User Manual. Then you simply can assign this macro to your button. Also many other switches can be operated by that method. It's way better compared to the mouse macro, as this method works across engine variants on all A3xx planes from AS. Rgds Reinhard
  • 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.