Jump to content

Communicating With Other Scripts in an Object


Gregorian Lytton
 Share

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

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

Recommended Posts

Good morning guys. Over the last few days I've been trying to figure this out as opposed to buying one off Marketplace. I have a "Menu" script that lets you create menu buttons from a dialog box, that will also link to other scripts in the prim or linkset. The issue I am having is getting it linked to the other scripts so they can communicate. For example: I wish to be able to left click the object, get a dialog box with buttons for "Color" and "Texture", and have the scripts communicate between each other to perform those functions.

I've tried altering this snipet from the  main menu script, but to no avail.

 listen(integer channel, string name, key id, string message) 
    {
        if (channel == MENU_CHANNEL)
        {
            if(message == "Textures")               
            {
               llMessageLinked(LINK_THIS, 0, "INVENTORY_TEXTURE", "");

 

Can someone point me in the right direction as to what I'm doing wrong in getting these scripts to communicate with each other. Thanks in advance.

 

 

Link to comment
Share on other sites

An object cannot talk to itself or, if you want to think of it the other way around, cannot listen to itself.  That's a built-in restriction to avoid disastrous feedback loops.  However, scripts in an object can send linked messages to each other.  Open the LSL wiki and look at llMessageLinked.  You can still create accidental infinite loops with linked messages, but they're less likely.

Link to comment
Share on other sites

Check your LINK_FLAG, it is set to LINK_THIS and hence only sends to the prim the script is in.

To send to all linked prims use LINK_ALL_OTHERS, Rolig refers to Wiki, take a look at the flags you have to specify,

 

 

Link to comment
Share on other sites

Can you tell us a bit more about what you want the script to do?

If, for example, you want it to change the texture or colour of the object, or parts of it, in response to the dialog messages, then having the script call llSetLinkPrimitiveParamsFast in response to the dialog message is probably simplest, since that way you have only one script to worry about.

Link to comment
Share on other sites

Thank you all for the replies.

@Innula Zenovka 

What I'm trying to achieve is..... I made and object that I want to be color change on a few faces, and texture change on others. But I want when you click it to have to buttons to choose what you wish to do. Example of the dialog box: https://gyazo.com/c3a9eab8a5e089edae93040eb6b3f88d . But when I click a choice, it doesn't communicate with the texture or color change scripts. I know I can easily buy one from Marketplace for a 1000L or more, but I enjoy learning new things and accomplishing goals lol.

Link to comment
Share on other sites

In that case, you need first to have your script decide, in the listen event, what to do if it receives the message "Color" or "Textures," and then present a second set of menu choices, Colors or Textures, depending on what option is chosen.   Then, after you receive the second message, you can either send an instruction via link messages or (which I think would be much better) simply use llSetLinkPrimitiveParamsFast to change the faces you want to affect.  

But first you need to generate and present the menus for choosing Colors and Textures.   I would use two strided lists, one of colour names and vectors, and one of texture names and uuids, and then use llList2ListStrided to generate a list of buttons on the fly when you need them (there's an example of how to do this in the wiki article).    Then when you receive a message from the second menu you can use llListFindList to decide whether the response is a colour or a texture and also to find the next item on the relevant list, the vector or uuid to which it applies.   

Then simply use llSetLinkPrimitiveParamsFast to apply the choice to the relevant faces.

Link to comment
Share on other sites

@Innula Zenovka

So you wouldn't recommend using an "Inventory_texture" type of script? Because that was a feature I was including in the item I was making, giving the consumer the ability to add their own textures by simply dropping them in the object. O r will it work the same way If I point the script to that script instead of pointing it to  notecard? I will also try what you guys have suggested and see where that leads me.

Edited by Gregorian Lytton
Link to comment
Share on other sites

You can certainly read the texture uuids from inventory textures and build a list based on the name of the texture plus the UUID.   If you're doing it that way, though, you need to be aware of the restriction that, while a script can apply a texture to the prim it's in by using the texture's name, it can read the texture's UUID only if the texture is full perms to the script owner.   That's going to be the case whether you decide to use link messages to communicate the the name of the texture to a child prim or if you use llSetLinkPrimtiveParamsFast.

But in general it would be easy enough to have one list of hard-coded textures and uuids and then to build and concatenate another list from a notecard or from the prim's contents.

I'm not completely clear about whether your item comprises a single prim/mesh or one make up out of several linked prims.    It would help to know that.

Link to comment
Share on other sites

@Innula Zenovka Sorry for the delayed response. Its actually 2 prims. The textures and faces that I'm wanting to be change-able are on the main mesh prim. While the second prim serves as the main prims base shadow. Since the main object has a taller profile height, it would be the pnm that is most likely clicked to access the features. In lieu of keeping my idea... my idea.... If you want to PM me so we can discuss it further, I can show you a few photos of what I'm working on. :-) .

Insert other media

Link to comment
Share on other sites

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...