Jump to content
The simFlight Network Forums

aua668

Members
  • Posts

    354
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by aua668

  1. Hi, I did now the test for the Aerosoft A320 - and again: No errors anymore and all modules are working as before. Rgds Reinhard FSUIPC6.log
  2. Hi, This looks GREAT !!! No more errors in the log and all modules did work after a short cross check. It seems, that my planes are not grounded anymore. Many, many thanks! Reinhard ๐Ÿ˜€๐Ÿ˜€๐Ÿ˜€ FSUIPC6.log
  3. John, Success - I used now this version and started my modules with the Q400. And in the log #1 I find now errors exactly for those modules, which did only partially work: 216484 LUA.7: LUA\Q400\Q400_GF_NAV2 started 216656 *** LUA Error: ...repar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_NAV2.lua:180: Coudn't enter critical section! Then I did a second run, where also these errors occured. But with different modules. You find the result in log #2. Before closing the simulator I turned on LUA debugging. Then I started run #3. With debugging turned on, the error only occured for a single module: Q400_GF_PanelLt.lua 203906 *** LUA Error: ...ar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_PanelLt.lua:87: Coudn't enter critical section! If you need more logs, please let me know. I attached also the Q400_GF_PanelLt.lua and NAV1 and NAV2 for your reference. Best regards Reinhard FSUIPC6_1.log FSUIPC6_2.log FSUIPC6_3.log Q400_GF_PanelLt.luaQ400_GF_NAV2.luaQ400_GF_NAV1.lua
  4. Hi, You can of course define differnt profiles for individual aircraft variants. That's not against the concept of profiles. The profiles (especially with the ShortAircraftNameOk=Substring) are useful, if you want to have the same settings in sync for a lot of variants of your aircraft, as assigning and calibrating is a lot of work to keep it consistent. But also your use case is valid for profiles. For your original problem I have no idea, why this happens only for that camera definition. I also use a lot of different camera views in the VC. But I have only one camera definition and set the position and view direction in a LUA program. I have two touchscreens below my curved monitor fo the outside view. On these two monitors I set different views of this special ockpit camera (with no outside visualization) according to a table, which I define per aircraft type. That's just some code pieces out of other functions to give you an idea how to solve this by using LUA. AC.CameraUpCoordL = {} AC.CameraUpCoordR = {} AC.CameraUpCoordL[1] = { 14.0 , 0.00 , 0.00 , -0.26 , -0.35 , 0.3 } AC.CameraUpCoordR[1] = { 14.0 , 0.00 , 0.00 , 0.26 , -0.35 , 0.3 } AC.CameraUpCoordL[2] = { -29.70 , 0.00 , 0.00 , -0.2 , 0.00 , 0.00 } AC.CameraUpCoordR[2] = { -29.70 , 0.00 , 0.00 , 0.2 , 0.00 , 0.00 } AC.CameraUpCoordL[3] = { -52.00 , 0.00 , 0.00 , -0.2 , -0.11 , 0.00 } AC.CameraUpCoordR[3] = { -52.00 , 0.00 , 0.00 , 0.2 , -0.11 , 0.00 } : : -- set cockpit camera for VC function setCameraL ( lCameraCoordList ) ipc.writeSTR ( 0x8680 , "Cockpit Camera - View 01" ) -- select cockpit camera ipc.writeStruct( 0x86A0 , "6FLT" , lCameraCoordList[4] -- X , lCameraCoordList[5] -- Y , lCameraCoordList[6] -- Z , lCameraCoordList[1] -- Pitch , lCameraCoordList[2] -- Tilt , lCameraCoordList[3] -- Heading ) ipc.sleep(100) end function setCameraR ( lCameraCoordList ) ipc.writeSTR ( 0x8680 , "Cockpit Camera - View 02" ) -- select cockpit camera ipc.writeStruct( 0x86A0 , "6FLT" , lCameraCoordList[4] -- X , lCameraCoordList[5] -- Y , lCameraCoordList[6] -- Z , lCameraCoordList[1] -- Pitch , lCameraCoordList[2] -- Tilt , lCameraCoordList[3] -- Heading ) ipc.sleep(100) end : : function setCameras (lPanel) setCameraL ( AC.CameraUpCoordL[lPanel] ) setCameraR ( AC.CameraUpCoordR[lPanel] ) end : : -- sample call for first camera setup setCameras (1) Maybe this is a better method instead of using different camera definitions. And by that you are not limited to the number of hotkeys. Rgds Reinhard
  5. Hi Roger, Ok now your intention is clear. I wonder, how you assign different panel variants, as you reference in both variants in the aircraft.cfg the standandar panel entry: panel= If you have different panel variants, why don't you have here distinct panel references? Are you just not showing the GTN750 in the first variant? Rgds Reinhard
  6. Hi, Some observations - but not related to the specific problem: Your INI file shows some error in the joystick configuration. You should correct this to avoid other problems: [JoyNames] AutoAssignLetters=Yes A=Saitek Pro Flight Quadrant A.GUID={3C53B7E0-BA58-11EB-8001-444553540000} C=Alpha Flight Controls C.GUID={98AE71F0-B7F2-11EB-8002-444553540000} D=Alpha Flight Controls D.GUID={3C53B7E0-BA58-11EB-8001-444553540000} E=Saitek Pro Flight Rudder Pedals E.GUID={502347D0-D007-11EB-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={502347D0-D007-11EB-8001-444553540000} 0=Saitek Pro Flight Quadrant 0.GUID={3C53B7E0-BA58-11EB-8001-444553540000} 2=Alpha Flight Controls 2.GUID={98AE71F0-B7F2-11EB-8002-444553540000} B=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> F=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> You said, that you have setup seperate profiles by intention. What is the reason for that. It's always the same aircraft model and panel behind the scenes. So why not use the same setting for all variants? You have set the parameter ShortAircraftNameOk=Substring for profiles. This would allow you to use one single profile for all of your PA23 variants. In your case this could look like this: [Profile.Alabeo PA23 Aztec F 250] 1=Alabeo PA23 Aztec F 250 [Axes.Alabeo PA23 Aztec F 250] RangeRepeatRate=10 0=AX,256,D,4,0,0,0 -{ DIRECT: Throttle }- 1=AY,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 2=AZ,256,D,6,0,0,0 -{ DIRECT: Mixture }- 3=AU,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 4=AV,256,D,6,0,0,0 -{ DIRECT: Mixture }- 5=EX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 6=EY,256,D,0,8,0,0 -{ DIRECT: RightBrake }- 7=ER,256,D,3,0,0,0 -{ DIRECT: Rudder }- 8=CX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 9=CY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 10=CP,0,F,66416,0,0,0 -{ TO SIM: PAN_VIEW }- [JoystickCalibration.Alabeo PA23 Aztec F 250] AllowSuppressForPFCquad=Yes ExcludeThrottleSet=Yes ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes SepRevsJetsOnly=No ApplyHeloTrim=No UseAxisControlsForNRZ=No FlapsSetControl=0 FlapDetents=No ReverserControl=66292 Reverser1Control=66422 Reverser2Control=66425 Reverser3Control=66428 Reverser4Control=66431 MaxThrottleForReverser=256 AileronTrimControl=66731 RudderTrimControl=66732 CowlFlaps1Control=66162 CowlFlaps2Control=66163 CowlFlaps3Control=66164 CowlFlaps4Control=66165 SteeringTillerControl=0 MaxSteerSpeed=60 Elevator=-16287,-512,512,16319 Throttle=-16384,16255 PropPitch=-16254,16255 Mixture=-16384,16383 Aileron=-16159,-578,512,16383/8 ElevatorTrim=-16380,-512,512,16380 SlopeElevatorTrim=-12 SlopeAileron=-3 LeftBrake=-16384,16383/16 RightBrake=-16384,16383/16 Rudder=-15610,-512,512,15807 SlopeLeftBrake=-8 SlopeRightBrake=-8 SlopeRudder=9 [Buttons.Alabeo PA23 Aztec F 250] 12=RA,1,C66243,0 -{INC_COWL_FLAPS}- 38=RA,0,C66244,0 -{DEC_COWL_FLAPS}- 48=PC,0,C66856,0 -{VIEW_CAMERA_SELECT_6}- 49=UC,0,C66851,0 -{VIEW_CAMERA_SELECT_1}- 52=PC,3,C65561,0 -{PAUSE_TOGGLE}- 53=PC,10,C66858,0 -{VIEW_CAMERA_SELECT_8}- 54=UC,10,C66851,0 -{VIEW_CAMERA_SELECT_1}- 58=PA,3,C65758,0 -{FLAPS_INCR}- 60=PA,4,C66079,0 -{GEAR_UP}- 61=PA,5,C66080,0 -{GEAR_DOWN}- 62=PA,2,C65759,0 -{FLAPS_DECR}- 63=RC,7,C66855,0 -{VIEW_CAMERA_SELECT_5}- 65=PC,6,C66857,0 -{VIEW_CAMERA_SELECT_7}- 66=PC,11,C66859,0 -{VIEW_CAMERA_SELECT_9}- 67=UC,11,C66851,0 -{VIEW_CAMERA_SELECT_1}- 72=PC,28,C66052,0 -{STROBES_ON}- 73=PC,29,C66053,0 -{STROBES_OFF}- 83=PC,1,C66579,0 -{TOGGLE_CABIN_LIGHTS}- 84=RC,5,Cx42000BC0,xC0010100 -{offset sword decrement, offset 0BC0 (Decr=256, Limit=-16383)}- 85=RC,4,Cx32000BC0,x3FFF0100 -{offset sword increment, offset 0BC0 (Incr=256, Limit=16383)}- 86=PC,22,C66237,0 -{FUEL_PUMP}- 87=PC,23,C66237,1 -{FUEL_PUMP}- In that profile the WHITE and the F-BALY would be covered by the same profile. And by that you only have to configure your axis, buttons, etc. only once. And if it works in one variant, it works for all variants. Btw.: Your configurations differ quite a lot between the WHITE and the F-BALY profile. So you are using axis assignments for missing joysticks in parallel with axis assignments for the same axis for existing joysticks. No idea, what your intention you had here. This doesn't solve your problem, but any error in a configuration could lead to other errors. So I would first try to eliminate those errors. Rgds Reinhard
  7. Hi, I am sorry - but this version does not start at all on my machine. It's simply not loaded, when I replace the original DLL by your version. There is no error generated. But FSUIPC menu is not appearing and no log is generated. Replacing this file again with the original DLL it's working again and FSUIPC is started. Rgds Reinhard
  8. As in other modules: I have several events registered - the event.button triggers are firing (i see, that the switches are operated in the cockpit) but the event.offset, which should tun on the LED on the GF module, when the battery switch is on, did not fire, although the offset did change, which I verified by FSInterrogate. So it's always the same scenarion: The module is running - most of the events are handled as expected - and one or two out of them are not working, although the trigger should fire them. That's exactly what I am observing: debugging and logging makes it impossible to reproduce. And also it's occuring randomly and in different modules. My observation is, that it occurs more often in modules, which are sterted later, when other modules are already running and a lot of events are alredy actively monitoring the trigger condition. I observerd the phenomen most likely with event.offset and event.offsetmask triggers. I will try with the new DLL this evening. I am happy, that you also had a chance to see it. I was alredy seriously thinking of a complet new setup of my machine, what would be an enourmous effort with all the sceneries and planes. As I am typically very carefully with my installations, I never had to do this step in the past. Of course for new major versions of the sim I did it anyhow. Best regards Reinhard
  9. Hi, I am away at the moment of my simulator, so I can't cross check. But I use it with the A320. And as far as I remember, it worked as planned. Rgds Reinhard
  10. Hi, I did two test runs with the attached DLL. The first run was done without extra debugging. And COM1 and NAV1 did not execute the event.offset triggers. But the log looks normal. Then I started with full logging enabled. COM1 was working here normally. But some other modules (like GF_BAT.lua) did not completely work as expected, although they show normal behaviour in the log file. I did disable the module with the event.timer function, as otherwise the log would have exploded. I am the next two days on a conference. So I will continue testing on the weekend. Rgds Reinhard FSUIPC6_COM1_NAV_error.log FSUIPC6_Full.log
  11. Hi, You are correct in all of your assumptions. I define one range to arm the spoilers when I move the lever into that range and to disarm, when I leave this area. Then there is a detent at my lever. In the range of this detent I want to be sure, that the spoiler is off. That's why I trigger an spoiler off command in that area. And then there is the range, where the spoiler axis is sent to the simulator. On page 38 of the FSUIPC6 User Guide you will find the screenshots, how to define commands for ranges of an axis. Rgds Reinhard
  12. Hi, I also thought, that I hit a hard coded limit, but this must have been introduced with P3D 5.2. Until this version this never happened. I use this method to start my necessary modules per aircraft since FSX times already. And yes - if more modules are loaded, the probability, that it occurs, raises. If I enable logging from the beginning, I was not yet able to reproduce it until so far. Maybe the monitoring/logging influence the startup. But I will continue to try to reproduce it. I also did some experiments by delaying the start. I extended the ipc.sleep call between each ipc.runlua call in my starting loop. But even if I waited 5 seconds between each single ipc.run call, it happened sometimes. The Q400_GF_COM1.lua is one of the modules which are loaded quite late in sequence. And with that module it happens quite often compared to others. So a lot of other modules and events monitored are already active during start. The other modules COM2, NAV1 and NAV2 are also candidates. For these modules it's easy to detect, because in most cases the event.offset triggers are effected and in that case my displays on the GoFlight hardware stay dark. Yesterday I had similar problems in the Q400_GF_EFIS.lua, where all events have been working but the one for increasing the QNH did not trigger the function. I manually restarted the module and in the 3rd attempt I got it working normally. So it's randomly occuring in different modules. I plan also to reinstall all Microsoft Visual C++ runtimes completely new, as at the time of my upgrade to 5.2 there was also a major Windows update (2021-06 Windows 10 21H1) to be sure, that this isn't the reason. This cleaning helped in the past with several problems. My system is stable and I have frames limited to have enough CPU capacity available. I assigned cores with enough headroom of capacity to LUA and FSUIPC via an affinity mask. My sim is running completely stutter free. So load should not be a problem. At the moment I am only able to fly the MD 530 helicopter or similar simple aircrafts. Q400 or A320 are always a challenge, if you detect that one button is not working as expected ๐Ÿ˜‰ Rgds Reinhard
  13. Hi, I have no knowledge about the PMDG, but did you calibrate the spoiler axis: Spoilers=-16380,16380/16 My entry, where I have specified the range, which should control the spoiler, looks different to yours. And the range for arming the spoiler and for turning it off is also missing. Pete gave you already the hint to define this region for arming/disarming. Rgds Reinhard
  14. Hi, I have configured my GoFlight spoiler in the Aerosoft A3xx profile like this: [Axes] : : 5=GX,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 6=GX,B,12518,16383,66066,0,66067,0 -{ DIRECT: SpoilersEntering=SPOILERS_ARM_ON, Leaving=SPOILERS_ARM_OFF }- 7=GX,B,8836,11413,66065,0 -{ Entering=SPOILERS_OFF }- : : [JoystickCalibration] : : Spoilers=-4608,15018/16 Rgds Reinhard
  15. Yes - the issue in the trace above occured with only one module running. Although th probality, that it happens, increases with the number of modules running. I run a similar module setup for the AS Twin Otter (with less modules) and there it was not happening so far. With the AS320 it also happens. I did some more tests and add the logfiles here. FSUIPC6_your_module.log I started only your module (I changed the name to GF_Test, as I have already a button assignment to start this specific module for test purposes). I also changed the button to trace to the GoFlight rotary for COM1 (143/8..15 instead of 175/0..7). With logging enabled it always worked and I could not reproduce. FSUIPC6_all_modules_started.log I started all my modules (but omitted the one with the event.timer function) with the full logging turned on. And I was not able to reproduce the error in that mode. FSUIPC6_normal.log I started all my modules including the one with the event.timer trigger but with only logging the COM1 offsets. I was not able to reproduce the error. FSUIPC6_COM1_error.log I started the test with all my modules a second time and in that run COM1 event functions, which should display the frequencies have not been triggered. In the log you see in that line, that I started the module out of my loop across all modules: 202375 LUA.8: LUA\Q400\Q400_GF_COM1 started After detecting, that COM1 was not working as expected, I enabled full logging again (see line 265609). By enabling the logging for the LUA modules, it showed, that COM1 did not show up in the list of modules waiting for an event (like all other modules), although the module was started and there are definitely event triggers defined. Shutting down the simulator closes all modules. But COM1 also never showed up in the logfile during shutdown. So it must have been in a type of inactive state. Very strange. Reinhard FSUIPC6_your_module.log FSUIPC6_all_modules_started.log FSUIPC6_normal.log FSUIPC6_COM1_error.log
  16. One of my plugins use the event.timer function and runs some code every second. By that the logfile get's quite big and cluttered and it's hard to read. But I will do as advised. I added for one single module to each of the button event functions a simple ipc.log line and I started only this single module (Q400_GF_COM1 from above). So there was only one module running. The logfile extract simply shows, that one of the functions (IncCOM10) fired during the event registrations, although buttons never should fire the function during event registration. At several runs I even got two or three functions firing without touching any button. I will test your script, when I return to home. Many thanks for taking care. Best regards Reinhard
  17. These errors are only raised, if I use the Majestic Q400. These errors are shown since all versions of the Q400 for P3D (and as far as I remember even with FSX). I did a fresh installation for all major versions of P3D and always install the updates according to the proposed procedure. Other planes don't show these errors. Also other users have these errors in the logfile, if they use the Q400: https://forum.simflight.com/topic/91564-have-to-hit-reload-all-buttons-every-time/ Rgds Reinhard
  18. Hi, Another strange finding: I added debugging info to the module above, as I found, that starting of the module increased my standby frequency. So I added simple logging code to the modules: function IncCOM10 (joynum, button, downup) ipc.log("IncCOM10") IncDecCOM1 (25) end function IncCOM11 (joynum, button, downup) ipc.log("IncCOM11") IncDecCOM1 (100) end function IncCOM12 (joynum, button, downup) ipc.log("IncCOM12") IncDecCOM1 (1000) end function IncCOM13 (joynum, button, downup) ipc.log("IncCOM13") IncDecCOM1 (1000) end function DecCOM10 (joynum, button, downup) ipc.log("DecCOM10") IncDecCOM1 (-25) end function DecCOM11 (joynum, button, downup) ipc.log("DecCOM11") IncDecCOM1 (-100) end function DecCOM12 (joynum, button, downup) ipc.log("DecCOM12") IncDecCOM1 (-1000) end function DecCOM13 (joynum, button, downup) ipc.log("DecCOM13") IncDecCOM1 (-1000) end When I registered the buttons: -- register button events up/down event.button(GF_JoyLetter, GF_Button, 3, "DecCOM13") event.button(GF_JoyLetter, GF_Button+1, 3, "DecCOM12") event.button(GF_JoyLetter, GF_Button+2, 3, "IncCOM12") event.button(GF_JoyLetter, GF_Button+3, 3, "IncCOM13") event.button(GF_JoyLetter, GF_Button+4, 3, "DecCOM11") event.button(GF_JoyLetter, GF_Button+5, 3, "DecCOM10") event.button(GF_JoyLetter, GF_Button+6, 3, "IncCOM10") event.button(GF_JoyLetter, GF_Button+7, 3, "IncCOM11") One of the routines fired during registering the event. But only one. No other modules have been running. So this is the only module active at that time: 5608297 LUA: "GF_Test.lua": killed 5626125 LUA.69: IncCOM10 It's getting even more strange. Rgds Reinhard
  19. Hi, After writing this post, I started my modules again with logging enabled as suggested. I incremented the standby frequency, the button event was trapped and the offset for the standby frequency of COM1 changed - but the event.offset trigger never fired: 3338203 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338437 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00000000} 3338437 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338453 Monitor IPC:311A (U16) = 6512 3338500 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338734 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338734 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00004000} 3338734 Monitor IPC:311A (U16) = 6514 3338797 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3339078 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00000000} 3339078 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3339109 Monitor IPC:311A (U16) = 6517 3339172 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" All the other offset triggers worked as expected. Here the swap of frequencies, which changes the offset of COM1: 4199766 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00004001} 4199781 LUA.58: Button event: calling "SetCOM1Swap" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4199797 FS Control Sent: Ctrl=66372, Param=0 COM_STBY_RADIO_SWAP 4199828 Monitor IPC:034E (U16) = 6519 4199828 SimRead: 034E="COM ACTIVE FREQUENCY:1" INT32: 6519 (0x00001977) 4199828 Monitor IPC:311A (U16) = 8544 4199828 SimRead: 311A="COM STANDBY FREQUENCY:1" INT32: 8544 (0x00002160) 4200016 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4200016 LUA.58: Offset Change event: calling "DispCOM1" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4200016 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" Both offsets changed, but only DispCOM1 was executed while DispCOM1Stby never was triggered. Rgds Reinhard
  20. Hi, I did deeper analysis with one module, where this phenomenon did happen more often than at others. For handling COM1 (or COM2) via my GoFlight module I use the following module: -- Q400_GF_COM1.lua -- V1.3 -- Q400 implementation of the GF COM1 -- include GF variables require "GF_Variables" local GF_Model = GF166 -- name of device local GF_Unit = GFHW.GF_166_1 -- Id (default=0) local GF_JoyLetter = GFHW.GF_166_Joy_1 -- Joy-Letter of switch/button local GF_Button = GFHW.GF_166_Sel_1 local GF_JoyButtonSwap = GFHW.GF_166_But_1 -- Joy-Button of toggle switch/button local GF_JoyButtonID1 = GF_JoyButtonSwap + 1 -- Joy-Button of switch/button local GF_JoyButtonID2 = GF_JoyButtonSwap + 2 -- Joy-Button of switch/button local GF_Id_COM11 = 0 -- Id of COM11 local GF_Id_COM12 = 1 -- Id of COM12 local GF_Id_ID1 = 1 -- Id of LED 1 local GF_Id_ID2 = 2 -- Id of LED 2 -- define P3D controls require "P3D_Controls" -- define XML interface require "Q400_Write_XML_IF" function IncDecCOM1 (pStep) local lValue2 = string.format( "%04X", ipc.readUW(0x311A) ) local lCOM1 = lValue2 * 10 + 100000 local lFract = 0 local lCorr = 0 lCOM1 = lCOM1 + pStep if lCOM1 < 118000 then lCOM1 = 118000 end if lCOM1 > 136975 then lCOM1 = 136975 end lFract = lCOM1 % 100 if lFract == 25 or lFract == 75 then lCorr = -5 end if lFract == 45 or lFract == 95 then lCorr = 5 end lValue2="0x"..math.floor( (lCOM1+lCorr-100000) / 10 ) ipc.writeUW(0x311A, lValue2+0) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , lCOM1+lCorr - 100000 ) end function IncCOM10 (joynum, button, downup) IncDecCOM1 (25) end function IncCOM11 (joynum, button, downup) IncDecCOM1 (100) end function IncCOM12 (joynum, button, downup) IncDecCOM1 (1000) end function IncCOM13 (joynum, button, downup) IncDecCOM1 (1000) end function DecCOM10 (joynum, button, downup) IncDecCOM1 (-25) end function DecCOM11 (joynum, button, downup) IncDecCOM1 (-100) end function DecCOM12 (joynum, button, downup) IncDecCOM1 (-1000) end function DecCOM13 (joynum, button, downup) IncDecCOM1 (-1000) end function readCOM1 () local lValue2 = string.format( "%04X", ipc.readUW(0x034E) ) local lCOM1 = lValue2 * 10 local lFract = 0 local lCorr = 0 lFract = lCOM1 % 100 if lFract == 20 or lFract == 70 then lCorr = 5 end lValue2 = lCOM1 + lCorr return lValue2 end function readCOM1Stby () local lValue2 = string.format( "%04X", ipc.readUW(0x311A) ) local lCOM1 = lValue2 * 10 local lFract = 0 local lCorr = 0 lFract = lCOM1 % 100 if lFract == 20 or lFract == 70 then lCorr = 5 end lValue2 = lCOM1 + lCorr return lValue2 end function DispCOM1(offset, value) -- react on P3D Input gfd.SetDisplay( GF_Model, GF_Unit, GF_Id_COM11, string.format( "1%02X.%02X", math.floor( ipc.readUW(0x034E)/256 ) , ipc.readUW(0x034E) % 256 ) ) end function DispCOM1Stby(offset, value) -- react on P3D Input gfd.SetDisplay( GF_Model, GF_Unit, GF_Id_COM12, string.format( "1%02X.%02X", math.floor( ipc.readUW(0x311A)/256 ) , ipc.readUW(0x311A) % 256 ) ) end function DispCOM1Id(offset, value) -- react on P3D Input if logic.And(value, 0x80) == 0x80 then gfd.SetLight( GF_Model, GF_Unit, GF_Id_ID1 ) else gfd.ClearLight( GF_Model, GF_Unit, GF_Id_ID1 ) end if logic.And(value, 0xA0) ~= 0x00 then gfd.SetLight( GF_Model, GF_Unit, GF_Id_ID2 ) else gfd.ClearLight( GF_Model, GF_Unit, GF_Id_ID2 ) end end function SetCOM1Swap(joynum, button, downup) -- react on GF Input P3D_Ctrl.P3D_COM_STBY_RADIO_SWAP ( 0 ) ipc.sleep(100) writeXMLIF ( Q400_XML.ARCDUCOM1Freq , readCOM1 () ) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , readCOM1Stby () ) end function SetCOM1ID1(joynum, button, downup) -- react on GF Input writeXMLIF ( Q400_XML.ARCDUMicSelector , 1 ) ipc.clearbitsUB(0x3122, 0x60) ipc.setbitsUB(0x3122, 0x80) end function SetCOM1ID2(joynum, button, downup) -- react on GF Input ipc.togglebitsUB(0x3122, 0x20) end -- initialize COM1 writeXMLIF ( Q400_XML.ARCDUCOM1Freq , readCOM1 () ) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , readCOM1Stby () ) -- track every change of the P3D offsets event.offset( 0x034E, "UW", "DispCOM1" ) event.offset( 0x311A, "UW", "DispCOM1Stby" ) event.offset( 0x3122, "UB", "DispCOM1Id" ) -- Swap COM1 frequencies event.button( GF_JoyLetter , GF_JoyButtonSwap , 1 , "SetCOM1Swap" ) event.button( GF_JoyLetter , GF_JoyButtonID1 , 1 , "SetCOM1ID1" ) event.button( GF_JoyLetter , GF_JoyButtonID2 , 1 , "SetCOM1ID2" ) -- register button events up/down event.button(GF_JoyLetter, GF_Button, 3, "DecCOM13") event.button(GF_JoyLetter, GF_Button+1, 3, "DecCOM12") event.button(GF_JoyLetter, GF_Button+2, 3, "IncCOM12") event.button(GF_JoyLetter, GF_Button+3, 3, "IncCOM13") event.button(GF_JoyLetter, GF_Button+4, 3, "DecCOM11") event.button(GF_JoyLetter, GF_Button+5, 3, "DecCOM10") event.button(GF_JoyLetter, GF_Button+6, 3, "IncCOM10") event.button(GF_JoyLetter, GF_Button+7, 3, "IncCOM11") COM2, NAV1 and NAV2 are implemented in a similar way. When I start my modules, quite often one of the event.offset triggers will not work. Sometimes it's the one for COM1 , sometimes it's the event for the COM1 standby frequency. And sometimes they work normally. And sometimes it's happening at COM2, NAV1 and NAV2. What I have found is the fact, that's always one of the event.offset triggers, which are not firing. I checked with FSInterrogate, that the offse IS changing so the event normally must fire. And the code wasn't changed since all versions of P3D. This strange behaviour started with P3D 5.2. For me there is no reason, why one of these events should not work, while all the others in the module are working. Of course there is no error in the logfile and the offset is changing, which I checked by logging and by FSinterrogate. I start about 40 modules for my hardware components all of similar complexity like this one. Other modules show the same random behaviour - but not so often as the radio modules. I really have no idea, what I should change, that all events are trapped. And I have no idea, how I could support you to reproduce this issue. Rgds Reinhard
  21. Hi, I did the same test as above with event.button. It's not firing ast stated by you. event.Lvar is triggering the function when registering the event (same as with event.offset). Rgds Reinhard
  22. Hi, Thanks for looking at this issue. I am fine, if it is always the case., that it fires during registration. In that case I could take care for it in my code. In fact I didn't care in the past ๐Ÿ˜‰ For events, delivering some values (like COM frequency etc.) it's fine and useful to get the initial value, as you wrote. Therefore also for most of my plugins this was not a problem. For button events, this is more problematic, as this could produce unwanted effects (e.g. increasing the COM frequency), although the button was not pressed, just because I started my LUA plugin. Therefore I wanted to know, if this is always th case, as I then have to ignore the first button press. If you register increase and decrease frequency in the same plugin, they compensate even if they are fired. For the event not registering I did also some investigation as John proposed. I will give an example and explanation in the other thread. During writing this reply, I saw, that John answered, that it's by intention and that it's documented. Shame on me - I overlooked this obviously. I will go back to documentation and check, if this is also the case for the other types of events. Best regards Reinhard
  23. Hi, A question for Pete and John: Is it by intention, that the registration of an event immediately fires the related function, although the event didn't occur? I made a small sample module for easy testing. I just monitored the COM1 offset for changes and traced the firing of the related function. In my function I also tracked, if the function is called the first time or if it has already be run. Here is the simple module: -- Test event.offset function with COM1 offset ipc.log("---------------------------------") local vFirstRun = 0 ipc.log("vFirstRun = 0") function LogCOM1(offset, value) -- react on FSX Input ipc.log("Start LogCOM1") if vFirstRun == 1 then ipc.log( string.format( "1%02X.%02X", math.floor( ipc.readUW(0x034E)/256 ) , ipc.readUW(0x034E) % 256 ) ) else -- first run due to event registration done - now code can be activated vFirstRun = 1 ipc.log("vFirstRun = 1") end ipc.log("Leave LogCOM1") end -- track every change of the COM1 offset ipc.log("Define event") event.offset( 0x034E, "UW", "LogCOM1" ) ipc.log("Event defined") That's what i find in the log: ********* FSUIPC6, Version 6.1.4 (28th July 2021) by Pete & John Dowson ********* Prepar3D.exe version = 5.2.22.27615 Running inside Prepar3D v5 Module base=7FFE660E0000 Windows 10 Home 64 Bit reported as Build 19043, Release ID: 2009 (OS 10.0) Reading options from "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\FSUIPC6.ini" Checking the Registrations now ... User Name="xxx" User Addr="xxx" FSUIPC6 Key is provided WideFS7 Key is provided 0 System time = 28/08/2021 18:34:39 0 FLT UNC path = "\\PC-P3D\P3D_Files\" 0 NOTE: configuring for no weather reads or writes! 0 Using DialogMode 16 FS UNC path = "\\PC-P3D\P3Dv5\" 79 Finished: 0 Profile files created 79 ---------------------- Joystick Device Scan ----------------------- 94 Product= JoyWarrior A8-8 94 Manufacturer= Code Mercenaries 94 Vendor=07C0, Product=1104 (Version 16.48) 110 GUIDs returned for product: VID_07C0&PID_1104: 110 GUID= {BABB2690-FB55-11E9-8001-444553540000} 110 Details: Btns=8, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X241,Y127,Z127 110 Product= TQ6 125 Manufacturer= GoFlight 125 Serial Number= 00080 7 125 Vendor=09F3, Product=0200 (Version 2.0) 125 GUIDs returned for product: VID_09F3&PID_0200: 125 GUID= {CE023EC0-9A8D-11E8-800E-444553540000} 125 Details: Btns=4, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R221,U216,V221,X220,Y221,Z214 125 Product= Saitek Pro Flight Yoke 125 Manufacturer= Saitek 125 Vendor=06A3, Product=0BAC (Version 3.2) 125 GUIDs returned for product: VID_06A3&PID_0BAC: 125 GUID= {CDFBFD30-9A8D-11E8-800C-444553540000} 125 Details: Btns=23, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U255,V255,X1023,Y1023,Z255 125 Product= Saitek Pro Flight Rudder Pedals 125 Manufacturer= Saitek 125 Vendor=06A3, Product=0763 (Version 1.0) 125 GUIDs returned for product: VID_06A3&PID_0763: 125 GUID= {CDFBFD30-9A8D-11E8-800B-444553540000} 125 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R511,U0,V0,X127,Y127,Z0 125 ------------------------------------------------------------------- 125 Device acquired for use: 125 Joystick ID = 3 (Registry okay) 125 3=JoyWarrior A8-8 125 3.GUID={BABB2690-FB55-11E9-8001-444553540000} 125 Device acquired for use: 125 Joystick ID = 2 (Registry okay) 125 2=TQ6 125 2.GUID={CE023EC0-9A8D-11E8-800E-444553540000} 125 Device acquired for use: 125 Joystick ID = 0 (Registry okay) 125 0=Flight Yoke System 125 0.GUID={CDFBFD30-9A8D-11E8-800C-444553540000} 125 Device acquired for use: 125 Joystick ID = 1 (Registry okay) 125 1=Saitek Pro Flight Rudder Pedals (USB) 125 1.GUID={CDFBFD30-9A8D-11E8-800B-444553540000} 125 ------------------------------------------------------------------- 438 Controllers are set to ON, using RawInput within P3D 438 LogOptions=00000000 00000001 438 ------------------------------------------------------------------- 438 SimConnect_Open succeeded: waiting to check version okay 438 Opened separate AI Traffic client okay 8891 Running in "Lockheed Martinยฎ Prepar3Dยฎ v5", Version: 5.2.22.27615 (SimConnect: 5.2.0.0) 8891 Initialising SimConnect data requests now 8891 FSUIPC Menu entry added 8907 ... Using Prepar3D with Professional License 8922 \\PC-P3D\P3D_Files\P3D.fxml 8922 \\PC-P3D\P3D_SimObj\Airplanes\mjc8q400\MJC8Q4.air 9219 ### The user object is 'MJC8Q400_AUA_OE-LGM' 9219 ### Mode: FREEZE_ATT on FREEZE_ALT on FREEZE_LATLON on 14563 Monitor IPC:311E (U16) = 0 14579 ### Mode: PAUSE on 116422 Loading Complete ... 116438 ### Mode: PAUSE off 116922 User Aircraft ID 1 supplied, now being used 116922 Aircraft loaded: running normally now ... 116969 Monitor IPC:311E (U16) = 5664 116969 SimRead: 311E="NAV STANDBY FREQUENCY:1" INT32: 5664 (0x00001620) 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2898, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:1" 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2899, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:2" 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2900, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:3" 117532 System time = 28/08/2021 18:36:37, Simulator time = 10:00:02 (08:00Z) 117766 Aircraft="MJC8Q400_AUA_OE-LGM" 123547 -------------------- Starting everything now ---------------------- 123547 Starting WideServer now ... 123563 Using "C:\Program Files (x86)\GoFlight\GFDEV64.DLL", version 2.2.8.0 123563 GoFlight GFT8 detected: 1 device 123563 GoFlight GF166 detected: 5 devices 123563 GoFlight GFRP48 detected: 2 devices 123563 GoFlight GF46 detected: 1 device 123563 GoFlight GFTQ6 detected: 1 device 123563 GoFlight GFLGT2 detected: 1 device 123563 GoFlight GFMCPPRO detected: 1 device 123563 GoFlight GFEFIS detected: 2 devices 123563 GoFlight GFWP6 detected: 2 devices 123625 Run: ""C:\Users\Reinhard\AppData\Local\vPilot\vPilot.exe" "-host"" 123625 Affinity Mask set to 20 [x14], "vPilot.exe" 123625 ASN active function link set 123625 Ready for ActiveSky WX radar with additional data : : Here comes the debug log with logging on for offset 0x034E (=COM1) : 8030250 LUA.74: --------------------------------- 8030250 LUA.74: vFirstRun = 0 8030250 LUA.74: Define event 8030266 LUA.74: Event defined 8030266 LUA.74: Start LogCOM1 8030266 LUA.74: vFirstRun = 1 8030266 LUA.74: Leave LogCOM1 8035625 Monitor IPC:034E (U16) = 13376 8035625 SimRead: 034E="COM ACTIVE FREQUENCY:1" INT32: 13376 (0x00003440) 8035625 LUA.74: Start LogCOM1 8035625 LUA.74: 134.40 8035641 LUA.74: Leave LogCOM1 So as you can see, the function is fired immediately, when I register the offset, although frequencydid not change. I would have expected, that it fires, if the frequency changes for the first time. Later I switched frequencies and then it fires the second time and by that logs the frequency. As a consequence I would have now to add similar code to all my event functions, to avoid firing during the event registration process. Maybe you can check, if this behaviour is by intention. I had already in the past the feeling, that this happens, but did not consequently trace it down. As I currently have massive problems, where events are not registered although they are defined in the same way since many years, I try to nail my problem down. During these investigations (see thread: https://forum.simflight.com/topic/92801-p3d-52-lua-event-handling-not-reliable/ ) I came across this issue. If this is always working for all type of events in that way, I can add code to my modules, to avoid this firing. But before doing this, I want to be sure, if this behaviour is planned. Thanks in advance. Reinhard
  24. Hi, If links for downloading are not working, you can try to: Left-click on the link and copy the Link-URL Open a new tab in the browser and past the copied link in the address field With that method you are able to download the files. 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.