Donovan

Yea. Understood. Looks like the event.flag() is triggered by the various buttons. 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:6 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:9 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:12 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:15 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:18 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:21 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:24 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:27 45255 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:28 45365 LUA.0: D:\Flight Simulator 9\MODULES\Simsound.lua:46 Although I don't have the "line numbers" of the lua here. I don't understand why the same sound.play("name.wav") command that would audibly play on your original script, won't play within this script. Doesn't appear to be a fault within the script itself, unless I am completely missing something right in front of my face. Sorry haven't been able to help you toward a more fruitful and satisfying result. Don

Michael, Wow. Kinda scratching my head. I don't see any errors in the lua script. The script I originally posted tests fine here as written. I see the buttons are sensed in the .log file. But no other data on the lua other than it seems no lua errors logged. I wasn't aware you were using FS9, and not FSX, but that shouldn't matter. For more data: on the FSUIPC Logging Tab - enable "Debug/Trace Lua Plugins" And do a short run through each of the switches you have enabled. Then attach the log. I wish I still had FS9 on one of my systems, but I don't anymore. Let's see if there's a clue in the more detailed logging. Don

Anything show in the .log file? Are the sound files in the default FSX/Sound directory? Those particular files are not in MY FSX/Sound install, and if they are in a different directory, you will need the sound.path() set as in your original lua script. Also double check your first, and seventh button setup in the Buttons+Switches menu -- 1=P0,13,CL1:R,0 7=P0,8,CL3:R,6 It looks like they're set up as a Lua Run, instead of LuaSet, so the flags won't be properly set for the event.flag(), and the ipc.testflag() commands. Don

Michael, What does the FSUIPC4.log show? That should point us in the right direction. It will halt upon the first error found on compiling and not execute the lua script - so that may be why nothing will play - and will give you the line number and the error. Don

Michael, I still had a couple functional neurons after work, and this appears to almost work fully, but will serve as an example of what I was meaning. (Rename the files as you see fit, of course) In your FSUIPC.ini file: [Auto] 1. Lua=sndloop To your fsx/modules folder copy sndloop.lua: -- sndloop.lua function sndloop(flag) if ipc.testflag(1) then ipc.clearflag(1) sound.play("ai_twinprop01.wav") elseif ipc.testflag(2) then ipc.clearflag(2) if sound.query(refa) == true then sound.stop(refa) else refa = sound.playloop("backcourse_marker.wav") end elseif ipc.testflag(3) then ipc.clearflag(3) if sound.query(refb) == true then sound.stop(refb) else refb = sound.playloop("bmtouch1.wav") end else end end event.flag("sndloop") Then start FSX and open FSUIPC, and under the Buttons+Switches Tab, Select for FS control and in the dropdown for 'command to send when button pressed' select LuaSet Sndloop, and the desired parameter in the parameter field. This is almost the same thing you have done, but this time uses the LuaSet. The parameter is set as a flag# for the sndloop.lua, and will trigger the event.flag() and execute the function "sndloop". The function name does NOT have to be the same as the lua file name. I just took the easy way out in knocking this out. The only thing with this example, is that turning the "off" the looped files, is that they must be turned off in the reverse order that they were started. I'm not sure why, but you get the main idea of what my approach was. Like I said, there are probably a number of ways to get where you want to go. Hope this helps. Don

Hi Michael, YEP! Definitely not afraid to get your hands dirty on code! :cool: Don

Michael, No, your lua file isn't, constantly running! My guess it runs less than 0.5 seconds MAX each time you push a button. The sound.playloop() can run for however long after the lua file is finished. That isn't the issue. An "event-driven" lua script is technically "running" but not doing anything and not using clock cycles that detract from FSX execution until triggered by the event. Again, it wouldn't be actively using CPU cycles more more than 0.5 secs at a time (or less!). Also it isn't a "problem" doing it the way you are doing it UNLESS you execute sound.playloop() more than one .wav file at a time. Then the issue of using sound.stop() only being able to cancel the last soundloop crops up. Using event.button(), or ipc.testflag() for buttons/switches isn't unique to sound files, so don't limit your looking to just sound files, for examples of event triggered lua execution. READ the doc's and take a stab at it. Normally, I'd be happy to give you some examples but I'm still at work on a project and won't be home 'til the wee hours of the morning. I'll check back tomorrow to see how far you've gotten. I'm not trying to make it more confusing. Its not. But it does require that you are willing to dig in and get your hands a bit dirty. Also, I'm SURE there are probably 4-5 ways to achieve what you want, not just one. I'll try to put something together when I get home, if I have any neurons left firing in-me-skull. Don

