Help! having problems with timed event that also needs to listen

I'm having endless problems trying to get a particular script of mine working reliably. If anyone has any suggestions for how to make this work, I'd really appreciate some input. The situation is this: I'm trying to get a particle emitter that will periodically emit a puff of steam (think "exhaling", but that will also be switchable on or off via a hud button. It sounds really simple, doesn't it? But I'm finding that I can either put the steampuff commands inside the Listen and thus have the script reliably listen for the hud button command (but only actually emit puffs of steam when it hears something on the Listened-to channel), or I can put the puff-of-steam commands outside the Listen, but then the puff-of-steam loop means that the emitter doesn't hear messages from the hud button as it's stuck in that loop rather than listening for hud messages.

I'm sure I must be missing something here. How do I get a script to execute a repeating loop of actions (i.e. emit particles, pause briefly, stop emitting particles, pause for a second or two, repeat indefinitely) *while* listening for input? It sounds so simple but I've yet to find a logical structure that will allow it to do *both* of these simultaneously. What am I missing?

Hi Nimbus

You are already close as you say you need a 'timed' event. In LSL exists a 'timer' event that can be started by the llSetTimerEvent(x) function where x represents the time in seconds the timer event will start and be triggered repeatly until its stoped.

If you're not that experienced in scripting and unsure what to do you better post your script here and we'll be able to help some more.

greetings =)

As revochen said. Really sketchy code fragment to follow:


listen(integer channel, string name, key id, string message)
{
if (message == "start"
{
steampuff;
llSetTimerEvent(10); // start the timer
}
else if (message == "stop"
{
llSetTimerEvent(0); // stop the timer
}
}

timer() // this happens periodically when the timer is running
{
steampuff;
}

Hope that makes some sense. I probably forgot something so only use that as an example of roughly how timers work, not as actual usable code

Thanks for the suggestion, but I do already know about the timer event. The problem is that as far as I can figure out, continuing to listen for messages from hud buttons isn't all that practical *while* the timed event is running. If I implement it using some variation on either a timer or a series of llSleeps, then while that is occurring it can't simultaneously listen for hud button messages. If I have it perform a single cyle of the timed event (i.e. a single puff of steam followed by a delay) then during that period, any messages coming from that hud button won't be heard by the script. If I have it loop continually (i.e. puff, pause, puff, pause... etc ad infinitum) then at no point is it listening for hud messages. On the other hand, if I put the puff-pause sequence inside the listen, then it'll play once but not again unless the requisite hud button is pressed again, and if I put it after the listen, that brings us back to the "won't listen while the puff sequence is occuring" problem. And since what I'm after is an effect where the periodic puffs occur until the button is stopped, and stay stopped until the button is pressed again whereupon they resume again.... none of these variations seem to do the trick.

I've tried doing it with timers, I've tried doing it with sleeps, I've tried various permutations involving multiple states and putting the listens in different places, I've tried while and do-while loops. The same problem keeps coming up - I can't find a way to get the script to do both of these at once. A while ago I tried using a separate script to listen and to turn the puff-nopuff-puff script on or off according to button presses, but all the relevant prims are worn as attachments, and for some reason I found that when tping, scripts that were switched off spat out error messages as I rezzed at the new place. Unless something's changed in how the server handles that (and I suppose it's worth a try, it's been a while since I tried that one) then that option's out as well.

I'm stumped.

Hmm, STOPPING timers is a radical idea! *laugh* OK, that fragment makes it much clearer what the previous poster was probably suggesting as well. So in this example, while the stuff in the timer() sequence is happening, the script is *also* listening? If so, then it might be exactly what I need. I thought there must be some simple mechanism I was missing. I'll give this a go, for sure. Thanks, folks! I'll let you know if it does the trick.

And yes, that does seem to be working just fine! *happydance* Still a bit more testing to do, but that may have solved a problem that's been bugging me for a while. Thanks so much, folks!