aua668

Hi, These macros work for me to toggle Bat1 and Bat2: [Macros] Module="EJet.gau" 1=Bat1=RXdbb60*X8bcc 2=Bat2=RXdbba0*X8bcc Rgds Reinhard

Hi, Don't try to check, if spoilers are working, on the ground. This is a FS behaviour. Try it in the air. Rgds Reinhard

Hi, You must do something completely wrong. I also have the GF-TQ6 and it perfectly works with all my planes. You should check, if you also have assigned the flaps axis in the simulator. Before assigning axis via FSUIPC be sure to clear all assignments in the sim. That's in most cases the error. Rgds Reinhard

Hi, It's possible to define camera hotkeys either in the CAMERAS.CFG or in the AIRCRAFT.CFG. The only thing you have to avoid is of course conflicts. So if you have same hotkeys in both files, I don't know, how the simulatore reacts. So you must check, if you have some double assignments. Did you load the C172 from a flight file? Also in the flight file you might have a camera definition included. Rgds Reinhard

Hi, Some questions: Did you define the camera views in the aircraft.cfg (or in the camera.cfg) ? Which simulator is used? How did you assign the several views to buttons? Show the button assignment in the FSUIPC.INI (or in the aircraft specific profile, if you have used this method). Rgds Reinhard

Hi, Here you find an useful utility analyzing your USB devices: http://www.nirsoft.net/utils/usb_devices_view.html Rgds Reinhard

Hi, It's not fixed in P3D 2.5 at least :-( Rgds Reinhard

Pete, Thanks for clarification. I will take care for getting the initialization in sequence on my own. No need to change the code. It was just to check, if this option might avoid the concurrent writing. It's better to avoid it by programming already on my side :mrgreen: Thank you! Reinhard

