Jump to content

AV scanner prob


Marioni Unplugged
 Share

You are about to reply to a thread that has been inactive for 2556 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi there, here's one fur ya ;)

vector origin = <7.180, 31.280, 51.265>; // origin is lower left corner of the 3D Map's ground square ((0, 0)
vector detPos; // detected position of avatar(s)
vector newPos;
float scale = 0.01;
integer scanning = FALSE;

default
{
    touch_start(integer total_number)
    {
        if (llDetectedKey(0) == llGetOwner())
        {
            scanning = !scanning;
            if (scanning)
            {    
                llSensorRepeat("", NULL_KEY, AGENT, 96.0, PI, 5.0);
                // scan for all avatars (AGENT) with any name ("") and any id (NULL_KEY) within 96 mtr (the maximum scan range) in all directions (PI)
                // if any avatars are detected create an indexed list of them and raise a sensor() event
                llWhisper(0, "Scanning started...");
            }
            else    
            {
                llSensorRemove();
                llWhisper(0, "Scanning stopped");
            }
        }
    }

    sensor(integer total_number)
    // the sensor event is raised when avatars are detected, the number of detected avatars is passed to the script below in the parameter total_number
    {
        integer i;
        for (i = 0; i < total_number; i++)
        {
            //llWhisper(0, "Avatar name: " + llDetectedName(i));
            detPos = llDetectedPos(i);
            if (detPos.x <= 63 && detPos.y <= 63) // limit to 64 x 64 mtr parcel
            {
                newPos = origin + <scale * (integer)detPos.x, scale * (integer)detPos.y, scale * ((integer)detPos.z - 52)>;
                llRezObject("AV detected*", newPos,  ZERO_VECTOR, ZERO_ROTATION, 0);
            }
        }
    }
}

Now this all works fine. The REZZED object is a small red sphere that appears on the map, which dies after 5 seconds due to an llDie command in the script within it. A new ball is then rezzed immediatly, so we can see where each avatar is on a 64 x 64 mtr parcel.. Now what I want is floating names above each red ball ..

Any smart ideas? thx in advance ;)

 

Link to comment
Share on other sites

No, my scenario is from another sort: we rez a <number> of objects and each must be unique. Each object represents an avatar within scanning range. The problem is that each object dies after 5 seconds, whilst the actual avatar is most likely still there. To goal is to LIST their names even while they are moving, or deleted when gone ..  

Edited by Marioni Unplugged
Link to comment
Share on other sites

50 minutes ago, Marioni Unplugged said:

The problem is that each object dies after 5 seconds, whilst the actual avatar is most likely still there. To goal is to LIST their names even while they are moving, or deleted when gone ..  

So, Love Zhaoyang has the right idea, then.  Save the name when you first detect the av and then send it to a new red ball each time it's rezzed.

  • Like 1
Link to comment
Share on other sites

You can use Kira Komarov's very handy little routine Key2Number to encode the target avatar's uuid as an integer value and pass it to the ball as its start parameter.   The ball then loops through the results of llGetAgentList, encoding the uuids and comparing the results with its start parameter.  When it has  a match, it knows its target.     I often find that simpler than passing messages between the rezzer and the rezzed object.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Marioni Unplugged said:

concidering each rezzed object being the same, how would they idetify themselves? by some number when rezzed?

If you use the method I suggested, they don't need to identify themselves -- they can use the avatar's uuid, once they've decoded it, to find out all they need.

Otherwise you need to build a list of target avatars in the sensor event and then rez the first ball.   Either wait for it to send a message confirming it's rezzed (or, if you don't mind living a bit dangerously, simply sleep the rezzer script for 0.2 seconds or thereabouts, to give the ball script time to rez and wake up properly), then send it the UUID of the first avatar on your list. 

Having done that, delete the uuid of that avatar, and, if the list is not empty, rez a new ball, and carry on with the same procedure until the list ==[].

Link to comment
Share on other sites

2 hours ago, Innula Zenovka said:

You can use Kira Komarov's very handy little routine Key2Number to encode the target avatar's uuid as an integer value and pass it to the ball as its start parameter.   The ball then loops through the results of llGetAgentList, encoding the uuids and comparing the results with its start parameter.  When it has  a match, it knows its target.     I often find that simpler than passing messages between the rezzer and the rezzed object.

I thought of suggesting this too, but the OP seemed to want to display more than 1 name.."To goal is to LIST their names even while they are moving.." perhaps I misunderstood.

