Research Project 1: Phoenix Viewer Radar feed

I like to know what I’m walking into as often as I can.
So a radar that lists me all avatars in a region, along with their distance from me is a great way of discreetly keeping an eye on what I can’t always see; from people trying to be sneaky to those teleporting up/down&across the map.

But the obstacle in the face of accomplishing this in LSL is a formidable one;
scanners only work in spheres.
A)  To scan an entire sim, we would need to deploy multiple drones that spread out and zoom up and down the map to give us updates, which is resource-expensive.
B)  llSensor/llSensorRepeat can already be rather heavy in processing demand, especially for wider radii and fast repeat succession.
C) All in all, a good radar system is hard to make low in lag. There is just a lot going on in trying to see the whole sim’s activity.

Well, take a gander at this \/

The concept of Phoenix Viewer’s radar feed is actually really simple.
Getting it, however, without any walkthroughs and very little documentation on tapping into the radar, took some time and mistake-making to understand.
But there are three key components to this bridge:
1) Opening ears to the feed
2) Organizing the feed into workable values
3) Creating/updating the avatar list

*note* read before moving on > http://wiki.phoenixviewer.com/doku.php?id=avatar_list_radar
and pay heed to the section near the bottom of the page marked Options Tab about Announcing Keys to HUD.

So, we begin with easy-peasy-lemon-squeezy piece #1:

llListen(-777777777,”",”",”"); 

Phoenix Viewer uses a system of 3 pieces of information stuffed together and separated by commas, which is broadcasted anytime an avatar leaves or enters the sim. You will know which is the case by the second value separated by commas, an integer indicator which is 0 for an exit notification, and 1 or greater for an entry. The third segment will be our one or more keys, also separated by commas. The first value in the feed, however, is still a complete mystery to me.

So we might see something like:

This raw stream is of little use as is. We’re compiling keys, so that we can extract the names and distance from our avatar.

Ideally, we want to take

7256,4,b2d574b8-b293-4d0d-xxxx-a236367523fb,8277ec64-d8e1-4e23-xxxx-52bcdba0e33b,30db3442-0d5d-40e2-xxxx-d345279bec23,77f43037-6edb-44ae-xxxx-816f7b48333c

and compile it into a list like so:

7256
4
b2d574b8-b293-4d0d-xxxx-a236367523fb
8277ec64-d8e1-4e23-xxxx-52bcdba0e33b
30db3442-0d5d-40e2-xxxx-d345279bec23
77f43037-6edb-44ae-xxxx-816f7b48333c

This, too, is a one-liner of code to accomplish.
Ref lookup: llParseString2List(string src, list separators, list spacers); 

7256 means… I dunno.
4, being a positive number, tells us that we have 4 keys to add to the list.
Then we have the keys themselves.

If we were to see:

27338,0,8277ec64-d8e1-4e23-xxxx-52bcdba0e33b

It would mean that our buddy #2 has left, thus to remove this key from the Is Present list.

On occasion, we cannot wait for a person to exit/enter the sim to get an update, for we may have just entered ourselves. llTriggerSound the UUID: 76c78607-93f9-f55a-5238-e19b1a181389 to force a refresh of the feed.
(Currently, there is a bug in the functioning of the sound-triggered update. See http://jira.phoenixviewer.com/browse/PHOE-1023 for info)
*Update* bug resolved!* llTriggerSound of the key above works again.
But mind you, it is TriggerSound, not PlaySound. I’m not sure of the reason why, but I had to learn it the hard way. May have something to do with the fact of one making the sound attached to the object, and the other not.
Ref lookup: llTriggerSound(string sound, float vol); 
Ref lookup: llPlaySound(string sound, float vol); 

Let’s Bridge already!

Alright, I’ve talked enough. Get the Phx Radar Bridge script and follow along.

The very focal point of this script. The sacred list.

No need to re-explain, but this is where it all begins.

When a string of radar feed comes in, it is split into a flag and our keys [I simply extract the int flag and slice off all but the keys].

For each key we hear in the feed, we want to check for its existence in the noob list already, to avoid overlap or removing things that don’t exist, and casually avoiding catastrophe.

In laymans terms, it says that we’ll only add a key to the list if our flag is a positive number, if the key is not already in the list, and the key is not our own.
To remove, the flag will be 0, and the key should already be in the list, and its index, the value of nubFound, is positive.

Now, we get into displaying our list of unsuspecting suckers.
Two things are retrieved using the key: the name and the world position, which is used in determining the distance between the both of you.
Meanwhile, a multi-lined string is compiled as we go, and this shall be the display engine.

But wait, there’s more!!

Included in the package are a few Deluxe features.

Sim crossing refreshing.

Live updates on distance changes.

And by the end of it all, we find ourselves with something like this

Advertisement

~ by buddhatron on September 10, 2011.