llSensorRepeat -- not working when object changes owner

heyas;

okay, i made a simple script that uses llSensorRepeat to look for scripted objects that have 'fire' in the name. works great. i give it to my friend.... it doesnt work. we debug the heck out of it... the sensor is not going off.

i put the llSensorRepeat in the state entry, in the on_attach, in my function that is setting the marshmallow state every x.x timer seconds. no matter where i put it, the sensor is just NOT going off. (i have debug whispers in the sensor and no_sensor event.)

what's the deal???


llSensorRepeat("", "", SCRIPTED, 2.0, PI, 12.2);


this is the command im using. like i say, it works for me (no matter where i put it), but is not going off when i transfer the object. and yes, i put change & changed owner to reset the script.

is there some trick i am missing????

okay, i think i got it fixed.

the problem seems to be that it attaches before it does the 'change' event for changing owner.

so i put the sensor repeat in the on attach event, and put instructions to de/re-attach it the first time it is worn. that seems to cover it.

gawd.

Most objects work best if they reset the script on owner change. I do that unless it's important for the object's state to persist when passed to another owner, and it avoids a LOT of debugging.

So, as a habit, every state contains something like this:

    changed(integer change) {
        if (change & CHANGED_OWNER) llResetScript();
    }

Of course, if your marshmallow starts out white and turns brown as you toast it and you want to give it to someone after it's cooked, then you can't do this.

yes, i did that.

well, i fixed it by putting two llSensorRepeats in the fool script. one in on attach, and one in state entry.


but now, i have a sadder story.... the fool thing sometimes is totally not finding a fire.

