Listen() handlers in states...

LSL isn't well documented, but the code below is pretty simple.
It doesn't work right (type 'start' to enter moving state, then type 'stop' to return to stopped state.) For some reason the listeners fire alternately, and cummulatively. Are there two bugs here?

b - 1) Are listeners active even when their defining state isn't active?
b - 2) Do listeners accumulate? How would one disable a listener?

default {
state_entry() {
    state stopped;
  }
}

state stopped {
  state_entry() {
    llListen(0,"","","start");
  }
  listen(integer channel, string name, key id, string message) {
    llSay(0,"Starting.");
    state moving;
  }
}

state moving {
  state_entry() {
    llListen(0,"","","stop");
  }
  listen(integer channel, string name, key id, string message) {
    llSay(0,"Stopping.");
    state stopped;
  }
  collision(integer colliders) {
    llSay(0,"Hit something.");
    state stopped;
  }
}

OOp. Found one thing:

llListen returns an identifier that can be used to deactivate or remove the listen. [Sorry I missed that.]

I still have the problem with execution scope though. Why would a listen() in an unactive state execute?

Oracle Omega

afaik, the listen events are state-independent, and thus will remain running until you manually deactivate them. try an llListenRemove() before changing states, that should solve your problem...

Only one llListen(0, "", "", "" required in the default state's state_entry() of you script. It will enable the listen event for all states of your script. Multiple llListens will make your script appear to "hear" once for every time you use it. In your listen event, if (msg == "stop" { etc. }, if (msg == "start" { etc. }. If you like to submit the string in advance that's ok but you should still only use llListen() once in the script unless you are listening on more than one channel.

actually, i think setting up multiple listens (each triggering on a different keyword) is a good way to do it if you're going to have an object listen only to a few keywords. this way, it doesn't process the listen event at all unless one of the keywords is spoken. of course, you'd still have to have the if (msg == "start" tests, to separate out the different keywords once the listen event is triggered, but the multiple listens with narrower scopes would be more efficient overall, i think.