Library: Object Radar

I created an Object Radar.

this is direct copy and paste from the object.
it is also availiable on SLExchange.

//yes, it IS an object radar. Yes, it is modifiable. Yes, i am giving it away for free. YOu are not dreaming. Albeit not perfect, it still is very usable. Change it however you want, take the script out, change the script do whatever. but please, MAKE IT FREE. The idea is that i want my scripts to be free and open to everyone. This is because i learn best from example, and i wanted an object radar. I want others to learn from this example, and make knowladge free.

integer obj;
string display;
default
{
touch_start(integer lol)
{
llSensor("",NULL_KEY,PASSIVE|ACTIVE,20.0,PI);
}
sensor(integer num_detected){
for(obj=0;obj<= num_detected-1;obj++){

string display = (llDetectedName(obj)+" "+(string)llDetectedPos(obj)+"\n"+ display);


llOwnerSay(display);
}
}
no_sensor(){
llOwnerSay("lol, nothing?";
}
}

as an added note, for some reason, the object radar only displays up to 15 objects at a time. Why it limits it to 15 is beyond me, as i have not beenn scripting for long. Is it possible that it could be expanded? I dont know. But I do know that this method is 5 more than my first attemt at this script, and that one lagged alot due to 10 implementations of llSensorRepeat.

Sensor events only return 16 total objects. The reason you saw 15 and not 16 is your loop syntax is off; try using (i = 0; i < num_detected; i++).

the FOR loop increments the object index numbers from 0 to total -1.

The OP way is still stupid.

the best way is:

for( obj = 0; obj < num_detected; ++obj )


++obj is faster than obj++.

Also OP, please don't use variable names like lol in your program.

I have a related question.

What is a way to get more than 16 avatars detected? I tried making 2 objects with llSensor but they seem to detect same avatar names. I use same range and PI for each of them. Perhaps I need to limit the arc and have them looking out in opposite directions?

What's really stupid is insulting people and then asking for help.

Yes, sensors scanning different areas, or a rotating sensor, would be the only way to detect more than 16 avatars.

Well the OP's code looks atrocious yet he makes it sound like an ultimate freebie or something. I can understand newbie mistakes and problems, but OP was kinda asking for it. Sorry for flame though.

Thanks for your comment, I know what to do now. One more quesiton. The x-axis changes with the object's rotation, right? Or would I have to use some trick to sensor in a direction thats not +x?

Try this: http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSensor for a visual depiction of a sensor -- there's even a video. You would need to rotate the object on its z axis.

NO the OP was NOT asking for it. The OP gave of their own free time without asking for recompense to post a script that they were proud of.

If you come back and ask for help then no problem, that is what we do here. If you come back to insult other people's scripts, then just don't come back. We do not take kindly to this.

Anybody tested if this is still true with mono? (edit: I suspect it may still be true but not as true as it used to be - probably to the point where it's almost in the noise)

Jeran42: just as a suggestion, you don't really need to declare variables as global if they're only used in one function and, if you do declare things as global, it's a really good idea to get in the habit of giving them names like 'gVariable' instead of just 'variable'.

In your sensor handler, for example, you say 'string display = ...' but you also declare a global string named 'display' at the top of the script. The net effect is that anything that uses the string 'display' in a function _other than_ the sensor event will use the global one and the sensor code will use its own local one - these are two separate variables. Not really a problem in this particular script but it will drive you absolutely nuts when it bites you for real.


Two posts since the year-old join date, both of which are in this thread. I'm tempted to log in and see if they're partnered.

It isn't a matter of speed using pre-increment over post-increment. Pre-increment (++obj) adds 1 to obj right now and post-increment (obj++) waits so that the added 1 will not be in effect until the next cycle.

I am pretty sure this is wrong. In both cases, ++obj and obj++ the end result is that obj is incremented by one in the same iteration, so switching between pre and post increment does not change the logic of the FOR loop.

I know this to be true for Java and C/C++ but perhaps LSL is an exception? Or perhaps I misinterpreted your statement.

Well then you would be wrong. Test it for yourself in a script.

default
{
    touch_start(integer total_number)
    {
        integer a = 1;
        llOwnerSay((string)(a++));
        llOwnerSay((string)a);
        llOwnerSay((string)(++a));
    }
}

returns:
Object: 1
Object: 2
Object: 3

And I would check again in all of the languages you mentioned. This is the way increments work. It does not matter if you use ++a or a++ if it is not used in a formula at that moment and this is the mistake people commonly make including myself at one point. But if you use it in a formula then pre-increment is the only one that will work like you want. In either case, one does not execute faster then the other.

Looks like you're wrong: http://wiki.secondlife.com/wiki/LSL_Script_Efficiency

Also my point was that logic of FOR loop doesn't change at all if you use ++obj or obj++ as third statement in it, which is true.

default
{
touch_start(integer total_number)
{
integer a = 1;
for( a = 0; a < 5; a++ ) llOwnerSay( (string) a );
llOwnerSay( "=====" );
for( a = 0; a < 5; ++a ) llOwnerSay( (string) a );

}
}

outputs:

[23:15] Object: 0
[23:15] Object: 1
[23:15] Object: 2
[23:15] Object: 3
[23:15] Object: 4
[23:15] Object: =====
[23:15] Object: 0
[23:15] Object: 1
[23:15] Object: 2
[23:15] Object: 3
[23:15] Object: 4

default
{
    state_entry()
    {
        llResetTime();
        integer a = 0;
        while(a < 1000)
            a++;
        llOwnerSay((string)llGetTime());
    }
    touch_start(integer total_number)
    {
        llResetScript();
    }
}

a++: 0.022371
a++: 0.022340
a++: 0.022238
a++: 0.022061
a++: 0.022357
a++: 0.022546

default
{
    state_entry()
    {
        llResetTime();
        integer a = 0;
        while(a < 1000)
            ++a;
        llOwnerSay((string)llGetTime());
    }
    touch_start(integer total_number)
    {
        llResetScript();
    }
}

a++: 0.022442
a++: 0.022447
a++: 0.022405
a++: 0.022077
a++: 0.022305
a++: 0.022136
Taking into account any sim flunctuations, this shows that they take the same amount of time to execute.

Empty sim in Aditi with a Total Frame Time of 0.2-0.3ms and script time of 0.1ms.
You have to pump it all the way up to 100,000 iterations to notice a statistically noteworthy difference of 0.022187 total run time, which comes out to ++a is 0.0000002 seconds faster then a++ .

Er.. I don't think that's right, Jesse!

With a for loop, the final bit is a separate statement so pre- vs post-increment doesn't matter.


Thanks for testing this!

Those wiki pages should probably get updated to say that they're pre-mono stuff..

I've been writing compilers for 30 years, I've worked on the LSL compiler, and both "x++" and "++x" are evaluated at the same time. The only difference is the result of the expression.

Sophisticated compilers may do things like convert:

for(i = 0; i < 10; i++) j++;

Into:

i =10;
j = j + 10;

But the LSL compiler (regardless of the target bytecode) is not a sophisticated compiler, and the peephole optimiser in Mono does not have the semantic information to easily perform that kind of optimization... and I would be astounded if it did.

And regardless of the details of optimization, semantically, the only difference is that ++x is implemented with pseudocode something like:

plusplusx(&x) {
push val(x) on stack
increment top of stack
duplicate top of stack
pop top of stack to x
return
}

While x++ is implemented as:

xplusplus(&x) {
push val(x) on stack
duplicate top of stack
increment top of stack
pop top of stack to x
return
}

Thank you for this, I actually learned from it. Can you link or talk about what actual optimizations do work in SL? Apparently official LSL wiki pages are either inaccurate or old. Also, how do you guys implement parser/compiler for LSL? is it something like flex/yacc or do you use some other compiler/compiler?

The source code of what was THE compiler until recently is in the open source client. That's the version I was working on, I'm not at Linden Labs.

See indra/lscript/lscript_compile/*.

I understand that in a for loop that the a++ or ++a is standalone and that it is actually a statement, a test and then the formula which could be written as ++a, a++, a += 1 or even a = a + 1. I was talking increments in general and in formulas. I wasn't very clear on that because I was still seeing red. I have been in enough scripting forums where everyone attacks a noobie script unmercifully. I am sure Jeran42 is long gone from SL by now but I never want the image projected that we are less then welcoming with people just learning their very first language.EDIT: OOOPS I was looking at join date NOT the post date. Come on out and play again where ever you are Jeran42!

I had never looked at the wiki page on it but had done all of my own benchmarking when MONO came out. I am not sure looking at all of the extra fluff in the wiki script if it was even a valid test. I always strip my down to the barebones so that other functions, events or especially state transitions aren't figured into the equation and then throw in a llResetTime right above the point I want to test for good measure.


As far as optimizations in general for lsl go, MONO is so fast that most have been thrown out the window and it is just a matter of personal preference now. The only gotcha which aanoyone should be aware of is that state changes can pay a hefty time penalty in MONO.

I hope not! Even though it isn't a script I'd use, I'd rather have somebody productive here than more flamers..

/me confesses to not understanding the negative reaction the OP received.

I understand someone learning a new langauge and going through pain of learning. I have been there myself, but OP posted his horribly written script and described it as some awesome freebie that should be free and not sold (why would anyone want to buy this anyway). There is really nothing new or special in that script, and theres a better example on LSL wiki (http://rpgstats.com/wiki/index.php?title=Sensor) of how to get all detected objects.

If you are sharing your program, you should make sure that variable names make sense, a more or less sane style is used (no obj <= total_num -1) and that it is correct overall. Other newbies would get very bad ideas looking at OP's script. Otherwise ask for help with it and how it can be improved, but do not try to push it as some amazing freebie.

I certainly hope that Jeran42 is hanging in there. I also hope he keeps on learning and continues to take pride in his work. It takes guts to put your creations on public display, especially where they may get ripped to shreds by veterans. When Jeran42 is a veteran himself, I hope he remembers what it feels like to be a newbie and is kinder to the exhuberant, inexperienced ones who want to show him their first work.