saturday, my friend tp'd me cuz the mallows weren't toasting. this was with a new scripted fire. so im looking at the land -- scripts allowed. im looking at the fire, it is named with fire in it, im looking at the beacons, its scripted.... i put debugs in the marshmallow, and all im getting is no sensor. :(

so we take it to an empty sandbox area. no sensor.

i go back to my skybox and the same fire it was working fine with on friday. no sensor.

so i figured, its got to be sl on a bad day. they broke sensors?


sunday morning, i tested again. worked fine. i took it to show and tell -- no sensor. you cant tell me theres NO scripted objects at show and tell! it should sense SOMEthing!


okay, so what is going on here with this thing that is making it not sense? and, by the way, just how godawful is sensor repeate, anyhow? if five people around a campfire whip out marshmallows, will the entire sim fall to its knees or what? i suppose i could just make it a plain timer and have it not care if there is a fire nearby.

::sigh::

The easiest thing to do to fix it is to post the script. More then kind of hard to debug it when we have to guess how it is coded. Also remember that even though you are searching for scripted objects with "fire" in the name. The sensor you showed is going to return 16 scripted objects within range and then you would have to do an if test for "fire". You also only have a range of 2.0 meters set.

You could set the sensor like this:

llSensorRepeat("fire", "", SCRIPTED, 96.0, PI, 2.0);

That would search an area around you with a radius of 96 meters and only look for something named EXACTLY "fire" every 2 seconds. If it is named "Fire" or "fire eater" or "nuclear fire marshmallow thingy" it would'nt work.

There is no reason at all you should have two seperate sensor calls in the script if it is coded correctly.

heyas;

thanks guys, for giving me a hand with this. uh, well, for trying anyway. its driving me nuts.


i didnt post the script (i can later today), because there's nothing wrong with it. the script works fine. except when it doesnt. its the 'except when it doesn't' bit i need help with.

because the same script, in the same place, with the same campfire object worked friday, but not saturday. and it worked sunday morning in one place but not sunday afternoon in another. so... call me crazy, but i'm guessing it's an external problem :X this is my first foray into sensors, so i dont know what it could be.

so yes. i'm searching for ALL scripted objects (well, the first 16), within 2 meters only. gonna be standing next to the campfire, i dont imagine the center of such an object being more than 6 feet away. if that's what the distance is measuring -- center or root prim or whatever. okay.

and in the sensor event, im checking all the detected objects' names to see if they contain 'fire' anywhere in them, with any case.

and, when it works, it works.


when it DOESNT work, it doesn't find ANY scripted objects -- the no_sensor event fires.

this is the part that is baffling me. how can a sensor for scripted objects not be finding ANYTHING when im standing next to a scripted object? especially one that normally is detected. i mean, the passive/active whatever baffles me, but as i understand it, if the thing is putting out a red becon, its scripted, and the SCRIPTED sensor should find it. right?
finding TOO MANY scripted objects in a crowded situtation, i could understand. but it finds NONE???


also to the proper sensor use question. its neat that the marshmallow only toasts when its near an actual fire (and that it doesn't care which fire it is). but is this an extravagant use of a resource-hogging function? if five people sit around a scripted fire toasting sensoring marshmallows, will we crash the sim? lag it to death? i just don't know. i did toast about a dozen marshmallows at once with no noticeable problem. or-- if sixteen people whip out marshmallows around a fire, will the 17th one not find the fire for finding all these scripted marshmallows before the fire???? i just don't know. does it sense attachments? how does it number them? (im presuming by proximity, with the closest one being first.)


practical applications are fine. its this theory i'm lost on. :)

This is pretty reasonable use of sensor, depending on how often it runs.

First, it's unlikely that lots and lots of marshmallows will be out at the same time, all the time. This will be more of an occasional thing.

Second, and more significantly, the sensor range is short. That really helps.

Third, make sure the interval is reasonably long -- at least a second and maybe as much as 5.

Finally, the key to understanding script lag is to count the total number of times an event handler is called, in all objects with the script, in the sim. Worry when you get numbers in the hundreds or larger. Don't worry for numbers below 10. In between is a gray area.

Also, it's imporant what the script does in the event handler. If it does massive number crunching, the rule-of-thumb numbers need to be adjusted downwards. Above I assume you only have a few LSL calls per event handler -- and simple ones at that. (A better rule of thum might be to multiply the number of times the handler happens by the number of LSL calls -- but different calls have such different impacts on performance ... maybe not.)

This is not proof positive that the script has no bug. However, it's entirely up to you whether to post or not. We just can't help you much otherwise.

Consider writing a stripped down script that does nothing other than exhibit the bug, and post that. It's a very useful exercise for a number of reasons.

okay, i did more testing.

i changed the sensor repeat to just a sensor on the timer. that way, it only goes off when it needs to know if it should change toastiness or not. i also changed it to a half sphere in front of the avatar, so no toasting mallows behind your back. i also found out the following:

1: the distance of the sensor is... either to the root prim, or to the prim with the script in it. (the linden freebie campfire has the root on one of the side logs). if the range is too short and i stand on the other side of the fire from the root, i get no sensor.

2: i dunno if the range is actually HALF the input range (diamter instead of radius?), but changing it to 4 or even 5 meters works better to give me things im standing within a few 'feet' of.


3: it still flaky. sometimes it finds an object when i am holding (editing) it, and then stops finding it when i 'let go.' (close the edit palette.) sometimes it finds things off to the side, sometimes it doesnt find them when they're right smack in front of me. if i put two things on top of each other, sometimes it finds both, sometimes only one.
i just cant get a consistant result.


here is the script. like i say, it works fine. when it works.

this goes in an attachment. you need a scripted object with the word 'fire' anywhere in its name to activate the sensor. oh.... the script is in a child prim in the attachment. does THAT make any difference????



//----------------------------------------------
//-- Toasting Marshmallow
//-- by bloodsong termagant
//----------------------------------------------
// touch - vanish and start new one.
// sense "fire" to toast
// should take about 5 mins
//-----------------------------------------------

vector colour0 = <1.0, 1.0, 1.0>; //--new
vector colour1 = <0.84, 0.7, 0.6>;
vector colour2 = <0.80, 0.63, 0.35>;
vector colour3= <0.54, 0.4, 0.25>;
vector colour4= <0.3, 0.2, 0.04>; //--done
vector colour5= <0.1, 0.07, 0.03>; //--burnt

integer STATE = 0; //-- -1 = gone


setState(integer n)
{
if(-1 == n)
{
llParticleSystem([]);
llSetAlpha(0.0, ALL_SIDES);
llSetTimerEvent(22.0); //--how long to be marshmallowless
}
else if(0 == n)
{
llParticleSystem([]);
llSetColor(colour0, ALL_SIDES);
llSetAlpha(1.0, ALL_SIDES);
llSetTimerEvent(15.5); //--x5 = how long to toast before set afire
}
else if(5 == n)
{
llSetColor(colour5, ALL_SIDES);
llSetTimerEvent(20.0); //--burn a while
llParticleSystem([
PSYS_PART_FLAGS, PSYS_PART_EMISSIVE_MASK | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK,
PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_SRC_ANGLE_BEGIN, -PI_BY_TWO/2,
PSYS_SRC_ANGLE_END, PI_BY_TWO/2,
PSYS_SRC_TEXTURE, "fire_1",
PSYS_SRC_BURST_RATE,0.1,
PSYS_SRC_BURST_PART_COUNT,5,
PSYS_PART_MAX_AGE,0.75,
PSYS_SRC_ACCEL,<0.0, 0.0, 0.07>,
PSYS_SRC_BURST_RADIUS,0.12,
PSYS_SRC_BURST_SPEED_MIN,0.05,
PSYS_SRC_BURST_SPEED_MAX,0.1,
PSYS_SRC_OMEGA,<0.0, 0.0, 0.1>,
PSYS_SRC_MAX_AGE,0.0,
PSYS_PART_START_SCALE,<0.05, 0.08, 0.0>,
PSYS_PART_END_SCALE,<0.15, 0.35, 0.0>,
PSYS_PART_START_COLOR,<1.0, 0.5, 0.0>,
PSYS_PART_END_COLOR,<1.0, 1.0, 0.75>,
PSYS_PART_START_ALPHA, 1.0,
PSYS_PART_END_ALPHA, 0.0
]);
}
else
{
vector col1; vector col2; vector col;
if(1 == n)
{
col1 = colour0; col2 = colour1;
}
else if(2 == n)
{
col1 = colour1; col2 = colour2;
}
else if(3 == n)
{
col1 = colour2; col2 = colour3;
}
else if(4 == n)
{
col1 = colour3; col2 = colour4;
}
//--okay, this gets fancy; bloodsong tries to smooth change colours!

integer x;
for(x=0; x<=4; x++)
{//--twelve steps
//--going from 1 down to 0. stopping at col2, lowest.
col.x = col1.x - (col1.x - col2.x)/5;
col.y = col1.y - (col1.y - col2.y)/5;
col.z = col1.z - (col1.z - col2.z)/5;
llSetColor(col, ALL_SIDES);
llSleep(2.2);
}

}


STATE = n;
}


default
{
state_entry()
{
setState(0);
llSetTimerEvent(15.5);
}

on_rez(integer orn)
{
// llResetScript(); //--this borks the anim permissions, so leave off
}

attach(key id)
{
if (id != NULL_KEY) // object has been //attached//
{//--this always asks, in case you dont want to animate yourself
llOwnerSay("If you are a tiny, or not using right hand, deny animation permission.");
llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION); llSetTimerEvent(54.4);
}
else
{
if(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)
llStopAnimation("hold_r_handgun");
}
}

run_time_permissions(integer perm)
{
if(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)
llStartAnimation("hold_r_handgun");
}

touch_start(integer total_number)
{
if(llDetectedKey(0) != llGetOwner()) return;

if(-1 == STATE) setState(0); //--if no mallow, put one on
else setState(-1); //--take it off
}

timer()
{
if(-1 == STATE) setState(0); //--no mallow timer expired, re-do one
else
{
llSensor("", "", SCRIPTED, 4.0, PI_BY_TWO);
}

}

sensor(integer n)
{
integer x;
integer SENSOR = FALSE;

for(x=0; x<n; x++)
{
string sName = llDetectedName(x);
llOwnerSay("Found: "+sName);
if(llSubStringIndex(llToLower(sName), "fire") != -1)
SENSOR = TRUE;
}
llOwnerSay("sensor found something. fire="+(string)SENSOR);

if(SENSOR)
{
STATE++;
if(STATE > 5) setState(-1);
else setState(STATE);
}
}

no_sensor()
{
llOwnerSay("no sensor");
}

changed(integer change)
{
if(change & CHANGED_OWNER) llResetScript();
}

}


as for why it needed to sensorrepeats (now timers) is because the attach event fired before the change owner event, and if the script reset after granting permissions, then the on-attach didnt fire to turn on the sensor and it was off. and if it didnt change owners and just attached, the state entry didnt run so that sensor was off.

Cool ideas. I made a marshmallow stick myself once (while standing around the fire, just as I do in RL). I thought about scripting it to toast but didn't hit on any good colors right away and never got back to it. Looks like you have a great start here.

If you don't mind, I'll fiddle with this script a bit and return the results.

For one thing, you could simplify the program by using a list rather than color1, color2, etc. There also is probably a way to eliminate the extra call to llSensorRepeat(). And I'll look into the sensor issues.

However, it'll be a few days before I can get to it. My computer just croaked!

BTW, I believe that the sensor doesn't start at the avatar, but at the prim with the script (presumably the marshmallow). It would end at the center of the root prim in the object with "fire" in the name.

Finally, keep in mind that our avs are typically very large, so an SL meter looks closer to 2 feet than to 3. The typical av is well over 2m tall.

A couple of things come to mind.

Strip the script down. Dump the particles until you have the sensor working correctly. If you have to, then dump everything or make a new script with just a sensor in it to find the problem. Then and only then do you start adding in more functionality.

llSensor("", "", SCRIPTED, 4.0, PI_BY_TWO);
PI_BY_TWO does a scan of 180 degrees, try it at 360 degrees and see if it makes a difference.

Scripted will only find an object if it is active. Does your fire have a listen or something else in it to keep it active? Try Passive and see if it makes a difference.

So just for laughs I would try this by the fire and see what happens:

integer a = 10;

default
{
    touch_start(integer total_number)
    {
        llSensorRepeat("fire", NULL_KEY, PASSIVE, 10.0, PI, 1.0);
        llSetTimerEvent(10.0);
    }
    sensor(integer n)
    {
        llOwnerSay("Woot! You did it! Add more functions to me!");
        llResetScript();
    }
    no_sensor()
    {
        llOwnerSay((string)a);
        a--;
    }
    timer()
    {
        llOwnerSay("Sorry! Back to the drawing board");
        llResetScript();
    }
}

Again that will only work if the fire is named exactly "fire".

The wiki says that SCRIPTED will find both active *AND* passive... guess not. I had llSensorRepeat() also blow this on me. Thx for the PASSIVE tip.

now if only llMoveToTarget worked!!!

Yep. That is what it says. Well actually
http://lslwiki.net/lslwiki/wakka.php?wakka=llSensor
Says in two places that Scripted only detects active objects, then in the same page says that it sense both Active & Passive.

Unfortunately that isn't what testing bears out. I tried it in Aditi before posting the test script here. I guess to be safe it would be better to use something like this:

llSensorRepeat("fire", NULL_KEY, SCRIPTED | PASSIVE, 10.0, PI, 1.0);

hey can I get some marshmallow? my friend is burning her house down for her rezzday party =)

Good spot, Jessee.

Any chance you'll update the Wiki?

Nope! Not Me!!!!
The wiki's, as in multiples, is an extremely sore spot with me. Absolutely criminal that the years of hard work put into the original was cast aside. Criminal that month after month went by with cries of "The wiki is down again". Criminal that after eveyone posting freely to help each other, LL took the stance that there could be copyright problems in copying over the original material. Absolutely no one that contributed to that labor of love would have thought twice about having it moved to a home where it would be a whole living entity, instead of fragmented pieces.

I have my old copy of the wiki and I just update new entries into it. Copy and paste anything relevant and handy. That coupled with the scripts on my harddrive and Scite is all I need.

Mr Continetal, the maya rig you posted was in a corrupted zip file.
Could we get you to repost please?

I made my own FK rig, but I would like to see what the one from orion is like.

thanks.