llSensor behaving oddly?

Okay, either I'm misunderstanding something, or something is broken in the scripting language.

I have a script. I call llSensor in the script to locate nearby avatars within a certain distance and radius. My understanding is that either the script will go into the sensor state or the no_sensor state depending on whether or not an object was found. Here's an idea of what I have:

do_effect() {
//some set up stuff
// look for an avatar by a particular name
llSensor(name,"",AGENT,distance,radius)
llOwnerSay("After sensor";
}

default {
//various states

sensor(integer matches) {
llOwnerSay("Found a match";
}

no_sensor() {
llOwnerSay("Didn't find a match";
}
}

The llOwnerSay calls are obviously there for debugging. When the script is run, it says "After sensor" but does not say either of the other two. This is not making sense to me. Either name is found within the distance/radius or it isn't. One or the other should happen, right?

What am I missing?

use NULL_KEY.. not "" for the empty key, this may be your problem, however, I can't not say for sure. DO you have the object pointed the right way, you sure the distance is correct, and you are using Radians and not degrees for your arc?

llSensor(name, NULL_KEY, AGENT, distance, radius);

You would really need to post the whole script for us to debug it.
But from this one fragment that you did post:

"// look for an avatar by a particular name"

If you are looking for the location of one specific avatar then don't use a sensor, use llGetObjectDetails with the key of the person you are looking for instead. This bypasses the limit on both number of returns and distance and will work for the total sim.

Are you using states other than default? If you do llSensor in one state, it'll only trigger callbacks in that same state..

Like, this won't work:

default
{
state_entry()
{
llSensor (....);
state x;
}
}

state x
{
sensor (integer count)
{
...stuff
}

no_sensor()
{
...stuff
}
}

PS
"" instead of NULL_KEY is perfectly acceptable, is interpreted the same way, and saves 27 Bytes

NULL_KEY is 39Bytes to declare, an empty string in code is 12. 10/22 if declared globally (lsl/mono).

If you are not getting even the no_sensor() event, then the problem is not in the arguments to llSensor(). Is your script yielding? Or could it be sitting in an endless loop waiting for some global to be altered by one of the sensor events? (This will never happen until the script yields by returning from the other events such as state_entry())
~Boss

plus the fact that your code doesn't show your function being called, or how those variable you use in it are being populated = it's pretty hard to help. context is important.

No, that's not it. I have another script that uses "" instead of NULL_KEY and it works fine. In fact I think some of the scripts distributed at THE PARTICLE LABORATORY use "" there. It doesn't make a difference.

I'm not posting the whole script. It's not going to happen. There's such a thing as intellectual property rights, and other issues.

The reason for using sensor is because the particular avatar is not known in advance and has to be found at run time. Sensor is appropriate.

I've been doing programming for over 20 years, in a variety of languages. One of the things you learn to do when there's a problem is to break things down into the simplest form, the simplest example, to see where the problem is. That's what I've done.

And, the context is not important here.

The problem is that while the script "activates" and functions up to the point where llSensor calls but then seems to fail with neither sensor or no_sensor activating is the important point. What can cause that? The way the language is defined, it should never happen - one or the other should always activate.

LMAO OK................

Sorry, Sariel but we can not help you here. Looks like you are going to have to resolve those "other issues" by yourself.

It is happening because you have a flaw in your design and we can not see that design to spot the flaw. You really need to look through this forum or the various libraries and see the examples we unselfishly donate for others to learn from. Examples that we could instead sell our selves. As far as that goes, why should we even help anyone when they will turn into competition? Instead we donate hundreds of hours per year, with no thought of compensation, helping others to learn and grow.

Your claims of IPR are not going to have a sympathetic ear here.

Are you using multiple states?

Do you have code that isn't returning? LSL is single threaded and event based - if you don't return the thread back to the sim, callbacks (like sensor/no_sensor/etc) will never get called..

Well then what you can do is write a _complete_ skeleton script, not invalid fragments, that demonstrates the problem.

One thing I know does not work well, is to make more than one llSensor call inside a single event handler. If you have multiple names to check, feed them to yourself one by one with link messages or something like that.

do_effect() {
//some set up stuff
// look for an avatar by a particular name
llSensor(name,"",AGENT,distance,radius)
llOwnerSay("After sensor";
}


Maybe you have something like this:

do_effect() {
//some set up stuff
// look for an avatar...
if (AV_name == name);
llSensor(name,"",AGENT,distance,radius);
llOwnerSay("After sensor";
}

// Your snippet is already missing ; in places, maybe you have an extra one somewhere or some other common mistake.

Then strip the script down to a working example that runs and shows the problem.

Well with 20 years of coding experience, a person doesn't have to build like we do. They don't have to script a simple sensor and get it working and then start layering in the messaging and then the state changes and then other aspects of the total script, checking at each stage that there are no mistakes. Nope much easier with a new language to just throw it all together at once and then try to debug it. But what do I know, I only know a handful of languages and have only done it for 3 years. But wait, mine work.

Sorry, but this guy's replies to both Void and myself just really, really, rubbed me the wrong way.(just in case no one noticed)

<faux-innocent>I can't imagine why</>

"Guys, I've been programming for 245 years and I'm an expert in every programming language in existence. I have not written a single bug in over 100 years. Clearly the scripting language is broken. No, I will not show you any other parts of my script."

Ok, we agree, the language is broken. Let's all move on.

providing the value for some of the variables would go a long way too. Like 'name', 'radius', and 'distance'.

This, plus the OP's reference to "// various states" suggests that the problem may be that the sensor and no_sensor events are somewhere other than the default state, as a couple of people have suggested. It could be a simple misunderstanding about the difference between states and events -- confusing concepts if you're new to LSL. They were confusing to me, and I have been writing programs since the Fortran II days of the early 1960s. Of course, I'm not a pro.

There you go, traumatizing poor innocent variables by implying that some are more "valuable" than others! How do you expect positive outcomes from your software development environment with that kind of neanderthal approach?

/me still bets that he (he?) is calling sensor in one state and has the callbacks in a different state..

He says the OwnerSay after the llSensor call happens but that he never gets called back. Regardless of radius and "" vs NULL_KEY or anything else, it should always kick either the no_sensor or the sensor callback. Unless he changes state. Or unless he isn't giving the thread back to the VM..

hehe, learn something new every day. Is there a page with the list of this type of things, how the compiler interprits things and such. I figured that "" means exactly that, an empty string, where NULL_KEY is all 0's. Didn't know that the compiler interpreted an empty string as NULL or visa versa. Anyways, is there a reference for these memory saving tricks, especially with the new memory limitations coming up.

actually it interprets anything that doesn't fit the key format AND NULL_KEY as... well invalid and therefore NULL_KEY =) [slight exception, apparently mono will strip spaces from a key when determining if it's valid or not, but then might fail a comparison to the same key without the trailing space, it's been jira'd, bad inconsistent behavior, and doesn't occur in LSO]

these should be a good start
https://wiki.secondlife.com/wiki/LSL_Script_Memory
https://wiki.secondlife.com/wiki/LSL_Hacks

(last link only includes LSO, not mono, but is a little easier to read)

this is helpful for indirectly related resons of sim performance
https://wiki.secondlife.com/wiki/LSL_Benchmarking_Scripts

some other helpful stuff
https://wiki.secondlife.com/wiki/LSL_Script_Efficiency