Jump to content

Recommended Posts

I have a system that monitors a sim. It runs 2 lists, one for new the other Here, new is the new people that enter the sim, Here being who is currently at the sim. Thew system compares list, adds, and removes people so there not stacking of HUDs. It all works great until you log into SL in the region, it will not attach the HUD. I did debug, and it is calling out the UID correct. The HUD receives the message. I even change the llDie timer for 10 seconds as it takes a few seconds when your logging in to load everything, and still, it will be given the correct uid but will not attach. I have timers in the HUD giver for sending UID messages, the HUD is getting the message, and still, it will not attach. One person told me it was due to SL security not allowing experiences to accept and attach at log in until you in the asset server. Any advice?

Link to post
Share on other sites

Depending on how active your region is, I can imagine that there might be some delay between the time that llGetAgentList shows that you have arrived and the time when the region servers actually have all of your information.  Building in that delay is a good idea.  It just may not be long enough yet.  I assume that you are rezzing the HUD and then using llSetRegionPos to put it close to the new arrival before you try to attach it.  That shouldn't be necessary, but it can't hurt.  Finally, note that if you are attaching the HUD with a Land Scope Experience, the HUD may detach again if you enter a parcel where the Experience is disallowed.  That might be important to remember if you have a landing point that is not in a parcel where the Experience is allowed.

  • Like 1
Link to post
Share on other sites

the attach is auto, they once the accept the experience it just autos,I keep the server at the way up in the air, it works flawless, the whole region is covered by the experience , what is confusing is the HUD is getting the uid with int he timer event, it event triggers the attach command and yells it out, I have the timer set to 30 seconds, I have a click to auto apply if it fails at landing. its only when they Log into SL in the region, tping into the sim is working 100%, many rent homes in the sim, when they log into SL their standing in their home, the server see them, rez the HUD , it gets the attach command and runs it, it's not a timer thing. the only thing I can think of is having the HUD yell a command after attach that adds them to the InSim list.

 

Link to post
Share on other sites

Very odd indeed.  Any of your tenants should already be in the Experience, so the HUD ought to be able to attach immediately.  The fact that it works properly for people who TP into the region tells me that you have scripted the routines that rez and temp_attach the HUD correctly.  I don't know how your InSim list is loaded, but you may be right in guessing that it doesn't recognize someone who logs in there -- a race condition of some kind.  You should be able to test that by stuffing a few diagnostic llOwnerSay messages into your script to tell you whether the list is being updated correctly.

  • Like 1
Link to post
Share on other sites

If this helps, I use a security orb that kicks out people who aren't in the experience freom my experiece-area, and on TP/login i usually get kicked out myself.

It 'appears' that an avatar's experience status doesn't arrive at the same time as the avatar itself (baaaad)

Link to post
Share on other sites

here my work around

the HUD hits its timer event even set for 60 seconds, so I have now when the timer event hits to yell in a channel "TIMER:UID THAT GOT MISSED" as the HUD is getting the proper UID and it even goes threw ATTACH command with the UID and still  fails, its got to be a asset server thing.,when my server get the failed message it removed the person from the in sim list and places them back into the new list and runs the attach again, works like a charm in testing, i'm going to go live in the sim tonight when we have 30/50 people and see how it works with heavy load

Link to post
Share on other sites
1 hour ago, Profaitchikenz Haiku said:

No surprise there, mesh bodies also seem to take some time to arrive. Perhaps experience and mesh arrive together?

That seem insane, you'd think experience participation would be immediate.

1 hour ago, TheDarkhand said:

here my work around

the HUD hits its timer event even set for 60 seconds, so I have now when the timer event hits to yell in a channel "TIMER:UID THAT GOT MISSED" as the HUD is getting the proper UID and it even goes threw ATTACH command with the UID and still  fails, its got to be a asset server thing.,when my server get the failed message it removed the person from the in sim list and places them back into the new list and runs the attach again, works like a charm in testing, i'm going to go live in the sim tonight when we have 30/50 people and see how it works with heavy load

