Texture Change HUD via Notecard

[DarkEmperor13]

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 which deletes the notecard after reading it and then when you click the button, 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. Basically something similar to how the appliers for mesh bodies work. I tried looking at llGetNoteCardLine from the wiki, but it doesn't tell me how to do textures. The same with a few posts I read dealing with a hud that reads from the notecard. None of them have anything to do with changing textures. Plz help.

 

[steph Arnott]

7 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 which deletes the notecard after reading it and then when you click the button, 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. Basically something similar to how the appliers for mesh bodies work. I tried looking at llGetNoteCardLine from the wiki, but it doesn't tell me how to do textures. The same with a few posts I read dealing with a hud that reads from the notecard. None of them have anything to do with changing textures. Plz help.

 

A UUID in a notecard is a type of string. When reading a notecard it needs to be cast in a list which specifies its data type.

[Fenix Eldritch]

llGetNotecardLine by itself doesn't give you the actual data from the notecard. Instead, it gives you a query id and then queues up a datasrerver event. It is in the dataserver event that you will be given the actual text from whatever notecard/line you specified. You can use the query id to match up any dataserver event to the specific llGetNotecardLine function call. See the wiki page for an example, note how the dataserver event handler shown there has two variables, a key named "query_id" and a string named "data". You would compare the key returned by llGetNotecardLine with the query_id in the dataserver event. If they match, then you know that this specific instance of the dataserver event is answering that specific llGetNotecardLine call.

The data variable would contain the contents of the notecard at that line - whatever it may be. If it's just a uuid for a texture and nothing else, then you can get away with dropping that string straight into a texture function where appropriate. llSetLinkTexture for example, takes a string variable which can be the uuid of the target texture.

Edit: Ah if it's transmitting the uuid from a hud to another object, that's a little different. See KT's post below.

But it would be a good idea to do some error checking before hand, to make sure the value read in matches the expected format of a texture uuid with nothing else on that line.

 

Edited April 11, 2019 by Fenix Eldritch

[KT Kingsley]

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.

Edited April 11, 2019 by KT Kingsley

[steph Arnott]

7 minutes ago, Fenix Eldritch said:

The data variable would contain the contents of the notecard at that line - whatever it may be. If it's just a uuid for a texture and nothing else, then you can get away with dropping that string straight into a texture function where appropriate. llSetLinkTexture for example, takes a string variable which can be the uuid of the target texture.

No. The UUID has to be type cast. Using a list find will ignore it if not cast as a key.

Edited April 11, 2019 by steph Arnott

[Rolig Loon]

Sorry, Steph.,  llSetTexture and llSetLinkTexture both take the texture UUID as a string:

Function: llSetTexture( string texture, integer face ); Function: llSetLinkTexture( integer link, string texture, integer face );

The UUID arrives in the dataserver event as a string, so  all you need to do is drop it directly into one of those two functions.  In fact, even if you did have it as a key variable, those two functions will accept it without explicit typecasting.

[steph Arnott]

1 minute ago, Rolig Loon said:

Sorry, Steph.,  llSetTexture and llSetLinkTexture both take the texture UUID as a string:

Function: llSetTexture( string texture, integer face ); Function: llSetLinkTexture( integer link, string texture, integer face );

The UUID arrives in the dataserver event as a string, so  all you need to do is drop it directly into one of those two functions.  In fact, even if you did have it as a key variable, those two functions will accept it without explicit typecasting.

A notecard reader to a list does not type cast a string to a key. It will just be a baseline string. Using that string as data for a key will return nothing. Notecard read UUID should be cast as (key)"xxxx......................xxxx"

[KT Kingsley]

Maybe there's a confusion between "list" and "listen" happening somewhere here?

[Rolig Loon]

I think we're talking about two different things  When a datasever event opens, it has two parameters:

dataserver( key queryid, string data ) If your script is reading a notecard, the contents of a line are read as the parameter data, which is a string.  You may then apply it directly to any face on any prim.
 

dataserver (integer queryid, string data)
{
    if ( kReadMyCard == queryid )
    {
        if ( data != EOF )
        {
            llSetLinkTexture( link, data, face);
            kReadMyCard = llGetNoteCardLine( my_card, ++line);
        }
    }
}

You might want to read it into a list instead, which I suspect is what you are thinking about:

dataserver (integer queryid, string data) 
{ 
    if ( kReadMyCard == queryid ) 
    { 
        if ( data != EOF ) 
        { 
            lTextureList += [data]; 
            kReadMyCard = llGetNoteCardLine( my_card, ++line); 
        } 
    } 
}

In that case, the UUID will be loaded into the list lTextureList as a string.  Again, no explicit typecasting is necessary, since the llSetLinkTexture function requires a string.  You simply tell it

llSetLinkTexture( link, llList2String( lTextureList, i), face);

where i is the specific list element that you want to use.

[Rolig Loon]

21 minutes ago, steph Arnott said:

A notecard reader to a list does not type cast a string to a key. It will just be a baseline string.

Yes, that is true. 

21 minutes ago, steph Arnott said:

Using that string as data for a key will return nothing. Notecard read UUID should be cast as (key)"xxxx......................xxxx"

