Need help with script.

[THEEVILSQUIRREL Chronowire]

Hello,

I am trying to make a one time use texture applier script which will delete after it changes the texture to a set linked prim of a seperate object.The object which is applying the texture must be trans so it can be given away by people, until it is used. Once used I need it to delete from that person's inventory, so it can't be passed around after use. 

I have tried using a count from 5 to 1 script modded to 1 instead of 5, combined with a texture applier. which only changed the face to the applier. Also when trying to make it one script I kept getting a syntax error.

I am new to scripting as building my own scripts but have some knowledge modding ones already written. Can anyone help me figure out what scripts I need to make this happen, or show me how to write the script myself.

Thanks in advance.

 

Miz

[Rolig Loon]

I'm not sure what you mean by a "5 to 1" script, but all you really need is a touch_start event with two lines in it.  One would use llSetTexture to apply a texture to a specific face (or the entire object) and the other kills the script with llRemoveInventory(llGetScriptName()).  You can make it fancier -- and you'd have to, if the object to be textured has several prims or if you need to texture several faces or apply offsets and scale factors.  Still, the basic script is no more than a few lines.  Put the texture's UUID in the script so you don't need to pass the actual texture in the object's inventory, and be sure to make the script No Mod.

[THEEVILSQUIRREL Chronowire]

 Thank you for your responce. I did try the two scripts but am having trouble combining them.

I ran into a bit of a problem, may be a noobish one, but when saving i get syntax error after

if

llRemoveInventory(llGetScriptName()) <------ in the script below. of course the <------- is not in the script in SL, just to show where the error occurs.

Maybe not an if event, not sure, but I haven't had success saving the script. I also looked over other scripts I have in my inventory that have if in the script and tried a few of those keys to get it to save, but no luck.

(Also how would I set it to change a target prim by name. I forgot that was a neccesary part of the script earlier. The applier will be seperate from the linked object that needs the texture changed.)

Script:

integer face0 = 0; //Change this to the primary face number.
integer face1 = 1; //Change this to the secondary face number.
default
{
state_entry()
{
llSay(0, "Click this object to apply textures and and this script from it when you are done.");
}

touch_start(integer total_number)
{
//Change Paste your UIIDs in between the "" symbols. Hint: you can set different textures to different faces.
llSetTexture("UIID goes here",face0);
llSetTexture("UIID goes here",face1);

}
}

if

llRemoveInventory(llGetScriptName());
}
}

[Rolig Loon]

You left a few spurious lines in your script when you were editing. That's all. They would have been more obvious if you had been indenting each scope carefully.  Without them, your script works fine:

integer face0 = 0; //Change this to the primary face number.integer face1 = 1; //Change this to the secondary face number.default{	state_entry()	{		llSay(0, "Click this object to apply textures and and this script from it when you are done.");	}	touch_start(integer total_number)	{		//Change Paste your UIIDs in between the "" symbols. Hint: you can set different textures to different faces.		llSetTexture("UIID goes here",face0);		llSetTexture("UIID goes here",face1);		llRemoveInventory(llGetScriptName());	}}

 Now, from the description you gave at first, I thought that you were going to be packaging the script along with the texture UUIDs.  The comments you put in the script suggest that you want the user to insert the proper UUIDs and face numbers into the script instead.  I can predict that you will get a lot of trouble calls.

My guess is that the average user will make some sort of mistake (wrong UUID, wrong face numbers, typos, ....) and then of course the script will delete itself so the poor user won't get a second chance.  You're going to have to make the script foolproof, which means not letting the user get anywhere near it.  You'll need to provide a way for the user to drop a texture in, or select textures from a menu, and then do as many trial runs as she wants before clicking a "ALL DONE" button to delete the script.  Your simple script needs to be more complicated than you suggested at first.

Try reading up on how to construct a dialog menu and see if it suggests things you can do next.

[THEEVILSQUIRREL Chronowire]