To be fair, my system is in need of rework, a simplified design with a central, master controller or something.

Link to post
Share on other sites

OK, this one intrigues me, so I tried a totally new approach, laid out in the following two scripts. 

SUMMARY:

The rezzer uses llGetAgentList every ten seconds and then asks every avatar in the region whether s/he already has a HUD.  If so, the HUD will reply, so we can ignore that av from then on.  If not, the rezzer creates a new HUD and keeps track of its UUID and the UUID of the av who needs it.  When the rezzer has finished checking everyone in the region, it then changes to a new state, where it methodically matches each rezzed HUD to a needy avatar, and sends it the avatar's UUID.  The script in the HUD then uses the region's Experience to temp attach the HUD to the right avatar.  I had to do a lot of dancing with the timer event to avoid race conditions, but I think I've succeeded.

I have tested this system by ...

1. teleporting or walking into the region without a HUD

2. detaching a HUD that had already been attached

3. Logging into the region without a HUD.

In all cases, the system correctly identifies me as an avatar without a HUD and then creates and attaches one to me.

These scripts are not as pretty or efficient as I would make them if I were creating them for a client or a MP product, but they work just fine as a proof of concept.  In particular, they solve the problem that the OP posed in this thread.  If I log into the region without a HUD, I get one.  (BTW, note that I make the HUD temp_on_rez so that it vanishes within a minute or so if it's not attached.  That avoids clutter if a target av leaves before getting the HUD or has not accepted the Experience.)

The Rezzer Script:

list lAllAvs;
list lRezzedHUDs;
list lNoHUD;
integer iLen;
integer iCount;
integer iGotIt;
integer iReset;
integer iChan = -2833718;
string strQuery = "Got a HUD?";
string strVerify = "HUD attached";

Reset()     // Get a new list of avatars in the region
{
//    llSay(0,"state default");
    iChan;
    llListen(iChan,"","","");
    iCount = 0;
    lAllAvs = llGetAgentList(AGENT_LIST_REGION,[]);
    iLen = llGetListLength(lAllAvs);
    llRegionSayTo( (key)llList2String(lAllAvs,iCount), iChan, strQuery);    // Ask av #1 if he's wearing a HUD
    iGotIt = 0;
    lRezzedHUDs = [];
    lNoHUD = [];
    iReset = FALSE;
}    

default
{
    state_entry()
    {
        iReset = TRUE;
        llSetTimerEvent(0.1);            
    }
    
    listen(integer channel, string name, key id, string message)
    {
        if (message == strVerify)   //This av has a HUD already
        {
            ++iCount;
            if (iCount < iLen )     // We're working through the list of all avs in the region
            {
                llRegionSayTo( (key)llList2String(lAllAvs,iCount), iChan, strQuery);  //Ask the next av
                iGotIt = 1;
                llSetTimerEvent(0.5);
            }
            else    // Finished with all avs
            {
                if (lRezzedHUDs != [])  // Some avs need a HUD, so there's one waiting to attach
                {
                    llSetTimerEvent(0.0);
                    state Send;
                }
                else    // No avs without HUDS, so refresh the list of all avs
                {
                    iReset = TRUE;
                    llSetTimerEvent(10.0);
                }
            }                
        }
    }
    
    timer()
    {
        if (iReset)     // Ready to refresh the list of avs in the region
        {
            Reset();
        }
        else if (lAllAvs != []) // There ARE avs in the region
        {
            if (iGotIt == 0)    // We've just refreshed the lAllAvs list
            {
                llRegionSayTo( (key)llList2String(lAllAvs,iCount), iChan, strQuery);
                iGotIt = -1;
            }   
            else if (iGotIt == -1)  // This avatar reports not having a HUD, so rez one
            {
                key kAv = (key)llList2String(lAllAvs, iCount);
                lNoHUD += [kAv];    // Keep track of all avs without HUDs
                llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT,0),llGetPos() + <0.0,0.0,0.5>, ZERO_VECTOR,ZERO_ROTATION,iChan); 
                llSetTimerEvent(0.5);           
            }
            else
            {
                ++iCount;
                if (iCount < iLen )     // Keep working thropugh all avs in the region
                {
                    llRegionSayTo( (key)llList2String(lAllAvs,iCount), iChan, strQuery);    // Ask the next av if he has a HUD
                    iGotIt = -1;
                    llSetTimerEvent(0.5);
                }
                else    //Finished looking at all avatars in the region
                {
                    if (lRezzedHUDs != [])  // We have rezzed some new HUDs, so let's attch them now ...
                    {
                        llSetTimerEvent(0.0);
                        state Send;
                    }
                    else    // Everyone has a HUD already, so refresh the list of all avatars and start over
                    {
                        iReset = TRUE;
                        llSetTimerEvent(10.0);
                    }
                }                
            }
        }
        else    // There are no avatars in the region, but keep looking...
        {
            iReset = TRUE;
            llSetTimerEvent(10.0);
        }
    }
    
    object_rez(key id)      // We just rezzed a HUD
    {
        lRezzedHUDs += [id];    // Save its UUID
        ++iCount;
        if (iCount < iLen )
        {
            llRegionSayTo( (key)llList2String(lAllAvs,iCount), iChan, strQuery);    // Ask the next av in the region list if he has a HUD
            iGotIt = -1;
        }
        else    // We've asked everyone ...
        {
            llSetTimerEvent(0.0);
            state Send;
        }
    }
}