That part is not true.  You may always feed the UUID as a string.  No typecasting required.  I have been doing it quite successfully for 12 years.  I'm sure that many (most?) other LSL scripters have. It works like a dream. 

Edit:  In fact, the definition of llSetTexture in the LSL wiki defines that parameter as

• string

texture

–

a texture in the inventory of the prim this script is in or a UUID of a texture

Edited April 11, 2019 by Rolig Loon

[steph Arnott]

1 minute ago, Rolig Loon said:

Yes, that is true. 

That part is not true.  You may always feed the UUID as a string.  No typecasting required.  I have been doing it quite successfully for 12 years.  I'm sure that many (most?) other LSL scripters have. It works like a dream. 

'However there is no implicit conversion with llListFindList. llListFindList requires not only the values to match but also the types.'

[Rolig Loon]

We're not using llListFindList or any other list function.  Simply reading a line off of a notecard.

[KT Kingsley]

Why are we discussing lists here?

[Rolig Loon]

1 minute ago, KT Kingsley said:

Why are we discussing lists here?

I have no idea.

[steph Arnott]

Just now, KT Kingsley said:

Why are we discussing lists here?

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

[Rolig Loon]

1 minute 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 ..'

And in that case, we would be using the second script example that I posted above:

15 minutes ago, Rolig Loon said:

dataserver (integer queryid, string data) 
{ 
    if ( kReadMyCard == queryid ) 
    { 
        if ( data != EOF ) 
        { 
            lTextureList += [data]; 
            kReadMyCard = llGetNoteCardLine( my_card, ++line); 
        } 
    } 
}

In that case, the UUID will be loaded into the list lTextureList as a string.  Again, no explicit typecasting is necessary, since the llSetLinkTexture function requires a string.  You simply tell it

llSetLinkTexture( link, llList2String( lTextureList, i), face);

where i is the specific list element that you want to use.

You still get a string variable, which is what you need for llSetTexture.

[steph Arnott]

1 minute ago, Rolig Loon said:

And in that case, we would be using the second script example that I posted above:

You still get a string variable, which is what you need for llSetTexture.

Okay so you despute list casting types then. Fine, whatever.

[KT Kingsley]

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.

[steph Arnott]

Just now, KT Kingsley said:

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.

It is still data retrival, listed and sent.

[Rolig Loon]

1 minute ago, steph Arnott said:

Okay so you despute list casting types then. Fine, whatever.

Oh, not at all.  It is always very important to know what type of variable was loaded into a list.  If you do not know, then it's important to typecast it explicitly when you read out of the list again.  So, for example, if you do not know for sure that a string contains vectors, you should always read a specific element as

vector ThisVector = (vector) llList2String( lMy_list, i );

instead of reading

vector ThisVector = llList2Vector( lMy_list,i );

You are quite correct in recommending that as standard, safe practice.  In this specific case, however, we know that the information is being read into the list as a string, so we can read it out as a string too.  Plus, of course, in this case we really don't care whether we have a string or a key anyway, because llSetTexture will take either one.

 

[steph Arnott]

1 minute ago, Rolig Loon said:

Oh, not at all.  It is always very important to know what type of variable was loaded into a list.  If you do not know, then it's important to typecast it explicitly when you read out of the list again.  So, for example, if you do not know for sure that a string contains vectors, you should always read a specific element as

vector ThisVector = (vector) llList2String( lMy_list, i );

instead of reading

vector ThisVector = llList2Vector( lMy_list,i );

You are quite correct in recommending that as standard, safe practice.  In this specific case, however, we know that the information is being read into the list as a string, so we can read it out as a string too.  Plus, of course, in this case we really don't care whether we have a string or a key anyway, because llSetTexture will take either one.

 

This is about list data reading. Has nothing to do with whether the llSetTexure gives a 'whatever'.

[Rolig Loon]

1 minute ago, steph Arnott said:

This is about list data reading. Has nothing to do with whether the llSetTexure gives a 'whatever'.

Exactly.  As I said, that's a non-issue.  I agree.

[steph Arnott]

Just now, Rolig Loon said:

Exactly.  As I said, that's a non-issue.  I agree.

It is when you do something else and it will not work because you cludged it in the first place.

[Rolig Loon]

10 minutes ago, steph Arnott said:

It is when you do something else and it will not work because you cludged it in the first place.

That's where I think we are talking past each other. Take a look at my example again, because this is what the OP is asking for. 

47 minutes ago, Rolig Loon said:

dataserver (integer queryid, string data)

{

    if ( kReadMyCard == queryid )

    {

        if ( data != EOF )

        {

            lTextureList += [data];

            kReadMyCard = llGetNoteCardLine( my_card, ++line);

        }

    }

}

The only list is the one called lTextureist, and it is loaded with string variables, each read from the notecard.  Because we created lTexturelist  and loaded it ourselves, we can be 100% sure that the variables in it are all string variables.  We don't need to typecast them again as we read them back out of the list later.

As a more generic observation, regardless of what type of variables a list contains, we can always read them back out as strings.

Edited April 11, 2019 by Rolig Loon

[DarkEmperor13]

um.... can anyonepoint me to a script that does this? cause nothing ya'll said made  any sense to me.