Oh I just pasted the text without the uuid for my set, am making a hard copy because there is going to be well over 50 textures for the item, each applier will only have one uuid in the script., I will change that to the uuid before making the script for the prim. The prim will be on a seperate linked object. I just need the applier to delete after the person uses it, so it can't be passed around, since the main fun in the project is collecting the appliers in different locations in SL. I can' really go into a lot of detail for it. But the applier will customize a certain prim on a linked prim object.

Sorry if I misrepresented from what I was saying but am new to building my own scripts, I usually do well modding them, but writting one from scratch I am not well versed in. I did look at the dialog link, but from another post you commented in from a google search, I am trying to stay away from menu driven opperations. 

My goal is for the user to rez the applier with the object not linked to the object, then touch applier and it sets the texture to the prim it is set for. 

Would I have to set a target somehow? 

 

Again thank you for your help. I thought the seperate part would have been linked by an event like if. This also might help out a scrapped script I was working on as well. So I thank you for the knowledge, and your time.

Miz

[THEEVILSQUIRREL Chronowire]

Ok I found out I didn't need a bunch of the script text I had based my initial script on. 

 

So I simplified it basically set texture with uuid, and the delete after use script part that you mentioned in the script.

It works fine.

After playing with it to see if it worked, I placed a saved copy of the script in a folder then dragged it to a box to store and act as if the box that sells the contents. Sent that and the object which the script is applied for to an alt for testing without owners rights. 

I placed the script after opening it from the box from my inventory which it textured the root prim. I used the second copy in edit mode to texture the correct prim. With a little tweaking the script works fine, to what it is I am looking for it to do. 

My question is: Is there a way that I could target a certain linked prim in a linked object so that it textures that prim instead of the root prim?

[Estelle Pienaar]

It is a bit more complicated

First of all the child prim that you want to alter with your script should have a unique name in the linkset. Then you script a loop in the default event that checks all chid prims if they have this name. When the name is found, the link number of the child prim gets saved in a global variable. Let's say that you call the child prim "thisPRIM" and the global variable for the link number "linkNumberThisPRIM":

 

integer linkNumberThisPRIM;default{   state_entry()   {   integer p;   for (p=1;p<=llGetNumberOfPrims();p++)     {     if (llGetLinkName(p) == "thisPRIM")     linkNumberThisPRIM = p;     }   }}

 

Then you exchange the llSetTexture function in the touch_start event with llSetLinkPrimitiveParamsFast( integer link, list rules );

The following parameters need to be in the list: [ PRIM_TEXTURE, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians ] 

 

touch_start(integer total_number)    {	//Change Paste your UIIDs in between the "" symbols.         list setTexture = [ PRIM_TEXTURE, ALL_SIDES, "UIID goes here", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ];        llSetLinkPrimitiveParamsFast(linkNumberThisPRIM, setTexture);        llRemoveInventory(llGetScriptName());    }

 

 

[THEEVILSQUIRREL Chronowire]

@ Estelle,

Thanks for the reply.

I managed to save the first script modded to fit terms in my prim, ie: name uuid ect. Saved fine.

But the second script I am getting syntax errors here after I change the name to what I named the prim. I did try to add other characters like ) : but still the errors. Was this part of the script meant to occompany the first script or was this to be placed in the applier? What I did was set the first script in the prim that was linked to other prims, and set the second script into the applier to set the texture to selected prim. :

 

