Now this is worrisome...

Just did...

Keiki, did you look at the lsl wiki entry for this command?
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llgetobjectdetails

Shouldn't SVC-774 be changed to a feature request? The command appears to me to be working as designed and thus there is no bug, it is just being used for an unforeseen purpose. This is why I wanted Strife (as a person active in the scripting community) to take a look before filing anything in Jira ... I know the command has been discussed fairly actively by scripters lately, maybe it's all taken care of already.

For example, look at: https://jira.secondlife.com/browse/VWR-2295
This is a feature request on the same command, asking that it be changed to return even more info on avatars.

To me, SLX's approach as quoted above seems to be the only way to approach Linden Lab's TOS. I feel like you just never know. Check out this:

http://www.secondlifeinsider.com/2007/10/05/guess-what-will-get-you-banned/

To me, SLX's approach as quoted above seems to be the only way one can approach Linden Lab's TOS. I feel like you just never know. Check out this:

http://www.secondlifeinsider.com/2007/10/05/guess-what-will-get-you-banned/

From the wiki:
That seems to say to me that it shouldn't return the position of an avatar after it has teleported away.

It does seem like a bug or an unintended feature. If that is the case, they should move swiftly to correct it before more people make and buy content using this.

There are two other things which are alarming here: This thing is now #3 in sales - note the speed of the advance from #5 (and at $L1500, at that) -- and the seller is apparently using a free public domain script and selling it for $L1500!!!

I believe the product promotion material makes it clear that you must follow the av to the new sim in order to track their next tp. In short, you must stay within 96 meters if them all the way wherever they go.

Read this again. You must be in a scripted area. If the location has scripts off it will not work.

Just saw that there's a JIRA issue open to address this exploit: http://jira.secondlife.com/browse/SVC-774

Yep. Well, probably they repackaged it a bit... the sad part is that the buyers just don't know they can get the same functionality for free. But what's worse is that the script will cause enormous lag for all other scripts in the sim, and it apparently must do so in order to work at all. So with such high sales, LL will be pretty motivated to correct llGetObjectDetails() to work according to contract, just to control the lag these things will be causing all over the grid.

So, in summary, people are paying L$1500 for a very laggy script they could get for free, that won't work past the next release, and could get them banned. Such a deal.

It does have timers and sensors which have to be pushed to the max to work, but in fairness, if the script scheduler is working properly, the only script that should be slowed down in a busy sim is itself.

It is a ripoff to charge so much for something that uses an exploit, is already freely available and will likely be rendered useless in a future release.

Gee, I don't think it works like that. This thing is gonna use a timeslice every frame, isn't it? And surely the scheduler isn't so primitive as to give every script a fixed-length timeslice, is it? I mean, if it did that, then no script could be laggier than any other, and the Estate tool for Top Scripts would make for awfully tedious reading.

vector last;

