kdlovell Posted January 13, 2016 Report Share Posted January 13, 2016 Hello, I have been reading through the forums on how to toggle the lights in the 0D0C offset. My goal is to use a lua event to appropriately set the taxi light based on the Aerosoft Airbus Lvar. I understand each light is controlled by a separate bit and normally this would be done using AND and OR logic. However, based on what I have been reading in the forums and the Lua Library doc, the setbitsUW and clearbitsUW should work in place of using the AND and OR logic. Unfortunately, in all of my testing it seems to reset all of the other light offsets rather than just operate on the taxi light. I have also tested a one line script using setbitsUW to toggle the taxi light in the default 737 with the same result. Am I using the code below incorrectly? Do I need the AND and OR logic when using the setbitsUW and clearbitsUW -- set the pollrate to 250ms = 4 times per second pollrate = 250 function writeTaxi(varname, value) if value == 1 then ipc.setbitsUW(0x0D0C, 8) else ipc.clearbitsUW(0x0D0C, 8) end end -- create an event listener to monitor the LVAR -- this will call the function above when the LVAR changes -- Aerosoft Airbus Taxi Light event.Lvar("L:AB_TAXI_LT", pollrate, "writeTaxi") Thank You Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 13, 2016 Report Share Posted January 13, 2016 I have been reading through the forums on how to toggle the lights in the 0D0C offset. My goal is to use a lua event to appropriately set the taxi light based on the Aerosoft Airbus Lvar. If the Aerosoft lights are handled by an LVar, don't you need to write to that LVar to change it, not 0D0C? The latter collects together all of the default FS-implemented light switches. I understand each light is controlled by a separate bit and normally this would be done using AND and OR logic. However, based on what I have been reading in the forums and the Lua Library doc, the setbitsUW and clearbitsUW should work in place of using the AND and OR logic. Correct. If you are programming your own application using the regular FSUIPC interface you'd need to read 0D0C, change a bit using AND, OR or XOR, and write it back, hoping no one else had changed it in the meantime. But from Lua the setbits, clearbits and togglebits do it for you with no intervening changes guaranteed. Unfortunately, in all of my testing it seems to reset all of the other light offsets rather than just operate on the taxi light. I have also tested a one line script using setbitsUW to toggle the taxi light in the default 737 with the same result. Strange. If this were happening many things would be going wrong -- the technique is used extensively. Am I using the code below incorrectly? No, that looks fine. Please try two things: 1. Monitor 0D0C using the Monitor option, right-hand side of the Logging tab. 2. Enable Lua debug/trace option, in the Logging tab (do this before starting your plug-in). Let me see the log please. [LATER] Just tested here with FSUIPC 4.929, and those functions definitely still work fine. Pete Link to comment Share on other sites More sharing options...
kdlovell Posted January 13, 2016 Author Report Share Posted January 13, 2016 Hi Peter, Thanks for the response. I should have mentioned that the reason I am trying to accomplish this is so that a virtual airline acars system can read the taxi light from FSUIPC when the Aerosoft Airbus is used. I created a simpler example and turned on the logging as you suggested: Sim: FSX Steam Edition FSUIPC: 4.949 Aircraft: Default 737-800 Steps: 1) Load Aircraft and turn on all lights except taxi light 2) Run Lua script Result: Taxi light turns on and all other lights turn off Expected Result: Taxi light turns on and all others remain as is Lua Script: ipc.sleep(100) ipc.display("Turning on Taxi Light...") ipc.sleep(2000) ipc.setbitsUW(0x0D0C, 8) ipc.display("Done") ipc.sleep(2000) Lua Debug Log: ********* LUA: "test" Log [from FSUIPC version 4.949] ********* 156203 System time = 13/01/2016 08:16:01, Simulator time = 11:14:15 (16:14Z) 156203 LUA: beginning "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua" 160421 LUA: ended "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua" 160421 System time = 13/01/2016 08:16:06, Simulator time = 11:14:19 (16:14Z) ********* LUA execution terminated: Log Closed ********* FSUIPC Log: ********* FSUIPC4, Version 4.949 by Pete Dowson ********* fsx.exe version = 10.0.62615.0 Reading options from "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\FSUIPC4.ini" Running inside FSX Steam Edition on Windows 8.0 Module base=55FF0000 User Name="Keith Lovell" User Addr="keithlovell@metrocast.net" FSUIPC4 Key is provided WideFS7 Key is provided 62 System time = 13/01/2016 08:13:25 62 FLT UNC path = "C:\Users\Keith\Documents\Flight Simulator X Files\" 62 ------ Module Version Check ------ 62 acontain.dll: 10.0.62615.0 62 api.dll: 10.0.62615.0 62 controls.dll: 10.0.62615.0 62 fs-traffic.dll: 10.0.62615.0 62 G3D.dll: 10.0.62615.0 62 sim1.dll: 10.0.62615.0 62 visualfx.dll: 10.0.62615.0 62 weather.dll: 10.0.62615.0 62 window.dll: 10.0.62615.0 62 ---------------------------------- 93 Trying to connect to SimConnect Steam ... 93 FS UNC path = "D:\Program Files (x86)\Steam\steamapps\common\FSX\" 390 ---------------------- Joystick Device Scan ----------------------- 390 ------------------------------------------------------------------- 406 LogOptions=00000000 00000001 406 ------------------------------------------------------------------- 406 ------ Setting the hooks and direct calls into the simulator ------ 406 --- CONTROLS timer memory location obtained ok 406 --- SIM1 Frictions access gained 406 --- FS Controls Table located ok 406 --- Installed Mouse Macro hooks ok. 406 --- Wind smoothing fix is fully installed 406 --- All links checked okay 406 ------------------------------------------------------------------- 406 SimConnect_Open succeeded: waiting to check version okay 406 Trying to use SimConnect Steam 4015 Running in "Microsoft Flight Simulator X", Version: 10.0.62615.0 (SimConnect: 10.0.62615.0) 4015 Initialising SimConnect data requests now 4015 FSUIPC Menu entry added 4031 D:\Program Files (x86)\Steam\steamapps\common\FSX\flights\other\FLTSIM.FLT 4031 D:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.air 7453 Weather Mode now = Theme 21765 D:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.air 59000 Aircraft="Boeing 737-800 Paint1" 59000 System time = 13/01/2016 08:14:24, Simulator time = 11:13:32 (16:13Z) 66078 Starting everything now ... 82781 Advanced Weather Interface Enabled 129703 LogOptions changed, now 80000000 00000001 129718 Monitor IPC:0D0C (U16) = 2 144109 Monitor IPC:0D0C (U16) = 6 144109 SimRead: 0D0C="LIGHT LANDING" INT32: 1 (0x00000001) 148093 Monitor IPC:0D0C (U16) = 262 148093 SimRead: 0D0C="LIGHT LOGO" INT32: 1 (0x00000001) 150093 Monitor IPC:0D0C (U16) = 278 150093 SimRead: 0D0C="LIGHT STROBE" INT32: 1 (0x00000001) 158375 Monitor IPC:0D0C (U16) = 8 <================ This is where the Lua script was run 164937 Sim stopped: average frame rate for last 35 secs = 92.3 fps 168671 System time = 13/01/2016 08:16:14, Simulator time = 11:14:23 (16:14Z) 168671 *** FSUIPC log file being closed Minimum frame rate was 75.8 fps, Maximum was 122.2 fps Minimum available memory recorded was 3015Mb Average frame rate for running time of 51 secs = 99.7 fps Memory managed: 27 Allocs, 27 Freed ********* FSUIPC Log file closed *********** Thank you again for your time. Keith Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 13, 2016 Report Share Posted January 13, 2016 1) Load Aircraft and turn on all lights except taxi light 2) Run Lua script Result: Taxi light turns on and all other lights turn off Expected Result: Taxi light turns on and all others remain as is Lua Script: ipc.sleep(100) ipc.display("Turning on Taxi Light...") ipc.sleep(2000) ipc.setbitsUW(0x0D0C, :cool: ipc.display("Done") ipc.sleep(2000) Lua Debug Log: ********* LUA: "test" Log [from FSUIPC version 4.949] ********* 156203 System time = 13/01/2016 08:16:01, Simulator time = 11:14:15 (16:14Z) 156203 LUA: beginning "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua" 160421 LUA: ended "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua" 160421 System time = 13/01/2016 08:16:06, Simulator time = 11:14:19 (16:14Z) ********* LUA execution terminated: Log Closed ********* FSUIPC Log: Hmm. Very very strange. I'll try your test, exactly. Incidentally, you apparently did not turn on the Lua debug/trace option. And you don't want a separate Lua log as the idea is to make the Lua steps inter-relate to the monitoring action. Don't use "Luadebug" to start the plug-in, just start it normally, with a keypress or button. [LATER] Okay. I've reproduced the problem you describe. I don't know why I got a different result on my first test. I'm checking now to see what could have got messed up. Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 13, 2016 Report Share Posted January 13, 2016 Okay. Found it. It's the same with all the togglebits, setbits and clearbits variations! I don't know why it seemed okay when I tested it earlier. And it seems amazing that it's actually been wrong for years and no one has mentioned it till now! The problem was that originally the same Lua code was used for FSUIPC3 and FSUIPC4. Now FSUIPC3 only has one memory space for offsets, and they are all read and written there. But because SimConnect is asychronous in operation I had to have two such memory spaces -- one for writing into and the other for the results returned (often a little later) from SimConnect. I adapted all of the Lua code to handle this -- EXCEPT for these functions! They were reading and writing the write area, where they should read from the read area, do the changes, and write to the write area. The FSUIPC Offset controls for the same functions work fine because that part wasn't based on original FSUIPC3 code! I've fixed it in version 4.949c, available (DLL only for now) in the Download Links subforum shortly (about 30 minutes or so ...). Thanks & Regards Pete Link to comment Share on other sites More sharing options...
kdlovell Posted January 13, 2016 Author Report Share Posted January 13, 2016 Thank you Pete, I appreciate the confirmation that I am not crazy after all! I couldn't understand why I was having issues after reading through the forums for hours trying to figure this out. Once again you have proven your legendary status in the sim community :) Thanks, Keith Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 13, 2016 Report Share Posted January 13, 2016 Unfortunately I cannot at present get access to the Forum repositories in order to upload the corrected version. Seems that when all the SimFlight forums went down yesterday for an "upgrade" not everything was reinstalled correctly. I'm waiting for this to be fixed and will upload 4.949c as soon as I can. Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 13, 2016 Report Share Posted January 13, 2016 Whilst awaiting some fix to my access rights to the Download section of the Forum, you can get FSUIPC 4.949c from Dropbox via this link: Petes Downloadable Files Pete Link to comment Share on other sites More sharing options...
kdlovell Posted January 13, 2016 Author Report Share Posted January 13, 2016 Thanks! I'll be testing this out tonight after work. Keith Link to comment Share on other sites More sharing options...
kdlovell Posted January 13, 2016 Author Report Share Posted January 13, 2016 TESTED: Works like a charm! Thanks Pete Keith Link to comment Share on other sites More sharing options...
aua668 Posted January 30, 2016 Report Share Posted January 30, 2016 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 7, 2016 Report Share Posted February 7, 2016 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. Since the fix correctly operates by changing only the bits you specify, whereas previously, because of the bug, it affected other bits too, I suspect that one or other of the other bits are needed to change the visible switch. Try toggling all bits (255). It may be something to do with the way the gauges in that add-on are programmed. BTW, when 029C is written, no matter how, FSUIPC checks whether he value has changed, and if soit sends the control "Pitot heat set" (control number 66074)with a parameter of 1 if 029C is non-zero, or 0 if it is now zero. That is not changed by the Lua "togglebits" fix. I cannot understand what the gauge in your add-on can be doing to take different actions internally to that on the visible switch. That sort of thing might happen with mouse macros, but I can't see how it can react differently with standard FS controls. Pete Link to comment Share on other sites More sharing options...
kdlovell Posted February 7, 2016 Author Report Share Posted February 7, 2016 Hi Pete, Do you have an idea when this version of FSUIPC will be released on the download page? I'm just planning my code updates to line up with the new version's availability. Thanks, Keith Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 8, 2016 Report Share Posted February 8, 2016 Do you have an idea when this version of FSUIPC will be released on the download page? I'm just planning my code updates to line up with the new version's availability. Which version? 4.949c? It is there, in the Download Links subforum, and has been for a while. The main installer is still 4.949, 4.949a/b/c were minor updates which didn't justify a new installer build, that's all. Pete Link to comment Share on other sites More sharing options...
aua668 Posted February 8, 2016 Report Share Posted February 8, 2016 Since the fix correctly operates by changing only the bits you specify, whereas previously, because of the bug, it affected other bits too, I suspect that one or other of the other bits are needed to change the visible switch. Try toggling all bits (255). It may be something to do with the way the gauges in that add-on are programmed. 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 Link to comment Share on other sites More sharing options...
aua668 Posted February 8, 2016 Report Share Posted February 8, 2016 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 9, 2016 Report Share Posted February 9, 2016 I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't. Okay. Thanks. I'll check it here. Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 9, 2016 Report Share Posted February 9, 2016 I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't. Found it. This is another very long-standing bug which affects not only the togglebits functions but also the setbits and clearbits functions. Basically the problem was it was changing both the memory area for "Writes" AND that for "Reads", so the part of the code detecting changes to offsets never saw any. Of course they should read the read copy and write the write copy! The earlier bug effectively masked this one! Fixed in 4.949e, now provided in Download Links. Sorry I didn't see this earlier. It was the problem of two different bugs affecting the same functions! BTW this statement from earlier also led me astray: "Since 4.949c in P3D 2.5 the offset ist toggled, but the switch in the panel doesn't move anymore." I couldn't see how it was possible to separate the two actions. It sounds like your add-on aircraft is, itself, reading the offset as well as obeying the FS control event? Pete Link to comment Share on other sites More sharing options...
Pierre-Jean Posted February 9, 2016 Report Share Posted February 9, 2016 Hi Pete, hi All here. I'm very interesting for this thread here. Fantastic Job Pete, fantastic ... You "juggle" with bytes and scripts with a selfless manner and great competence. Congratulations Mr. Dawson for this sharing and what we would do without you ... Regards,-Pierre-Jean Link to comment Share on other sites More sharing options...
aua668 Posted February 9, 2016 Report Share Posted February 9, 2016 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 Link to comment Share on other sites More sharing options...
aua668 Posted February 11, 2016 Report Share Posted February 11, 2016 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now