llSetLinkPrimitiveParamsFast(linkNumberThisPRIM<-----

[Rolig Loon]

Look carefully and think about what the script is meant to do.  Estelle broke the job down into two parts.  The first part identifies which prim in the linkset is meant to be changed.  It's in the state_entry event because you want it to run one time, when the script starts or resets.  The second part changes the texture.  That's why it is in the touch_start event, where you want to activate it by clicking on the object.  The two tasks are obviously related.  You can't do one without the other, so then belong in the same script.  That variable "linkNumberThisPRIM" was made global so that its value could be read in both events. Read about global variables. 

[THEEVILSQUIRREL Chronowire]

ok so it is one script and not two then. to be placed in seperate things. I think that might have confused me.

[THEEVILSQUIRREL Chronowire]

Ok so more than likely that was the problem is I seperated the scripts. Sorry bout that, I thought they were seperate ones.

[Rolig Loon]

NP.  You are beginning to see why most scripters don't really like working on other people's scripts. 

When you are just learning, you will tend to focus on the mechanics -- which functions to use, what syntax they require, what the limits are.  Those are important things, but they are not the challenging part or the fun part of scripting.  Scripting is about logic.  It's about breaking down a puzzle into its most basic parts and describing it unambiguously so that a dumb machine can understand it.  The really fun part is that you end up understanding it better too.  When you work on someone else's script, they've already done the basic logic, so all you're left with is the mechanics and cleaning up their mistakes.  It's not as satisfying and it can be confusing if your logic doesn't match theirs.

We occasionally have debates among ourselves in this forum about how to offer help.  Some people like to provide full-blown examples that are working scripts or script chunks.  The rationale is that it gives an OP a starting point that they know will work.  Then they can run with it, customize it.  Other people, like me, prefer to give general directions that will help the OP shape the dimensions of the logic and see what the basic technical parts ought to be. Our rationale is that you will learn more scripting if you participate from the start and have the joy of finding out when your logic and mechanics work the way you intended.  It's not clear which approach is best, so you often get a mix when you ask a question.

 

[THEEVILSQUIRREL Chronowire]

well learning is learning, and there is no direct path to take, over than doing it and see where you end up at.

 

I did manage to compile the script in sl, and it does work, but I think I goofed somewhere. I had the applier rezzed along with the object. I clicked the applier and it set the applier to the texture instead of the intended object's prim. 

Just for keys Linked object will(Root prim) = OBJA, LinkedPrim=PA

Script used:

integer PA;default{   state_entry()   {   integer p;   for (p=1;p<=llGetNumberOfPrims();p++)     {     if (llGetLinkName(p) == "PA")     PA = p;     }   }      touch_start(integer total_number)    {	//Change Paste your UIIDs in between the "" symbols.         list setTexture = [ PRIM_TEXTURE, ALL_SIDES, "Set the UUID here", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ];        llSetLinkPrimitiveParamsFast(PA, setTexture);        llRemoveInventory(llGetScriptName());    }}

 It worked as intended, but not the right prim, instead it textured the applier which is seperate from the object that needs textured. Can you tell me where I went wrong? I had both rezzed, not linked. With this current format of script, will it work for that goal? It has no problem if applied in edit mode, dropping the script in the prim.

[Rolig Loon]

Ah, no.  You can't change the texture on an object unless your texture change script is in that object.  So, you have some design choices to make.  You could use the script as is, but put it in your object instead of putting it in a separate "applier".  That's what I thought you were doing.  Or, you could put the script in your object but rewrite it so that the touch_start event becomes a listen event.  Then write a separate script for your applier.  That script can have a touch_start event that uses llWhisper to send a secret message to the listening script in your object.  That's another perfectly good way to approach the problem, just different.  You just have to decide which is most likely to work flawlessly for your end user. 

ETA:  If you decide on the second option, which is a bit more scripting, your "secret message" could be a delineated list of texture UUIDs (or just a single texture UUID).  That way, you could have a generic texture changer in the object and send it specific texture UUIDs from different appliers.  Just a thought.

[THEEVILSQUIRREL Chronowire]

Ahhhhh ok, that makes sense, in why it applied to itself.  Ok then back to the scripting board to try my hand at a listner script for it so I can weigh the 2 options out first hand. Thank you for clarifying that for me. I wasn't sure if I goofed. It was a Wyle E. Coyote moment for me when I clicked it to set it off. LOL