Jump to content

llAttachToAvatarTemp: constant causes error


testgenord1
 Share

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

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

Recommended Posts

Hi!
I have a script that causes an object to attach as a HUD:

First the object containing the script is rezzed by a different object through touch_start.
That rezzing object then sends the key of the avatar touching  it over channel -10001 to the rezzed object containing the script.
This now, in turn, on listening, attaches as a HUD to the touching avatar having that key.

When I use the constant ATTACH_HUD_CENTER_1 as the attachment point in the script below, it produces the following error:

Quote

llAttachToAvatarTemp: parameter type mismatch; expecting Int32

When I use the number value (35) instead, the script works.
Do you maybe have an idea why this is the case?
Or is my script faulty?
Thank you very much in advance.
Here is the script:

default
{
    state_entry()
    {
        llListen(-10001,"",NULL_KEY,"");
    }
     listen(integer channel, string name, key id, string message)
    {
        key toucher = (key)message;
        llRequestPermissions(toucher , PERMISSION_ATTACH | PERMISSION_TRIGGER_ANIMATION);
    }
    run_time_permissions( integer vBitPermissions )
    {
        if( vBitPermissions & PERMISSION_ATTACH | PERMISSION_TRIGGER_ANIMATION )
        {
        llAttachToAvatarTemp( 35 );
        llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION,0));
        llSleep(15);
        llDetachFromAvatar( );
        }
        else
        {
            llOwnerSay( "Permission to attach denied" );  
        }
    }
    on_rez(integer rez)
    {
        if(!llGetAttached())
        { //reset the script if it's not attached.
            llResetScript();  
        }
    }
}

 

Link to comment
Share on other sites

Good question.  I tend to type the integer equivalent rather than the constant name, simply because I am lazy, but both should work.  I'm going to guess that you have somehow buried a bogus non-printable code in there somewhere or have typed an upper case I instead of a numeral 1 (I have done both myself).  Try retyping the entire line.  Otherwise, embrace the mystery and go with the integer 35.  It's easier. :)

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1600 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...