Pete, At normal operation by the pilot it's not a factor, as in most cases you don't operate two sitches exactly at the same time. Or at least you can avoid it. The problem is typically in the initialization phase, where you start all the LUA modules in parallel. And as I have to synchronize the hardware position of the switch (I might have left the switch on, when I left) with the actual state in the sim, all the modules do some similar synchronization. They are checking the hardware button state and switch the panel button to the same position (on/off). By that I can restart my complete LUA modules without reloading the plane. I already use the event system to program these modules. So compilation time of a larger module is no problem. And it's not this event based code creating problems, but just the initialization sequence. So I will move this initialization code out of the several event driven switch modules and by that I can control the sequence. Another option is to time the initialization calls of the several modules as it doesn't matter, if the sync is done immediately or 10 seconds later - it has just do be done once, when I startup my LUA modules. One question was not answered clearly enough (and maybe it's not easy to answer for you too): Are multi action macros (e.g. doing first the right single and then the right release click) treated as one sequence, which can't be interrupted by another mouse action? If so, I could create combined macros and have only one ipc.macro call in LUA (instead of calling the same mouse macro with the several parameters in sequence in LUA). This would be a simple change. Anyhow I will try to find out, if this is a solution too. I just thought, you might have a hint for me, which direction would be the best. Many thanks for you valuable input. Reinhard

Pete, One question to the expert about mouse macros: Some addon aircrafts need for trigggering actions mouse macros, which explicitely implement first the button down event and then the button release event. So the single click alone will not operate the switch. With the mouse parameters that easily can implemented. So in LUA you end up with code like this: ipc.macro ("Q400:AIceStruct" , 31 ) -- right single ipc.macro ("Q400:AIceStruct" , 19 ) -- right release If I have code segments like this in several LUA modules, there might be a conflict, as such macro calls might run in parallell at the same time. And by that they are influencing/disturbing each other. The sequence can not be guaranteed. I experienced such a situation especially in the initialization phase, where all the LUA module try to synchronize with switches and by that firing some mouse macros. So the question is: If I would create a multi action macro out of these commands, are these commands then executed in one sequence without disturbance? LUA threads are obviously completely independent and therefore you are not able to control the actual sequence, when more than one module is using mouse macros at the same time. In normal operation this is typically no factor, as you trigger one switch at one time. Best regards Reinhard

Hi, I just want to provide feedback to other users, that with the correction of the setbits, clearbits and togglebits functions there might be some other side effects, which were not visible by the bug. I have several hardware switches with LEDs, which I connected to FS with some small LUA scripts. All these scripts are event triggered and have two major elements: a switch function triggered by the hardware switch via event.button a display function triggered by monitoring an offset via event.offset writing to an user offset, which is controlling my LEDs Under these I had some switches driving standard FS lights via offset 0x0D0C. As this was an quite old code from FS9 times, I had used event.offset, as event.offsetmask have not been available in that version. So whenever one of the switches was switched, the event offset in all modules fired. I checked in the display function for the bit for the specific light and set or cleared the bit in my LED ouput offset. This worked, as writing and reading was done to the same memory location (by the bug now fixed). So setting and clearing bits - even if done in within a short time frame (as all events fired at the same moment) did work. By using now different read and write memory locations and the asynchronous behavior of simconnect suddenly this did not work any longer. But it's an easy fix. i had just to change to the event.offsetmask function and now everything is fine again. So as a conclusio: If you have used event.offset for an offset like the 0x0D0C (lights) in several areas of your code, you should change them to event.offsetmask to avoid some side effects after this bug fixing. Maybe this helps some other people, experiencing some strange behaviour after this change. Best regards Reinhard

Pete, I tested now version 4.949e with several aircrafts. And it worked absolutely fine! Thanks for checking and fixing this issue so quickly. Best regards Reinhard

Hi, I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't. Rgds Reinhard

Hi, Instead of creating different cameras for each view, you can create the different camera types (cockpit, flyby, etc.) and set camera position and view direction with the function mentioned above. So open the necessary windows (and I assume that it are less than ten) and with the function you are able to control these cameras. Rgds Reinhard

Pete, I tested with the following code: ipc.writeUB(0x029C,0x01) ipc.sleep(1000) ipc.writeUB(0x029C,0x00) And guess: everything works. The switch moves and the pitot is set on and off. With ipc.togglebitsUB(0x029C,0x01) it does not move - independent which bits I toggle. I tried with all bits. I traced with FSInterrogate and the correct bits were toggled. But the Switch doesn't move. And I also traced it in the FSUIPC.log: 1075408 Monitor IPC:029C (U8) = 0x0 1087249 Monitor IPC:029C (U8) = 0xFF 1088715 Monitor IPC:029C (U8) = 0x0 1089823 Monitor IPC:029C (U8) = 0xFF 1090665 Monitor IPC:029C (U8) = 0x0 1097545 Monitor IPC:029C (U8) = 0x1 1098543 Monitor IPC:029C (U8) = 0x0 As a gauge can't react on offsets but only on key events, it seems, that by ipc.togglebitsUB the event PITOT_HEAT_TOGGLE is not triggered. But by simply writing to that offset it's fired obviously I did trace the events fired and at writing the offset I find the PITOT_HEAT_TOGGLE event in the log: 1768489 *** EVENT: Cntrl= 65858 (0x00010142), Param= 0 (0x00000000) PITOT_HEAT_TOGGLE But with the togglebits function no event is written in the log. Rgds Reinhard  

Hi Pete, Since that change in 4.949c I have a problem with the ipc.togglebits function. At my Dodosim B06 helicopter I used ipc.togglebits(0x029C,0x01) for toggling the pitot heat switch. And with the FSUIPC versions before, also the switch in the panel moved. Since 4.949c in P3D 2.5 the offset ist toggled, but the switch in the panel doesn't move anymore. If I use alternatively the ipc.control(65858) for toggling the pitot heat, the switch moves again. It looks like, that with the change you made, that there is a different behaviour than before. Toggling the bit has a different effect than calling the ipc.control for the gauge. I could see the same effect at the GPS/NAV button. Maybe others are also working different now. Best regards Reinhard

Hi, First character U=Unsigned and S=Signed Second character B=Byte, W=Word (=2 Bytes), D=Double (=4 Bytes). 1 Byte = 8 bits = 0..255 I don't know the Airbus interface but that's the logic behind the several ipc.writeXY() functions. Rgds Reinhard

Hi, A lot of your questions are answered in the global description of events, which is also valid for the event.timer function: So the LUA plugin is waiting/dormant until the event occurs - so no CPU factor. And the exit can be realized via ipc.exit function. From my personal experience I can tell you, that this comcept is working perfectly and without any impact on performance. Rgds Reinhard

Hi, For the Saitekmode switch a simple search in the forum shows this result: http://forum.simflight.com/topic/80345-just-registered-saitek-yoke-mode-1-2-3-question/?p=485423 Rgds Reinhard

Hi, As this is part of a large number of LUA modules, I will extract these things to show, how it could be used. I will need some time, but of course I will share this. Rgds Reinhard

Hi Pete, I detected, that you have uploaded version 4.948e. I downloaded this version, installed it and it works great !!! Christmas is here :razz: :razz: :razz: To give you an impression, how I use this function: I have a setup with three screens for the outside world and two touch screens below for the panels. With that I fly several planes (Fokker 100, Airbus, Dash 8 Q400, Twin Otter). Especially with the newer planes with virtual cockpits only you have to create several camera views so that you can switch through the several views easily. But you have only 10 hotkeys for cameras. So you can navigate to a special view not directly but only by stepping through views. With that function I use only one cockpit camera, I define the several views in a LUA table and I can reach each camera per index. So no limit of hotkeys anymore. It's really great, how your program improves missing or limited functionality. Many thanks To Santa Pete ... Reinhard

Pete, I checked the standard camera names of P3D. The simulator adds to hese names typically " - View xx": Cockpit - View 00 Virtual Cockpit - View 00 Spot - View 00 Locked Spot - View 00 FlyBy - View 00 Top-Down - View 00 Nearest Tower - View 00 Facilities Tower - View 00 Facilities Runway - View 00 AI Planes - View 00 Multiplayer Planes - View 00 IR (White Hot) - View 00 IR (Black Hot) - View 00 NVG (White Hot) - View 00 NVG (Black Hot) - View 00 Weapons - View 00 Static - View 00 RadarCamera - View 00 The longest name I found was 28 characters long. So this can be used as a guideline for the length. With 30 chars I believe you are on the safe side. For the own cameras you can influence the length of the camera name. The only uncertain names are the aircraft cameras, which are defined in the aircraft.cfg files. Anyhow you can shorten names there too. So if someone is so experienced to control cameras from LUA, he/she should also be able to edit names of cameras ;-) The reuse of the existing offsets was exactly what I thought. No problem with that. Best regards Reinhard

