Listen script ignores at random times (really annoying)

I've been noticing quite a bit lately that any script I have that is given commands through listen scripting, sometimes completely ignores what it's being told. I'm not sure if it's a problem with the lag (which I don't really feel anymore) or some other problem, but this really needs fixing to get assurable payout from gambling devices and to get some of my games working flawlessly. Hope you can ID this bug and squash it!!

*bump*

seriously, this happens every single day and it's really annoying, some linden acknowledge this bug =P

I was noticing this with my chandeler (sp).

I click on it and it lights itself, click again and it says "DIE!" on a specific channel. the flames are rezed objects that listen for "DIE" on a specific channel. Sometimes a few flames won't die, even though most do most of the time.

Yah Dave right on this bug is real, my 21 and High Low booths will once in a while just not "hear" you. Because those are somewhat elaborate scripts I isolated to a simple test and reproduced it, so put into the house rules to re-issue your command if there is no activity for about 5+ seconds. I haven't been able to find a consistent pattern. It's infrequent; I may see it twice in a night. Lag/channel mischief?

I guess for now people need to be aware that when using a device driven by vocal command and response, you need to go easy.

Could you please post this test for the benefit of the Lindens?

Create an object, put a script that responds to a listen event on it (so it talks back), trigger it over and over . Sooner or later it will ignore you.

OK I have a responce that deals with the post about the Candalabra that says DIE! to its child candles to make them go out... I think this problem can be solved by using the

link_message(integer sender_num, integer num, string str, key id)

thing and

llMessageLinked. This method of sending commands between parent and child objects is much more reliable then using llSay and llListen. Ill post a code snippet as soon as SL is online, Im too tired to write one up right now Ill get back to this asap.

That might work chris if they were linked.

And if I link them, then the flames don't work. :-/

Yeah, chris, the flames are spinning, and linked childs can't spin on their own, so llListen is required.

Even Ben Linden has problems with his games due to the llListen script being broken, so I'm pretty sure this will be fixed eventully.

I'm having MASSIVE trouble with this... The Pit refuses to score correctly because the scorebox and scoreboards aren't hearing correctly.

Worse yet, the capture points use llSay to tell the ball where the goals are... and it really kills the game when the ball doesn't hear that and a team cannot score...

Gah! Again, my speed reading instinct gave me the wrong infomation. Yeah, messagelinked wont work without and object link

Has anyone tested the difference felt when using llShout instead of llSay with this problem? Im guessing that the deaf/ignorant objects may hear better if the objects trying to talk to them are shouting. So um, anyone ever try that? (not that I think that's the solution to this problem btw...)

Shout isn't "louder" just longer range. Allthough the idea that our objects are losing thier hearing is kinda funny - maybe if I didn't make all my scripts shout at each other.

BBC

The bug is real as far as I can tell, but there seem to be cases where you may think it's the bug but it's not...which always makes me think that the bug is not as straightforward as it seems. Look out for...or correct me if I'm wrong:

Scripts that use loops. if your script is processing a loop, (@Loophere, jump or while or if loops that have sleeps), it doesn't seem to respond to other events.

If your script is asleep, it won't hear you. So if you are interjecting 1.0 pauses and so on to space commands, you are periodically deafening your script.

I actually found one instance where I thought the bug was occurring, but after isolating all parts of the script in seperate tests, I couldn't reproduce that particular error, even though the fulll script was occassionally affected by it. I finally realized what was happening, removed the 1 second sleep, problem gone.

Good catches Tcoz!

As for if the bug is real, yes, you said it was real, and yes, I agree, it is real.

Proof is found when I talk to an object directly when it doesn't have any other scripts other than "listen" and it completely ignores me unless I talk to it again

So don't take Tcoz's post as "there is no bug" because it's still there you silly lindens you!!

Dave, can you post an example script that fails to listen?

BP, like your icon, my answer is "NO!!!!!"

Actually, any script with llListen() is your example. The problem with the bug is that it happens at random times.

Basically, at completely random times (I have yet to follow any pattern) a script will just plain not reply to a command.

What's making me rather mad is that this even happening to a Linden (Ben) yet the Lindens have yet to respond to this thread!

Please, one of you, respond, say you know about the bug!!! *cries*

Yah Dave I'm still totally with you a-la my little posted test. My other post was more to encourage people to make sure they are indeed dealing with the bug and not some other procedural issue.

Let me tell you, sitting in technical training where you're not learning anything with a wireless DSL-quality connection...ain't so bad ;p.

I posted a feature suggestion about a new way of communicating script-links. It works the same as linking (so you can use the reliable linkmessages) but the objects won't be attached (physically). That would get rid of the listening bug and also it can't interfere with other object that are around that listen on the same channel.

Good idea Mark, but the problem is, we don't even know what's causing the listen problem, so for all we know, even that suggestion might fail (although it does sound rather fail-proof). Just my thoughts

I've made several things with linkmessages and they never seem to fail so I guess if they use the same system as that it will work.

does anyone have a simple way to reproduce this bug? i've been messing around with llListen for a lil bit and I've never had a problem.

Yes Ope, just create an object that responds to voice commands. Give it the tirgger over and over, sooner or later it will ignore you. It may take 100+ times, but eventually it will happen, I posted that about 10 posts back or so.

The linked object idea is great for objects talking to objects, but I'm not sure it solves players talking to objects...which means that the first object in your link chain has to hear the player to get it started. If that doesn't work, the objects get no trigger to chat about.

oh hehe, you're right. I should learn to read more I was under the impression though that this happens more like 1/4 of the time, not more like 1/100. I'm gonna make my own little test tonite, just out of curiousity, since I haven't seen it yet. I'll post how it goes.

Suggested test involves two objects:

default {
  state_entry() {
    integer i;
    for (i=0;i<100;i++)
      llWhisper(0,(string)i);
  }
}

and

default {
  state_entry() {
    llListen(0,"","","") //could put the name of the other cube here
  }
  
  listen(integer c, string n, key id, string m) {
    llWhisper(0,"I heard " + m);
  }
}

Could put a few sleeps in that for loop up there.

And I can confirm with Tcoz that other events do not get triggered durring for loops. I think this is a flaw, but here is the work around - keep a global counter (or global whatever it is you need to check for the end of the loop), start a timer event and use that instead. At the end of the 'loop' set llSetTimerEvent(0);

Yah Ama awesome stuff I came to the same conclusions, good to know. I got stymied by the global counter approach when I was wrestling with seamless sound looping, but otherwise the global counter approach has gotten me out of some jams.