state Send      // We wouldn't be here if we didn't have HUDs to attach
{
    state_entry()
    {
        if ( lNoHUD != [])  // Just in case, let's be sure we belong here
        {
            llSetTimerEvent(1.0);
        }
        else    // Nope, no HUDs to attach, so go back to state default
        {
            state default;
        }            
    }
    
    timer() // Work through all the HUDs we have rezzed
    {
        integer j;
        integer len = llGetListLength(lRezzedHUDs);
        while (j < len )
        {
            llRegionSayTo(llList2Key(lRezzedHUDs,j), iChan, llList2String(lNoHUD,j));   // Tell this HUD which avatar to attach to
            ++j;
        }
        state default;  // All done.  Start over
    }
    
    state_exit()    // Cleanup
    {
        lNoHUD = [];
        lRezzedHUDs = [];
        llSetTimerEvent(0.0);
    }
}
        

And the script for a dummy HUD, which does nothing but attach and look nice.  Remember to set it in the Experience:

integer iChan;
string strQuery = "Got a HUD?";
string strVerify = "HUD attached";
key kAv;

default
{
    on_rez(integer startup)
    {
        if (startup)    // Rezzed by the rezzer
        {
            llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEMP_ON_REZ, TRUE]);   // Pre-emptive cleanup
            iChan = startup;
            llListen(iChan,"","","");
        }
    }

    listen(integer channel, string name, key id, string message)
    {
        if (message == strQuery)    // Rezzer has asked if I am attached to this avatar
        {
            llRegionSayTo(id, iChan,strVerify); // Yup, confirm
        }
        else    // I am not attached yet.  Rezzer is telling where to go
        {
            kAv = (key)message;
            llSay(0,message);
            llRequestExperiencePermissions(kAv,""); // Prepare to attach
        }
    }
    
    experience_permissions(key av)
    {
        llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);  // Temp attach
    }
    
    attach(key id)
    {
//        llOwnerSay(" I'm attached!");
    }
}

 

  • Like 1
  • Thanks 1
Link to post
Share on other sites

sorry I had to paint the house, wife won that fight,

it works good for one avatar in testing when I bring in 2 avatars it only applied to 1 of them leaving the other av to not have the HUD.

I keep chipping away at it, thank you so much for the help

Edited by TheDarkhand
  • Like 1
Link to post
Share on other sites