default
{
timer()
{
list post;
post = llGetObjectDetails("2f85ef9d-19e8-4a2a-8b9a-5e8f3e25438d",[OBJECT_POS]);
vector tmp;
tmp = llList2Vector(post,0);
if(tmp.x > 256 || tmp.x < 0)
{
last = tmp;
llOwnerSay("Agent has left the sim.";
llOwnerSay((string)last);
llSetTimerEvent(0);
}
}

state_entry(){
llSetTimerEvent(0.0001);
}

touch_start(integer n_m)
{
llMapDestination(llGetRegionName(),last,<0,0,0>;
}
}

list keys = [];
vector last = <0,0,0>;

default
{
state_entry(){
llListen(3,"",llGetOwner(),"";
llSensorRepeat("",NULL_KEY,AGENT,96,PI*2,1);
llSetTimerEvent(0.00001);
}

timer(){
integer i=0;
list temp;
vector raw;

@home;
for(i=0;i<llGetListLength(keys);i++){
temp = llGetObjectDetails(llList2Key(keys,i),[OBJECT_POS]);
raw = llList2Vector(temp,0);
if(raw.x > 256 || raw.x < 0 && llKey2Name(llList2Key(keys,i))!="Pinkie Piek"{
llOwnerSay(llKey2Name(llList2Key(keys,i)) + " has left the sim to " + (string)raw);
last = raw;
keys = llDeleteSubList(keys,i,0);
jump home;
}
}
}

sensor(integer n_m){
integer i=0;
for(i=0;i<n_m;i++){
if(llListFindList(keys,[llDetectedKey(i)])==-1){
keys+=[llDetectedKey(i)];
llOwnerSay("Indexed: " + llKey2Name(llDetectedKey(i)));
}
}
}

changed(integer c){
if(c == CHANGED_TELEPORT){
keys = [];
}
}

touch_start(integer n_m){
llMapDestination(llGetRegionName(),last,<0,0,0>;
}

listen(integer c, string name, key id, string msg){
llMapDestination(llGetRegionName(),(vector)msg,<0,0,0>;
}
}

I found another ripoff on SLX.

It's a freebie called the "Gendar".

Its ad copy touts it as being a HUD that will tell you "who the nice and not nice people are" in a group, and whether or not an avatar represents it's player's Real Life gender.

How can a no-cost item be a ripoff?
1. The list of "qualified" people is old, and contains only a tiny fraction of the current SL population.
2. If you attempt to go to their website and "verify" yourself, you get one of those "your computer may be infected with spyware" sales pitches that works by actually infecting your computer with a rather nasty bit of malware.

[Edit] Apparently, the Gendar site was hacked. The vendor fixed it, and removed the malware ads. However, I still think this product is a ripoff. It charges you $10L every time you "rate" somebody. You are allowed to "rate" them as Nice or Nasty, Boy or Girl. Nice or Nasty I can go along with, but "Boy or Girl"? We've debated this, and decided that there's no way of knowing...so why should votes count?

But if you want to get "gender certified", you can...through PayPal, with a credit card with an appropriate male or female name, for a fee of $5.00.

This thing wants money every time you use it!

Maybe someone with a little better understanding can shed some light on it, but the script scheduler does make sure that one script doesn't use up all the resources for a particular sim. I remember when they put that in. If many people used them in a busy sim, it might have an impact, but 1 person using that script is not going to make much difference either way.

No, I don't think you have to tell them but I for one will be wary of any future dinner invites over to your place. Scary mind pic!

Oh no! What kind of things will get broken? Just griefer tools or things like vehicles?

I can't see vehicles using the kind of bug that the weapons were using - which basically involved rezzing physical objects near to, on top of, other avatars to exploit the physics errors that occur when objects intersect.

But in answer to the original question, it's because the market demands it. Since Hyperorbit became possible (I can't remember who invented it) suddenly your system is just Better if it contains it. I've seen several people who were making themed gadgets or other items suddenly find they lost a huge amount of sales because they didn't include weapon-style attacks in their products and didn't want to.

I suspect it's to do with the feeling of "having power over others", even if it's never used.

As I understand it, the main, official map used to let you track av's anyway. This feature was taken out because some sensitive types complained about how it was used (they were stalked, which I guess one can think of as "being found guilty of posession of a nasty-hot av".

Presumably the scaffolding that lets this work was left in the system, and that's how these HUDs work. personally, I don't really get bothered about those who use them: so they discover stuff - big deal. They then have to choose how they use that knowledge, and that's when the fun starts. Most people dumb enough to think a tool like that is cool, are also going to screw up the aftermath of it's use.

In the old news he were abnle to track friends. But since there are so many griefters getitng in to people friends listing. LLABS stopped the feature. But what made things worse was P2P place to place teleporting. It cause all sort of problems of people following you. This device is just as bad as that of tracking people online as friends.

Educated guess as to how/why this works...

When you teleport to another sim you spend a little time as a child of that sim - in limbo.

It seems that at some stage during this transition llGetObjectDetails can still access your position data and returns the position you are teleporting to, relative to the current sim. Without testing I wouldn't know how long this data is available for but it certainly seems to be available at the point where the avatar 'officially' leaves the sim.

When the script calls up the map, it calls up the current region, but gives these relative co-ordinates as a position, at which point the map simply moves that number of metres from the current sim and displays whatever is there - in this case, the sim where the avatar TPed to.

The solution ?

LL need to shuffle code around a little. Just make sure that the avatar leaves the sim (I'm guessing this is a flag in the code somewhere ?) BEFORE the new co-ordinates are set.


As to lag...

This sort of coding will cause a load of it. While I have no access to server code, from inspection of the time stats the way server load is managed is...

1 - Reactive - When you trigger this thing it will cause a major lag spike before the server has a chance to react and attempt to correct things.

2 - Primitive - I don't know the algorithms used, but it looks like it's based on predicting the load in the next frame, and it gets it wrong a lot of the time, especially when it varies significantly.

Max

Vehicles are fine, it's just the 'blitz', 'toss', or 'ownage' style no-push orbiters that I was talking about. They worked by using a bug or something in havoc 1, but havoc-4 does not have that bug so they don't work. Hopefully that means an end to being orbited on no-push land.

-Atashi

There's a far easier workaround - check if the coordinates that llGetObjectDetails is about to return are outside the 0-255 range, and if they are, return NULL instead.

WHAT are we looking at? I didn't see anything in that link that resembled what this thread is about. Did the item get removed?

I believe that the item was a scanner using a recently discovered scripting loophole which enables you to find, when an avatar teleports away, where they went.