Link to comment
Share on other sites

52 minutes ago, Innula Zenovka said:

@Love Zhaoying Maybe I misunderstood, but I thought the little balls are meant to represent individual avatars as they move round the map.   Jesse Barnett made something similar ages ago, which is in the wiki.

Yes, when I re-read the post again it seemed to say that also. 1 rezzed per avatar. So your solution is best, I agree.

Link to comment
Share on other sites

I think many of us have probably scripted something like this at one time or another, so there are lots of solutions out there.  Maps like this used to be very  popular in SL.  Basically, It's just a matter of making a list of avatars in range, updating their positions every few seconds, creating a new marker that goes to the appropriate map coordinates, and displaying the avatar name. I like Innula's suggestion, because it puts all the business of locating the designated avatar, getting its name, and moving to the map coordinates in the script that's in the marker.  The rezzer doesn't need to do anything but create one marker per avatar and pass it the av's encoded UUID.  Nice and easy. 

The only thing that I find troublesome is the amount of rezzing that it requires.  If the region is at all busy, that much rezzing is going to create a bit of potential lag.  If I were scripting this thing, I would keep each marker alive as long as the detected av is still in range, simply moving it to a new position.  Let the rezzer create a new marker only when it detects an avatar who was not in range in the previous cycle.

Edited by Rolig Loon
  • Like 2
Link to comment
Share on other sites

1 hour ago, Rolig Loon said:

so there are lots of solutions out there

Linking 16 prims to the map prim, and doing it all from within the main prim. No rezzing, no extra scripts etc..

If it's a cylinder instead of a sphere, and the physics shape type is set to None, the land impact will be even halved.
16 would be sufficient because a sensor won't return more results anyway. Of course, using some other method to detect agents, there could be even more prims linked. The land will have to provide the same number of available prims as avatars are displayed at max anyway. Only by linking them the number of prims can be cut in half.

  • Like 3
Link to comment
Share on other sites

19 minutes ago, arton Rotaru said:

Of course, using some other method to detect agents, there could be even more prims linked.

So, you might create a comfortably large number of those cylindrical markers and activate only selected ones by making them visible when you need them. Use llGetAgentList and a timer to keep a current list of avatars within range.  Move the visible (active) markers around and control the hover text label over each marker with PRIM_TEXT in SLPPF commands with a single script in the root prim. Oh, I like that.  Nice, Arton.

Edited by Rolig Loon
Link to comment
Share on other sites

Yes nice one arton, having a fixed number of linked prims sounds really good, no rezzing needed! Just make them visible when needed. Thank you all so much for helping me getting on the right track. And thx Rolig, Innula and Love for the llgetAgentList tip! I'll keep you guys posted when I got it all working ..

Edited by Marioni Unplugged
Link to comment
Share on other sites

The one idea I had that was worth a dern was already suggested (keeping the ball rezzed while the avater was within range), but I agree that toggling linked prims on or off is probably the best bet. Unless it's absolutely necessary to do something complex for the sake of the visual effects desired, it's always best to keep it as simple as possible.

Link to comment
Share on other sites

EDIT* Changed the prim to a non-pathcut cube, and adjusted the position with Arton's suggestion. Also added in a the http bit to get the sim map texture

I made this script and dropped it into a cube prim that's been flattened and 100(regent limit, can do 20 for a homestead sim) cylinder prims linked to it. I am cutting the path of the prim to 0.375 begin and 0.625 end because it's too early for me to figure out the math to offset the values to allow for a negative local position. any ideas? 