Pete, It works perfectly now with that version. Many thanks !!! Reinhard PS: As there is Christmas coming soon: It would be great if SimConnect_CameraSetRelative6DofByName also could be supported: This would allow to manipulate any camera view and not only the main view ...

Pete, I am using FSUIPC 4.948 with P3D 2.5 under WIN 7/64. I tried to use the offsets 86A0..86B4 to set the current camera position relative to the defined eyepoint. The values should be float as described and should be written as a structure. I tried to test this with the following code: -- test eyepoint setting -- play with these values local lX = 0.0 local lY = 0.0 local lZ = 0.0 local lPitch = 0.0 local lBank = 0.0 local lHeading = 0.0 -- now set the eyepoint ipc.writeStruct( 0x86A0 , "6FLT" , lX , lY , lZ , lPitch , lBank , lHeading ) -- X, Y, Z, P, B, H What I found: Float is not working. I have to use Integer (32-bit). By that I can write positive values only and only in degrees. So writing 0x000F to the heading Offset for example really moves the camera 15 degrees in the right direction. It seems if the binding to the Simconnect function is not correct. If I try to use float values other than zero, the result is completely wrong. Please check the code for implementation gain. Reading the thread, where you implemented this feature, it obviously did work in 4.939t. But If I use your test sample code there, it gives a completely wrong setting for me. It might of course be a bug on LM side too. Rgds Reinhard

Pete, Thanks for verification. I will report the findings to LM. Best regards Reinhard