Michael, There is one other point. Because your current method executes the lua script each time you push the button, Simsound.lua runs "newly" with each button press. This creates the situation that ref = sound.playloop() value will always = 1 (as its the first sound played in that script execution). Thus if sound.playloop("5-16fueltrk") is already playing in a loop (now "globally", outside the lua script, which is no longer running), and then you execute sound.playloop("5-17fueltrk2") in a new iteration of Simsound.lua , they will both have a ref = 1, because they were started in separate Simsound.lua threads. So the sound.stop(1) will stop the last executed soundloop only. From what I can tell, this is a limitation of the current method you are using. To overcome this, you may want to switch over to an "event- triggered" method of button checking, whereby your Simsound.lua is executed only once at startup, and remains running and use an event-driven method of executing the function using event.button (joynum, button,"function") to trigger the actions. There are examples of this here in the user contribution section. Don

Hi Michael, I see! My error on the interpretation of the "R", as given in your [buttons] section. When used with a button/switch executing a Lua Script, the R stands for "Run" (pgs 28-29 of the FSUIPC4 for Advanced Users PDF) My apologies for the mis-information. I fooled around a bit with a couple test lua scripts using the sound.playloop("name") on my system, and learned something in the process. Referring to the FSUIPC Lua Library PDF as a reference. To quote (page 30 of the Library PDF): The SOUND Library ref = sound.play("name-of-wave") The "ref" value returned is a number which can be used subsequently in the stop, adjust and query functions. In my simple tests, the value for ref returned was a simple number corresponding to the order of which a sound.playoop (name) was executed. The first looped sound yielded a ref value of 1, the second a ref value of 2. I did not test this extensively, just used ipc.log(ref) to see what values came back in the FSUIPC.log. I used this ref value obtained in the next test. In this second lua script, I setup a toggle switch to execute "Testloop.Lua", passing a parameter of 3, just as you have shown above, but leaving the "command sent when released " fields empty. -- testloop.lua if ipcPARAM == 3 and sound.query(1) == true then sound.stop(1) else sound.playloop("bmtouch11.wav") end Toggling the switch ON, executed the soundloop of wheels touching down. (that sound gets old FAST!) Toggling the switch off turned off the sound. You MUST use the ref value, and NOT the "name"! I think you probably can work it out from here, but I'm glad to help more if needed. Don

Michael, There are only two files in your lua script that are set to loop -- elseif ipcPARAM == 16 then sound.playloop("5-16fueltrk") elseif ipcPARAM == 17 then sound.playloop("5-17fueltrk2") These would require the sound.stop("name") command to stop their playing. (as they are being executed outside the lua script via the Sound Library) The sound.play("name") command will play a file once to the end of the .wav file. Its not clear to me why you have the "Repeat while button held" programmed with almost every button, and on some of these you have the "Kill Lua" upon release of the button. Was that intentional to make the sound continue? It repeatedly calls your Lua Script (2) at 6 times per second, as long as the button remains pressed. And the "Kill" stops the current lua script execution (not the sound.play().) On line 44: 44=P0,20,C1084,20 you are using the "Lua Kill All" command and passing a parameter of 20 which will be ignored, and won't execute what I think you intended to be seen by your lua script: elseif ipcPARAM == 20 then sound.stop("5-10premovie") Editing line 44: 44=P0,20,CL2,20 would pass the ipcPARAM of 20, to your lua scipt, where the sound.stop() command would be executed, and the lua script completed. Unless I am missing the point of what you are trying to achieve, I would suggest editing the other button entries similarly (there are other more graceful ways to get the .wav file to play longer than the repeat method you are currently using), and let the lua script exit gracefully on its own without using the Kill command unless absolutely necessary. Don