vector oldscale;
float factor;
float factorz;
string URL = "http://www.subnova.com/secondlife/api/map.php?sim=";
key httpRequestId;
setpos()
{
    list agents = llGetAgentList(AGENT_LIST_REGION,[]);
    list params = [PRIM_LINK_TARGET,LINK_ALL_CHILDREN,
    PRIM_POS_LOCAL,<0.0,0.0,0.0>,
    PRIM_COLOR,ALL_SIDES,<0.5,0.0,0.0>,0.0,
    PRIM_TEXT,"",<0.0,0.0,0.0>,0.0];
    integer i;
    integer len = llGetListLength(agents);
    for(i = 0; i < len; i++)
    {
        list details = llGetObjectDetails(llList2Key(agents,i),[OBJECT_POS,OBJECT_NAME]);
        vector pos = llList2Vector(details,0);
        string name = llList2String(details,1);
        vector size = llGetAgentSize(llList2Key(agents,i))/100;
        params += [PRIM_LINK_TARGET,i+2,
                    PRIM_POS_LOCAL,<(pos.x-128)*factor,(pos.y-128)*factor,pos.z*factorz>,
                    PRIM_COLOR,ALL_SIDES,<0.5,0.0,0.0>,1.0,
                    PRIM_SIZE,size,
                    PRIM_TEXT,name+"\n"+(string)pos,<0.0,1.0,0.0>,1.0];
    }
    llSetLinkPrimitiveParamsFast(LINK_SET,params);
}
default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN,
                                    [PRIM_PHYSICS_SHAPE_TYPE,
                                    PRIM_PHYSICS_SHAPE_NONE,
                                    PRIM_POS_LOCAL,<0.0,0.0,0.0>,
                                    PRIM_COLOR,ALL_SIDES,<0.0,0.0,0.0>, 0.0,
                                    PRIM_TEXT,"",<0.0,0.0,0.0>,0.0,
                                    PRIM_SIZE,<0.01,0.01,0.01>]);
        vector oldscale = llGetScale();
        if(oldscale.x > oldscale.y){oldscale.y = oldscale.x;}
        else{oldscale.x = oldscale.y;}
        llSetScale(oldscale);
        factor = oldscale.y/256;
        factorz = oldscale.y/4000/2;
        setpos();
        llSetTimerEvent(5);
        httpRequestId = llHTTPRequest(URL + llEscapeURL(llGetRegionName()), [], "");
    }
    http_response(key request_id, integer status, list metadata, string body)
    {
        if((request_id == httpRequestId) && (status == 200))
            llSetTexture(body,0);
    }
    touch_start(integer n)
    {
        if(llDetectedKey(0) == llGetOwner())
        {
            llResetScript();
        }
    }

    timer()
    {
        setpos();
    }
}

 

Edited by Ruthven Willenov
Link to comment
Share on other sites

20 minutes ago, Ruthven Willenov said:

it's too early for me to figure out the math to offset the values to allow for a negative local position. any ideas?

 vector vPos = llList2Vector(llGetObjectDetails(kAgent, [OBJECT_POS]),0);
 vPos = (<vPos.x - 128.0, vPos.y - 128.0, 0.0> / 256) * gvScale.x;
 vector vScaledPos = <vPos.x, vPos.y, 0.10>;

Where gvScale.x is the lenght of the prim.

Link to comment
Share on other sites

UPDATE: I have solved it according to Love's first reply, which is IMO the most elegant solution: Send names to the balls after rezzing it. No fuz, no lists to be processed. Each rezzed ball does a llListenremove() after receiving the name and then displays the name with llSetText before dying. As my parcel never gets more than say, 5 visitors simultaneously, this works perfect! Next step: get the data from av's up to Z height being 600 mtr! (the 3D Map is after all eh... 3D ;)

  • Like 1
Link to comment
Share on other sites

45 minutes ago, Marioni Unplugged said:

UPDATE: I have solved it according to Love's first reply, which is IMO the most elegant solution: Send names to the balls after rezzing it. No fuz, no lists to be processed. Each rezzed ball does a llListenremove() after receiving the name and then displays the name with llSetText before dying. As my parcel never gets more than say, 5 visitors simultaneously, this works perfect! Next step: get the data from av's up to Z height being 600 mtr! (the 3D Map is after all eh... 3D ;)

Congratulations!

Link to comment
Share on other sites

7 hours ago, Marioni Unplugged said:

UPDATE: I have solved it according to Love's first reply, which is IMO the most elegant solution: Send names to the balls after rezzing it. No fuz, no lists to be processed. Each rezzed ball does a llListenremove() after receiving the name and then displays the name with llSetText before dying. As my parcel never gets more than say, 5 visitors simultaneously, this works perfect! Next step: get the data from av's up to Z height being 600 mtr! (the 3D Map is after all eh... 3D ;)

Why not using llGetAgentList( AGENT_LIST_PARCEL, []) ? If you hardly get more than 5 avatars the list processing will be pretty small. You could also skip distance checks, because the function will return only avatars on your parcel anyway. Up to any height as well. I really don't see what would be more elegant with rezzing/deleting, chat & listeners, instead of doing it with linked prims. 

The script Ruthven posted does even take the Z dimension into account as well.

  • Like 4
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2556 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...