What's wrong with this script?

integer  Range     = 40;
float    Arc       = 2 * PI;
float    Frequency = 10.0;
list     Previous;
integer  Search;
string   Target;

default{
     state_entry(){
          llSensorRepeat( "", "", AGENT, Range, Arc, Frequency );
     }
     
     sensor( integer Sensed ){
          do{
               Target = llDetectedKey( --Sensed );
               Search = llListFindList( Previous, Target );
               if (Search = -1){
                    Previous = Target + llList2List( Previous, 0, 78 ); llDialog( Target, "Message ", [], -42 );
               }
          }while (Sensed)
     }
}

Everyone here is aware, I know what wrong with it, for the sake of argument, pretend I don't... I promise it'll be enlightening...

You mean besides Search = -1 and Previous not initialized?

Don't tell I'll have to look hehe

yes I mean besides Search = -1
("Previous" not being initialized is not big deal, it's filled in the sensor event)

Is this a test? I see more than one problem, I think.

float Arc = 2 * PI;
// didn't think we could use math to define a global

Target = llDetectedKey( --Sensed );
// wouldn't you miss the last AGENT sensed? Of three agents (0, 1, 2) you'd check the UUID of agent 2 first (1), then agent 1 (0) and never check agent 3 (2)... Sensed-- instead
// and, if only 1 avatar is sensed, not sure what happens when you do llDetectedKey(-1)... does it return NULL_KEY?

if (Search = -1){
I see this was a typo, not part of the test

2 * PI cannot happen in global space and the number is dubious for sensors, PI is good or TWO_PI if good if dubious makes you smile.

do---while misses ;

llListFindList needs [Target]

we all know of the == on all the threads

The script can run then but what is the desired logic?

I guaruntee that "--Sensed" does not miss any targets in this case*

got the assignment vs comparison check
got the math error in globals
got the missing list cast in llListFindList

what else? come on, that won't even compile with those changes =P


*the sensed count is is one higher than the index needed and zero is being handled before the test. if it'd been done IN a test, then yeah you'd have lost the zero index avatar, but in this case we're grabbing them before the test, so it's safe.

The ; is in that list and it compiles.

ahh I missread your reply... ok, you got all the compile errors...

there's 3 minor logic errors left, two are more completeness than anything

ETA:
yes, it is a test of sorts... but not of the individuals answering.

integer Range = 40;
float Arc =  TWO_PI ;
float Frequency = 10.0;
list Previous;
integer Search;
string Target;

    default{
    state_entry()
    {
        llSensorRepeat( "", "", AGENT, Range, Arc, Frequency );
    }

    sensor( integer Sensed )
    {
        do {
            Target = llDetectedKey( --Sensed );
            Search = llListFindList( Previous, [Target]);
            if (Search == -1) {
                Previous = Target + llList2List( Previous, 0, 78 ); 
                llDialog( Target, "Message ", [], -42 );
            }
        } while (Sensed) ;
    }
}

don't think --Sensed is a mistake because with 3 agents --Sensed is 2 the first time.

only one of those 3 subtle errors left will actually break the script though.

declared Range as an integer, but llSensorRepeat needs a float, haven't tried compiling to see if it matters though. does it automatically use the float value of the integer, or do you you have to cast it to a float?

frequency is a float, needs to be an integer
target is a string, but being filled with a key

would you believe I forgot to count "Range"... but you're right it should be a float, thankfully the cast is added to the sensor repeat by the compiler so it's caught at run time, frequency is fine (range arc and rate are expected to be floats, only type requests an integer, and we used a constant)

"Target" should be a key as mentioned, and is currently auto cast to that type in the dialog call, same as "Range" in sensor repeat... "target is also being auto cast to list when being added to "Previous".

I counted that as one of the mentioned subtle errors, really unimportant to it running... there one more that will cause the script to blow up, and another that probably just as minor as the implied typecasts (and someone may have already realized it and just not said anything about it specifically)

so as it stands, the script compiles, runs, has all the right types, but it also crashes after a while, and "I don't know why... won't somebody please help me?"

i'd say it;s the list function maybe using up the memory, but it looks like you have it set up to only keep the latest 80 targets

all else looks fine to me, i give up lol

aww see, I was actually looking at the wrong version.. the list is indeed capped at 80 elements.... forget about the crashing...

congratulation on pointing out the errors in my manufactured errors

it does still have one minor logical error but it will run without it.

times almost up... I'm close to bed time... anyone care to take a stab at that last logical error? it's not harmful in this case but there's and assumption in there that could cause problems in other similar scripts...

ok well the last error was TWO_PI being fed to sensor repeat, which isn't harmful in this case, but the assumption would hurt scripts that relied on it when trying to do less than a full sphere.... because sensor arcs in LSL are a radius, not a span, so the correct value for a full sphere is only PI

ETA:
this entire posting was about comparing resources SLA vs the forums, response time, interest generated, completeness of answers, etc

in the process I discovered that it's also a fun and engaging way to tutor on scripting... and may take up the format again at a later time.

Okay, now let's talk optimization : I would declare Target locally

well if you insist....

list Previous;
key  Target; //-- faster here, less idle memory if in the sensor, you pick

default{
    state_entry(){
        llSensorRepeat( "", "", AGENT, 40.0, PI, 10.0 );
    }
     
    sensor( integer Sensed ){
        do{
            if (!~llListFindList( Previous, (list)(Target = llDetectedKey( --Sensed )) )){
                Previous = (list)Target + llList2List( Previous , 0, 78 );
                llDialog( Target, "Message ", [], -42 );
            }
        }while (Sensed);
    }
}

you could also use store av names, or hashes of the key to increase the storage capacity, and use detected key in the dialog... there should be no significant gain by eliminating the sensor globals for the compile size, but it should reduce the running size !~ is smaller and faster than == -1, and dumping the code for searh into where it's used, and the set for target into where it's first used saves a little on references... @loop|jump with an if test might use less space than the do|while, and used to run faster... but recent testing shows it's now slower... go figure.

was that what you had in mind? =P

Yes all depend if you optimize for speed or memory
What do you think of

err no scratch this one.. this:

list Previous;
key  Target; //-- faster here, less idle memory if in the sensor, you pick

default{
    state_entry(){
        llSensorRepeat( "", "", AGENT, 40.0, PI, 10.0 );
    }
     
    sensor( integer Sensed ){
        list l ;
        do{
            if (!~llListFindList( Previous, (list)(Target = llDetectedKey( --Sensed )) )){
                l += Target; 
                llDialog( Target, "Message ", [], -42 );
            }            
        }while (Sensed);
        Previous = llList2List(Previous, 0, 78-llGetListLength(l)) + l ;
    }
}

good point, no need to senselessly resize the list during looping... but the extra variable isn't necessary, I mean we're already being lazy and not moving the found keys back to the front like we should so how about a little more laziness...

list Previous;
key  Target; //-- faster here, less idle memory if in the sensor, you pick

default{
    state_entry(){
        llSensorRepeat( "", "", AGENT, 40.0, PI, 10.0 );
    }
     
    sensor( integer Sensed ){
        do{
            if (!~llListFindList( Previous, (list)(Target = llDetectedKey( --Sensed )) )){
                Previous += (list)Target;
                llDialog( Target, "Message ", [], -42 );
            }
        }while (Sensed);
        Previous = llList2List( Previous , -80 -1 ); //-- think that works, from memory
    }
}

OK let's just call llDialog() before adding Target to Previous (because llDialog() is asynchronous and there is no reason to wait for Previous update here) and we're good to go I think.

Cerise already pointed that out:





So, how did we fare?

Must admit losing Scripting Tips (and in particular pearls of wisdom from Void) is going to be a huge loss when the forums go (I can't guarantee I'm moving over to SLA in its current form).

Can I just say thank you to everyone who's contributed here over the years... it's been a pleasure working with you.

well that might make nanosecond difference on the first call, but it won't change the spacing between multiple detections.. the sensor DOE only run at 10 second intervals. =P

is dubious wrong? I was trying to squeeze a WHY out
to be far Cerise got it (I keep spelling that name wrong too =(
(sorry Cerise)


not as well as I expected, but still miles ahead of SLA.

part of that I think is due to some people here avoiding it because they thought it was just just for the purpose of showing newer people some simple errors that crop up. or maybe they ignored it because it was ME that posted it... I dunno.

it also points out what LL is losing as far as brain drain.... and why one big conglomerate SLA versus sub forums makes it infinitely harder to direct those talents where they are most useful...

SLA is a corporate level communication tool, questions like this wouldn't even occur in that environment because all the coders would be in one place, or at the very worst you'd direct these sort of question to that department.... you don't have that in a random pool of talented users... where different users may not only have different talent sets, but may also duplicate talents in different areas, but not all. these are key facts that I think LL is missing out on.

they're current model does make it easy to have a single source for asking questions, but it makes it infinitely harder for specifically talented users to monitor and direct their own talents to answer them.

it also gives no good means to finding answers that have a wider application than the question, forces helpers and querents alike to wade through previous replies (thankfully you CAN turn on a paged view), and makes no concession for basic static topic based information (like stickies).

the question isn't whether people will use it, it's whether people will just give it up for one the many fractured off site solutions that do all these things already... ease of communication is just as important.

not that I think you don't already know all this and more... I just needed to rant about it a bit.