Just install the lastest FSUIPC version, and the FSUIPC installer itself will search the registry for the proper paths for any combination of FSX, FSX-SE and/or P3D. The only problems I've seen with this on the forums here, is when the simulators themselves were not properly installed and thus there were registry errors. You can do a search here on the forums for more data related to this. The most recent FSUIPC version is v4.939t, and can be downloaded here under Download Links, under the pinned topic "updated modules." Don

Peter, Double check and make sure you don't have the "Repeat while Pressed" for the PTT assignment box checked in the button assignments page. That's the most common problem I've seen with PTT issues. Don

Glad to hear it! Don

You can certainly write a Lua Script for this, but you can also use the Conditional Button Programming as described in the FSUIPC for Advanced Users PDF. Here is an (untested) approach for programming the Buttons. Definitions ("=>" denotes action to be taken when button switched position) AP_1 = Pilot AP master switch (Joystick A, Button 17 = A,17) AP_2 = CoPilot AP master switch (Joystick A, Button 14 = A,14) AR = Autorudder Toggle ON/OFF switch (Joystick G, Button 11) Assumptions 1. That the PM Offsets you have listed for the Pilot and CoPilot AutoPilot engage toggles the respective AP functions on/off (i.e. doesn't require a write to a separate offset, or a different <,parameter> to turn AP function off) 2. That the AR Switch is overridden by the AP switch positions (i.e. you cannot turn AutoRudder off if either AP_1 or AP_2 is ON, and you cannot turn AutoRudder ON if both AP swithes are OFF) -- If this is the case, I am not sure why you even have the physical button programmed on Joystick G, Button 11, as it would not be independently operative) Logic 1. AP_1 ON => if AP_2 OFF => pilot AP ON + Toggle AutoRudder ON if AP_2 ON => pilot AP ON + do NOT toggle AutoRudder AP_1 OFF => if AP_2 OFF => pilot AP OFF + Toggle AutoRudder OFF if AP_2 ON => pilot AP OFF + do NOT toggle AutoRudder 2. AP_2 ON => if AP_1 OFF => co-pilot AP ON + Toggle Autorudder ON if AP_1 ON => co-pilot AP ON + Do NOT Toggle AutoRudder AP_2 OFF => if AP_1 ON => co-pilot AP OFF + Do NOT Toggle Autorudder if AP_1 OFF => co-pilot AP OFF = Toggle AutoRudder OFF Result 1. If either AP_1 or AP_2 or Both is/are on, AR is ON 3. If Both AP are OFF => AP OFF and AutoRudder OFF Edit FSUIPC.INI [buttons] Section: ;line numbers are arbitrary adjust to suit own needs [buttons] PollInterval=25 ButtonRepeat=20,10 InitialButton=A,14,A,17,G,11 ;(Optional) intializes these buttons/flags in 'off' state 15=CP(F-A,17)(-A,14)A,17,C2998,32 ;if AP_1 was OFF, and AP-2 is OFF => turn AP_1 ON then: 16=CU(F-A,17)(-A,14)A,17,C65951,0 ;toggles AutoRudder (AR) ON when button released 17=CP(F-A,17)(+A,14)A,17,C2998,32 ;if AP_1 was off, and AP_2 is ON, then toggles AP_1 ON 18=CP(F+A,17)(-A,14)A,17,C2998,32 ;checks AP_1 was ON and AP_2 is OFF, toggle AP_1 then: 19=CU(F+A,17)(-A,14)A,17,C65951,0 ;toggles AR OFF when button released 20=CP(F+A,17)(+A,14)A,17,C2998,32 ;tests if AP_1 was on and AP_2 is on, then toggles AP_1 OFF 21=CP(F-A,14)(-A,17)A,14,C2998,33 ;if AP_2 was off and AP_1 is off, then toggles AP_2 ON then: 22=CU(F-A,14)(-A,17)A,14,C65951,0 ;toggles AR ON when released 23=CP(F-A,14)(+A,17)A,14,C2998,33 ;if AP_2 was off and AP_1 is on, then toggles AP_2 ON 24=CP(F+A,14)(+A,17)A,14,C2998,33 ;if AP_2 was on and AP_1 is on, then toggles AP_2 OFF 25=CP(F+A,14)(-A,17)A,14,C2998,33 ;if AP_2 was on and AP_1 is off, then toggles AP_2 OFF then: 26=CU(F+A,14)(-A,17)A,14,,C65951,0 ;toggles AR OFF when released Don