Hmm..  Thanks for the test.  I did say it wasn't as clean and pretty as I would like yet, so my guess is that I left a weak spot in my hurry to post the concept here.  I'll go back and poke at it this weekend.  I think the basic design is the way to go.  Essentially, rez any necessary new HUDs, give the dust time to settle, and then get on with attaching them. I suspect that the servers have their hands full keeping track of an avatar who is just logging in, so they are not ready to pass its UUID to a newly-rezzed HUD right away.  There's a delay imposed by rezzing the HUD and another created by the appearance of the new av.  There may also be delays in registering the new av properly with the list of people who have accepted the Experience. The approach I'm suggesting is to give the servers time to get over those stresses before they attach a HUD.

EDIT:  Oh yes, and a busy region has its own stresses to deal with on top of everything else, as you may be discovering.  ;)  Good luck.

Edited by Rolig Loon
  • Like 1
Link to post
Share on other sites

I'm not sure what the original problem was here, so I'm not sure what we learned. Ordinarily I'd suspect the old race condition between the rezzer's object_rez() event and the rezzed object's on_rez() event, but if all the rezzed objects were getting their target UUIDs and failing to attach, it must be something else.

Thing is, I have an Experience-based thing that scans for new arrivals as in this case but instead of attaching anything it starts a sequence of avatar-specific EEP settings. I've never seen it fail when somebody logs in to the parcel, so... whatever the problem was, maybe it was specific to attaching stuff (not specific to Experiences).

In passing, I have another thing, coincidentally on the same parcel, that does temp-attach something (a swimmer) to new arrivals or anybody else who wades too deeply into the water. Because the object it's temp-attaching, once attached, doesn't need any Experience permissions (just normal permissions granted any attached object), I use a slightly hacked version of open source [AV]prop in the rezzer, and standard-issue [AV]object in the attachment so it can use the AVsitter Experience, hence avoiding asking permission of the many folks who've already accepted AVsitter prop attachments.

Link to post
Share on other sites
11 minutes ago, Qie Niangao said:

Ordinarily I'd suspect the old race condition between the rezzer's object_rez() event and the rezzed object's on_rez() event, but if all the rezzed objects were getting their target UUIDs and failing to attach, it must be something else.

That's my own guess as well, or a version of it.  It is a race condition. As I said in my last note, I think there's just too much going on as a new av is logging in, a HUD is being rezzed, Experience permissions are being verified, the av's UUID is being passed to the new HUD, and it's being attached.  My solution is to delay that last step until the rest catch up.

  • Like 1
Link to post
Share on other sites

Then the first thing I'd try, as a relatively unsophisticated test, is to increase the delay as the timer is set at the start of state Send.  I gave it a second before HUDs start attaching. Try increasing that to see if it helps.  If so, then consider ways to make that delay depend on the number of avs in the region, or something more elegant.

  • Thanks 1
Link to post
Share on other sites

ok will do, it's getting close, atm I got it one out of 2, so we getting there!!

 

very exciting and once again thank you this is a great learning experience, your example answered other question I have wanted to know for a while, your dynamic with your systems teaching people like me better directions to take when developing .

Link to post
Share on other sites

so in the end, this system above is cool , but it keeps rezzing piles of HUDs "waiting" and if they don't apply they just sit there at on e point 30 HUDs and just kept rezzing more, if I add a die timer it cant seem to catch people logging into the sim on log in as there not a HUD waiting. I know this works as there a sim out there doing it, but they will not share how. I thank you all for the help but I think the sim owners will have to hire some one to handle this part as just making 2 list , comparing if some one new and rezing a HUD to attach seems to be a task out of my reach at least on log into SL in the region.

 

 

Edited by TheDarkhand
spelling
Link to post
Share on other sites

Race conditions can be very hard to track down, especially when there are several competing events.  Sometimes it takes more patience than others.  If you have the heart for it, you might try designing a way to make that final response time more flexible so that the system allows more delay time if the region is really busy and relaxes if it's pretty empty.  Or not.  It all depends on how big a deal this is for you.  There's a limit to the value of fiddling, after all.  ;)

  • Like 1
Link to post
Share on other sites

That's a good point.  It is one less bit of information exchange to worry about.  We can't use llGetAttachedList to reveal HUDs in the first place, but once we know that they exist, we can ask whether their UUIDs are still known to the servers later.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...