Jump to content

KT Kingsley

Resident
  • Posts

    1,072
  • Joined

  • Last visited

Posts posted by KT Kingsley

  1. 4 hours ago, Fenix Eldritch said:

    Slight nitpick for an otherwise excellent post, but the wiki page for llListen does say that the id can be either "" or NULL_KEY and it will be treated the same - i.e not used for the filter.

     

    That is kind of what I first thought, but when I gave it a quick blast inworld it didn't work using NULL_KEY, but did using "". Mind you I was in a bit of a rush and I wasn't being systematic, so it could've been almost any of the other tinkering I was doing that caused the failure.

  2. I'd suggest you'll want to start the notecard read in the touch_start event. That way you can drop the notecard into the prim and then click on it to get the process going. Then I'd suggest you use LLRegionSay rather than llRegionSayTo because that way you won't need to identify the receiver by its UUID. And you can put the llRegionSay in the dataserver event where you get the UUID from the notecard. And that llRegionSay can say just the UUID you're using. There's no need to send a message "Change".

    In the receiver script you don't want to listen out for an object that's identified by a NULL_KEY (that won't exist). The way to specify any object key is to use an empty string: "". And also in the receiver script you don't need to be listening for a specific message "Change", but rather for any message. Hopefully the only message it'll ever hear is the UUID of the texture you're using.

    string notecardNameOrKey = "#New Note#";
    key notecardQueryId;
    integer notecardLine;//  first notecard line is 0, so we don't have to set notecardLine = 1 here
     
    default
    {
        touch_start(integer total_num)
        {
            llSay(0, "Reading notecard...");
            notecardQueryId = llGetNotecardLine(notecardNameOrKey, notecardLine);
        } 
        dataserver(key query_id, string data)
        {
            if (query_id == notecardQueryId)
            {
                if (data == EOF)//  we have reached the EOF (end of file)
                {
                    llSay(0, "No more lines in notecard, read " + (string) notecardLine + " lines.");
                    llRemoveInventory(llGetInventoryName(INVENTORY_NOTECARD, 0));
                }
                else
                {
                //  increment line index first, both for line number reporting, and for reading the next line
                    ++notecardLine;
                    llSay(0, "Line " + (string) notecardLine + ": " + data);
                    notecardQueryId = llGetNotecardLine(notecardNameOrKey, notecardLine);
                    llRegionSay (5589, data);
                }
            }
        }
    }
    default
    {
        state_entry()
        {
            llListen (5589, "", "", "");
        }
    
        listen (integer channel, string name, key id, string message)
        {
            llOwnerSay ("Message received: " + message);
            llSetTexture (message, 0); //or change the 0 to whatever face number you're using
        }
    }

    Now, there's plenty of pitfalls to be found here. Perhaps the most likely is that the notecard will have a blank new line after the UUID, and this blank will be said to the receiver which will try and fail to apply it as a texture. So for now, while you're just getting the basics of this working, make sure that the notecard contains just the UUID on the first line, and that there's no blank (or even non-blank) new line after the UUID.

    We can get into ways of catching errors like that later if you need to.

    • Like 2
  3. 7 minutes ago, steph Arnott said:

    Because a notecard reader as decribed would instal the data in a list. '.. that reads a notecard containing a texture uuid which deletes the notecard after reading it ..'

    But the notecard reader as described makes no mention of lists. It describes reading a single texture UUID that needs to be sent to another object. There is no need for a list.

  4. 31 minutes ago, DarkEmperor13 said:

    Ok this is very frustrating. I've looked and looked, but couldn't find anything that helped me. I'm trying to make a Hud that reads a notecard containing a texture uuid

    As you've already figured out, you use llGetNoteCardLine to read from a notecard. The data you get in the dataserver event will be the texture's UUID (at least it will be if the notecard you're reading from has been done properly).

    31 minutes ago, DarkEmperor13 said:

    which deletes the notecard after reading it

    llRemoveInventory.

    31 minutes ago, DarkEmperor13 said:

    and then when you click the button

    The touch_start or touch_end events.

    31 minutes ago, DarkEmperor13 said:

    it changes the texture of an attached object that is separate from it(like clothing for example) into the uuid that the hud got from the notecard.

    To get the UUID to a seperate object you'll probably want to use llRegionSay in the HUD and set up a listener in the target object using llListen so that the message will trigger the listen event, where you can use llSetTexture to apply the texture to the object. (llSetTexture isn't particularly fussy about whether the UUID it's given is a string or a key, and there's no need to get involved with lists for this.)

    Note that you need a script in the target object that knows which channel the HUD will be using to broadcast the texture's UUID.

    • Like 1
  5. The inventory thing is related to the size of the first level of inventory: the folders directly under the inventory folder that you see when you open the inventory floater, and their contents. Sub-folders of those seem to load quietly in the background or when they're opened.

    • Thanks 1
  6. On 4/4/2019 at 1:26 PM, MBeatrix said:

    Region name and approximate time, please? That is valuable info for LL, as they can check the log...

    TP out of Coconut Island to Endless at approx 21:45 PDT Friday 5th May, failed. Relogged to Last Location. Message: Login failed. Agent not in region. Please try again in a minute. (Or words to that effect.). Relog returned to where I'd last logged into after a normal SL exit (which must be a few days ago by now).

    • Thanks 1
  7. As mentioned in other threads, if your TP is failing (for me this usually means that it hasn't happened within about five seconds, and "Requesting teleport..." hasn't appeared in the TP progress bar) click the cancel button and repeat the TP request. This brings up the "Teleports are locked" message, which you can dismiss, and also completes the teleport.

    • Thanks 1
  8. There's also the moving_start and moving_end events, which are triggered in an attachment's scripts when the avatar starts and stops moving, though the type of movement isn't limited to just walking.

    If you want to be walking-specific, you could use Rolig's test for that in the moving_start event and start the rotation when appropriate, and then stop it in the moving_end event.

    • Like 1
  9. The llDetected* functions (as in user = llDetectedKey (0)) don't work in a link_message event, so the user you're targeting is the NULL_KEY.

    Make sure that the script that's sending the link message has the key for the target user in the key parameter of the llMessageLinked function, something like: llMessageLinked (LINK_SET, 0, "texture", llDetectedKey (0)), and then use that parameter in the call to your menu function: menu (target_key, "Select a Texture.", texture_list).

  10. 46 minutes ago, Rider Linden said:

    Does the moon in the region you are testing this in move?  

    If you give me a SLURL to the region I can go take a look.

    Also one way to sanity check what you're seeing would be to also call llGetMoonDirection and llGetRegionMoonDirection and compare the results.

    Yup, the moon is moving just fine in http://maps.secondlife.com/secondlife/Hane/203/125/58.

    And yup, that script in my post is comparing the two. It's an extract from a script I was using to try to get my head around how the various EEP functions work, and it compares both the parcel and region rotations for both the sun and the moon. And it gives the same results both in my home parcel (which has had absolutely no EEP tinkering performed on it: I haven't even downloaded the EEP viewer) and in the adjacent Linden Home public land, and on other LL owned public mainland.

  11. I'm getting an odd result using llGetRegionMoonRotation, in that it's returning a result that when Rot2Eulered and RAD_TO_DEGed has a y component of zero all the time. The equivalent llGetMoonRotation returns a value, similarly treated, whose y component changes over time.

    default
    {
        state_entry ()
        {
            llSetTimerEvent (1.0);
        }
    
        timer ()
        {
            string text = 
                "Moon rotation " + (string) (llRot2Euler (llGetMoonRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionMoonRotation ()) * RAD_TO_DEG) + 
                "\nSun rotation " + (string) (llRot2Euler (llGetSunRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionSunRotation ()) * RAD_TO_DEG)
            ;
            llSetText (text, <1.0, 1.0, 1.0>, 1.0);
    //llOwnerSay (text);
        }
    }

     

  12. The angle brackets around the <n> are wrong. It should be @setcam_unlock=n. In the API documentation, <y/n> means you can use either y or n, but leave out the angle brackets which are there to indicate the beginning and the end of a list of possible options.

    • Haha 1
×
×
  • Create New...