Listen script ignores at random times (really annoying)

i was thinking i'll do something like, have one box repeatedly say 'hello' on some channel, and count how many times it says it. the other box will count how many times it hears it. i could have both boxes say 'ok' at a certain number, and if the second box doesn't say it when the first does, then i know it missed at least one message. i could also put in a listen for it to say how many it did actually hear.

thats probly what i'm gonna do. again, i'll post the results here.

The gyst I think is that events don't interrupt other events. So if you put a for loop or something in the state_entry, the other event won't come through until state_entry is done.

So if you want something to be interruptable.... you gotta have points when it isn't in any event handler, such as between timer events.

Most (?) scripts are ok because they do some setup stuff in state_entry and then wait for something to happen. The problem comes I think when you want to continously do something, and have it interruptable.

I would like an 'event' that is called right after state_entry that is interruptable. It can be the only state that is. Call it state_run . Any event would interrupt happenings in it. I suggest this because I can imagine trouble being caused if other event handlers were interruptable.

ok, I ran my little test. I think you guys would find this interesting, as I did. I set it up much like i posted earlier.

Here is the saying script:

integer limit = 100;
integer channel = 666;

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        integer x;
        llSay(0, "Touched.");
        for(x = 0; x < limit; x += 1)
        {
            llSay(channel,"can you hear me now?");
        }
        llSay(0,"done");
    }
}

and the listening script:

integer heard = 0;
integer channel = 666;

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
        llListen(channel,"","","");
    }

    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        llSay(0, "heard = " + (string)heard + ", resetting to 0");
        heard = 0;
    }
    
    listen(integer channel, string name, key id, string message)
    {
        if(message == "can you hear me now?")
        {
            heard += 1;
        }
    }
}

so basically you touch the sayer, it repeats "can you hear me now?" 100 times, and the listener adds 1 to its 'heard' count every time it hears that message. the sayer says 'done' when it has finished repeating. at this point if you click the listener to find out how many, you will usually get around 50. apparently this is because a number of listens haven't arrived(?) or been processed yet. something like that. because if you instead give it a few seconds from when the sayer says 'done' it will be around 90. But, so far the most succesful the listener has been in a bunch of tries has been 93. I haven't tried putting a llsleep in there to slow it down, but thats because i fugured that we shouldn't have to do that anyway.

so it seems that there definitely is a bug. also, please double check me incase i messed something up in the code.

Hey, guys - thanks for doing a bit of debugging - sorry that it took so long for an engineer to post to the thread.

I don't know too much about the internals of the scripting system (and especially about how event handling works) - so this is a bit of guesswork.

We'll try and take a look at it soon - it obviously can make it a bit difficult to make scripts work reliably.

- Doug

Uh, now that you mention it, I think we may have already seen this bug out at my place, Doug. As you recall, the maglev was having a bit of trouble with communicating with the nodes properly, even before it started killing the collision detection for the entire sim... hmm... at least it worked perfectly for ONE day before 0.6.0.

i was scripting the doors on my bunker last night, and the keypad is set to tell the doors a password when the correct code is entered. the doors are actually a pair of double doors that open in opposite directions. however, many times i noticed that one door would open while the other wouldn't. just for curiosity, i put a generic listen box in that listened on the same channel as the doors and echoes whatever it heard into channel 0, and dropped it further away from the keypad than either door.

not too surprisingly, i would get any of the combinations below:

L Door  |  R Door  |  Box
--------+----------+--------
 open   |   open   |  echo
 open   |   open   |   X
 open   |    X     |  echo
 open   |    X     |   X
  X     |   open   |  echo
  X     |   open   |   X
  X     |    X     |  echo

you'll note that at least one of the three objects responded at any given time, indicating it's not a problem with the keypad issuing the command.

the box has no sleep states, for/while loops, or any other delays at all, and the doors only have a llSleep after they open, to provide a delay before they close

the doors are insta-open (i.e. they snap into the open position, and do not "open up" in steps like the doors on my pagoda), and do not have for loops, before any of you ask

now i sometimes have to hit buttons three or more times just to get the desired response!

i did the test routine, with the following scripts on two different objects:

    touch_start(integer total_number)
    {
        llSay(1000, "Touched");
        count++;
        llSetText((string)count,<1,1,1>,2.0);
    }

    state_entry()
    {
        llListen(1000,"",NULL_KEY,"");
    }

    listen(integer c,string n,key k,string m)
    {
        count++;
    }
    touch_start(integer x)
    {
        llWhisper(0,"I counted " + (string)count + " messages.");
        count = 0;
    }

and once the "talker" box's count reached 20, i touched the "listener", and it had only counted 10 messages!

what's even worse is, sometimes i would touch the talker, and it wouldn't register the touch!

these two problems combined wreak havoc on the keypad to my bunker, as it relies on you touching certain buttons in a certain combination. although they're linked and using llMessageLinked() to get around the listen problem, they're still not always registering the touches, making it nearly impossible to open the doors, even with the right combo!

WHAT IS GOING ON!?!?!?

I saw this happen when Davada was trying to get his MLe1937 AT gun to fire, and only about 2/5 of the time it would fire.

I've also noticed the touch doesn't work good anymore (maybe on some sim's it does and on some it doesn't). Maybe there are too many events so they can't all be processed.
But I can't test it now, but I thought the touch would always work if you HOLD the object for at least a full second.
Anyway these problems should be resolved.

little of topic:
Also on servers like Varney the server FPS is about 30 f/s while others are at 2000 or 3000. What causing that great lag. Is it just the great number of objects or are there certain buildings/objects/scripts that are causing the lag?? If so please ask the owner of these things to change/remove it so we can walk normally trough neo-city again.