Texture Change HUD via Notecard

[KT Kingsley]

Sorry, I can't point you at a script.

But don't feel too bad about stuff not making sense to you. A lot of it doesn't make any sense to most of the rest of us either.

[Rolig Loon]

No, but you can write your own script quite easily if you take the advice you have been given.  Specifically, you were pointed to examples in the LSL wiki that show how to use llGetNotecardLine to read text (including texture UUIDs) off of a notecard.  I have posted an example in this thread (several times) to show how to add that information to a global list.  All you need for completing the job is learning how to use llDialog to create a menu-driven system for reading information from your list and using it to apply a texture.  You can even shortcut that process by looking for examples of dialog menu scripts in the LSL Library , like this one:

 

[DarkEmperor13]

ya I can script, but this is a little too advanced for me. If anyone is willing to help me in-world, I think would make it a lot easier. I made these tattoo Layers for Belleza Freya with my own UV maps and not taken from the devkit that I have because I honestly dont know how ppl are able to make textures that wrap around the legs and arms perfectly. I really want to make a hud that ppl can easily put in a note card with texture uuid without needing to go into the script especially for those who have no scripting knowledge.

[Rolig Loon]

It sounds like you probably need to hire a scripter to write a custom system for you.  I suggest writing out a good description of what you want your system to do  Then, post a note in the InWorld Employment forum to attract a scripter.  When someone responds, send a copy of your notecard and start negotiating a price and delivery terms.

[DarkEmperor13]

ya that seems like the only thing I can do at this point. Wait, is there a way I can use llGetTexture to get a texture in the prim and send it to the receiver without a notecard?

 

[Rolig Loon]

llGetTexture will grab the UUID of the texture on the face that you have identified ( that is, you ask for kUUID = llGetTexture(face); )  There are two important limitations, however:

• If face indicates a face that does not exist the return is NULL_KEY
• NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.

It's that second one that is most likely to be important.  Whoever owns the scripted object must have full perms for the object, and the texture has to be in the object's inventory.

[DarkEmperor13]

OK so I have this:

Sender

string notecardNameOrKey = "#New Note#";
key notecardQueryId;
integer notecardLine;//  first notecard line is 0, so we don't have to set notecardLine = 1 here
 
default
{
    state_entry()
    {
        llSay(0, "Reading notecard...");
        notecardQueryId = llGetNotecardLine(notecardNameOrKey, notecardLine);
    }
    touch_start(integer total_num)
    {
        llRegionSayTo(llDetectedKey(0), 5589, "Change");
    } 
    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);
                
            }
        }
    }
}

Receiver

default
{
    state_entry()
    {
        llListen(5589, "", NULL_KEY, "Change");
    }

    listen(integer channel, string name, key id, string message)
    {
    }
}

How exactly do I get the UUID from the dataserver?

[Fenix Eldritch]

The "data" variable is local to the dataserver event, and can only be accessed from inside that event. In addition, it will be overwritten with each successive call. In order to preserve it, you must save the string to a global variable. Then you can do other things to it after the dataserver event passes. Alternatively, you could instead opt to initiate the llRegionSayTo relay right then and there once you have confirmed the data string isn't an EOF. You could move your llRegionSayTo command out of the touch_start event and instead into the else clause of the dataserver event (where your llSay is outputting the notecard line and text to local chat).

Note that you need to update your llRegionSayTo command to actually contain the data string you intend to transmit. Something as basic as this could work - assuming you have formatted the notecard line to only have a single uuid and nothing else. Otherwise you'll need to do some parsing either before or after the string is transmitted.

llRegionSayTo(llDetectedKey(0), 5589, data);	//transmit the contents of the data variable to llDetectedKey(0) over channel 5589

Then, in your listen event, you would find the transmitted text inside the "message" variable.

It should be noted that your script as currently written will immediately start reading the notecard lines once the script is compiled or reset. And it will read the entire notecard automatically and then delete it. This may cause you some trouble if you run the script before the notecard is ready. I would advise you move your initial llGetNotecardLine call out of the state_entry event and instead into the touch_start event. That way, you can control when it starts reading, and it will give you time to actually place the notecard inside the object.

[KT Kingsley]

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.

Edited April 12, 2019 by KT Kingsley

[Fenix Eldritch]

20 minutes ago, KT Kingsley said:

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).

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.

Quote

If msg, name or id are blank (i.e. "") they are not used to filter incoming messages. If id is an invalid key or assigned the value NULL_KEY, it is considered blank as well.

 

Edited April 12, 2019 by Fenix Eldritch

[steph Arnott]

 

18 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.

 

" " is a filter. The space would make it one. And a NULL_KEY has a value of "00000000-0000-0000-0000-000000000000" which is also a filter. The wiki page you quoted is no longer valid information for MONO.

Edited April 13, 2019 by steph Arnott

[KT Kingsley]

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.