LepreKhaun

Drake1 Nightfire wrote: Apparently LL deletes them for some reason.. Perhaps then, it was you that should've searched before posting.

Unsure if there's a JIRA on that issue or not but there is definitely a problem with rezzing on a mesh surface and that (misleading) error message comes up. Only solution I could think of is to put a transparent prim floor down or build off of anything that isn't mesh.

Searching for the term "stolen" shows only 7 previous threads in this forum, with the last being made back in February. None of them address the issue of stolen hair creations.

http://wiki.secondlife.com/wiki/LlSetText

I realize that. But when I saw a flaw in the user interface that needed correcting and having contributed little more to this thread than a few (obvious) suggestions and an uncalled for rant, I figured the reader might benefit from seeing how all our efforts would work together. And seeing the OP is now a participant in the Builders Brewery, I had no qualms.

Very well done. Except you have introduced an infinite loop of llDialogs and the OP still has to change just the prims she wishes (the code you had previously given in posting #6). So: [Edited to include the on_rez event, which is necessaary.] [Re-Edited to remove the on_rez event, which I see serves no purpose after all. Linkage can't change in inventory.] integer dialogChan;integer handle;list main_menu = ["grayscale", "reds", "pinks", "violets", "dk_blues", "lt_blues", "yellows", "dk_greens", "lt_greens", "oranges"];list colours =[ "grayscale", "black",<0,0,0>,"white",<1,1,1>,"gray",<0.5,0.5,0.5>,"silver",<0.75,0.75,0.75>,"darkgray",<0.4,0.4,0.4>,"lightgrey",<0.83,0.83,0.83>, "reds", "red",<1,0,0>,"darkred",<0.55,0,0>,"crimson",<0.86,0.08,0.24>,"indianred",<0.8,0.36,0.36>,"orangered",<1,0.27,0>, "pinks", "hotpink",<1,0.41,0.71>,"pink", <1,0.75,0.8>,"lightpink",<1,0.71,0.76>,"deeppink",<1,0.08,0.58>,"fuchsia",<1,0,1>,"orchid",<0.85,0.44,0.84>,"plum",<0.87,0.63,0.87>, "violets", "violet",<0.8,0.51,0.8>,"indigo",<0.29,0,0.51>,"lavender",<0.7,0.7,1>,"magenta",<1,0,1>,"purple",<0.5,0,0.5>,"darkmagenta",<0.55,0,0.55>,"darkviolet",<0.58,0,0.83>,"blueviolet",<0.54,0.17,0.89>, "dk_blues", "darkblue",<0,0,0.55>,"blue",<0,0,1>,"deepskyblue",<0,0.75,1>,"mediumblue",<0,0,0.8>,"midnightblue",<0.1,0.1,0.44>,"royalblue",<0.25,0.41,0.88>,"slateblue",<0.42,0.35,0.8>,"steelblue",<0.27,0.51,0.71>, "lt_blues", "teal",<0,0.5,0.5>,"turquoise",<0.25,0.88,0.82>,"darkcyan",<0,0.55,0.55>, "lightblue", <0.68,0.85,0.9>,"aquamarine",<0.5,1,0.83>,"azure",<0.8,1,1>,"cyan",<0,1,0.9>,"skyblue",<0.53,0.81,0.92>, "yellows", "yellow",<1,1,0>,"gold",<1,0.84,0>,"lightyellow",<1,1,0.88>,"goldenrod",<0.85,0.65,0.13>,"yellowgreen",<0.6,0.8,0.2>, "dk_greens", "darkgreen",<0,0.39,0>,"green",<0,0.5,0>,"forestgreen",<0.13,0.55,0.13>,"lawngreen",<0.49,0.99,0>,"springgreen",<0,1,0.5>, "lt_greens", "lightgreen",<0.56,0.93,0.56>,"chartreuse",<0.5,1,0>,"greenyellow",<0.68,1,0.18>,"honeydew",<0.94,1,0.94>,"limegreen",<0.2,0.8,0.2>,"mintcream",<0.96,1,0.98>,"seagreen",<0.18,0.55,0.34>, "oranges", "orange",<1,0.65,0>,"darkorange",<1,0.55,0>,"coral",<1,0.5,0.31>,"navajowhite",<1,0.87,0.68>,"salmon",<0.98,0.5,0.45>,"seashell",<1,0.96,0.93>,"brown",<.24,.17,.15> ];list sub_menu;list bulbs;list find_prims(string which){ which = llToLower(llStringTrim(which,STRING_TRIM)); list prims; integer max = llGetNumberOfPrims(); integer i; if (max>1){//if it's part of a linkset i=1; } do { if(which ==llToLower(llStringTrim(llGetLinkName(i),STRING_TRIM))){ prims+=[i]; } } while (++i<=max); return prims;}default{ state_entry() { dialogChan = (integer)llFrand(100000.0)+1000;//generate a random channel for the dialogs bulbs = find_prims("bulb"); } changed(integer change) { if(change & CHANGED_LINK){ find_prims("bulb"); } } touch_start(integer total_number) { llListenRemove(handle);//close any open listener key k = llDetectedKey(0);//get uuid of avatar who just touched me handle = llListen(dialogChan,"",k,"");//start listening to messages from that avatar llDialog(k,"Please choose a colour group",main_menu,dialogChan);//present a menu giving the main colour groups llSetTimerEvent(30.0); } listen(integer channel, string name, key id, string message) { integer n = llListFindList(main_menu,[message]); if(~n){ string next = llList2String(main_menu,n+1); //list temp; integer start = llListFindList(colours,[message]); integer finish = llListFindList(colours,[next]); if(~finish){//if the string is not the last colour group (orange, in this case) --finish; } sub_menu = llList2ListStrided(llList2List(colours,++start,finish),0,-1,2); llDialog(id,"Please Choose a colour",sub_menu,dialogChan);//use them to build the sub menu } else if (~llListFindList(sub_menu,[message])){ n = llListFindList(colours,[message]); vector colour = llList2Vector(colours, n+1); //do colour changing stuff here list params; integer max = -llGetListLength(bulbs); do{ params+=[PRIM_LINK_TARGET,llList2Integer(bulbs,max),PRIM_COLOR,ALL_SIDES,colour,1.0]; } while(++max); llSetLinkPrimitiveParamsFast(LINK_SET,params); params=[];// llSetTimerEvent(30.0);// llDialog(id,"Please choose a colour group",main_menu,dialogChan);//present a menu giving the main colour groups } } timer() {//shut down listener if no reply after 30 seconds llListenRemove(handle); llSetTimerEvent(0.0); }}

I apologize for the tone I used. It's alright to admit you need help with a script. I can't draw worth a squat but I still need things textured at times. Just understand, please, that this was really the wrong forum for your request. This one is meant for scripters to discuss their scripts and scripting problems within, nothing more, nothing less. Looking for someone to write or rework a script for you is best done in the Wanted or InWorld Employment forums from now on. OK? With that said, if you truly want to learn scripting, I can recommend both the NCI Scripters and the Builders Brewery groups. Both of them regularly offer beginner through advanced scripting classes. And they both have a good number of individuals willing to help a novice get started. In the meantime, you can simply begin by going to any number of scripting depositories where you can download working scripts and study them to see how they do what they do. Each and everything you come across that you can't figure out, Google it. In other words, if you come across a "llListen" and you have no idea what it's about, put that word into Google and its wiki page will come up, read it and reread it until it makes sense. If a term on that page is unknown to you, it will most likely have a link to an explanation of it. Follow those links, deep as you have to, until it does make sense. Or, let it go for awhile and come back later, after you've learned some more about something else. Sooner or later it'll all come together for you. And maybe it won't. Some of us simply aren't meant to be scripters, their talents lay elsewhere. And LSL is (most definitely!) not the easiest first language to learn programming in. That's fine too. We all can't be great texture artists either. So, you can do as I do, find a good texture artist when I need one and trade what I am capable of offering. And, if you join those two groups I recommended, you'll find plenty of good scripters willing to trade.

AnnieBumbleclaw wrote: I am certain I want to present my chosen colors between 20-50. I do realize it does involve submenus so I did some digging on some scripts and the closest I came to what I want is using the script I will be posting. The only thing is tha if I link all of them, it colors everything when I only want two specified prims colored. Any ideas on how to adjust this script so that it colors only two prims? That code has already been given to you. If you're not taking the time to see what is being offered and study why it works they way it does, you have no interest in writing code of your own. And, frankly, I have no interest in writing it for you.

Keeping in mind that anything over 12 choices is going to have to involve submenus, are you sertain you want to present 20-50 named color choices? Why not have each color channel (red, blue and green) adjustable by (say) 10% up or down on each choice? That would give you nearly 1000 variations using only 6 buttons.

Before your scripts get much larger, it might be pointed out that you would benefit from merging them into one and using llSetLinkPrimitiveParamsFast ( http://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParamsFast ) to set the colors of your light prims. That way, you'd not only avoid having to send messages between scripts, you'd consolidate your lists in one place, making your code much easier to maintain and update. (Edited to add: must learn to type faster. lol)

Better tribbles than shmoos. If shmoos are ever introduced to SL, it would wreck the economy.

A simple design decision addresses all your concerns regarding using llLinkMessage, But first, let me state the main reason one should avoid any of the llSay variants for communication within a single object: Overhead. Each Listen event within all the scripts entail the following actions (excerpted from http://wiki.secondlife.com/wiki/LlListen ) 1. Chat that is said gets added to a history. 2. A script that is running and has a listen event will ask the history for a chat message during its slice of run time. 3. When the script asks the history for a chat message the checks are done in this order: channel self chat (prims can't hear themselves) distance/RegionSay key name message If a message is found then a listen event is added to the event queue. The key/name/message checks only happen at all if those are specified of course. Now, Number 1 happens in due course, all chat is being added to the chat history, regardless. It's only #2 and #3 that gets called into play for open listens. And that overhead happens whether the event is added or not to the script's queue to be processed. So, if one had (say) 10 scripts communicating with listens, that would be a minimum of 10 listen overhead calls, with more in play if a menu dialog is opened or you have a script waiting for the owner to chat a command. But wait! Look at that second check being done in #3- where "prims can't hear themselves", that tells us that if the object consists of only 1 prim, one can't even consider using a variant of llSay, llLinkMessage is the only option possible. So, let's say you do have a task that requires 10 scripts to coordinate/communicate with each other and only one prim for them to work within. The question then becomes how to most efficiently to do this with no chance of error. That's where the design decision comes into it all. It's both simple and scalable; one makes the decision to use the integer num (the second parameter in both the llLinkMessage function (the transmitter) and the link_message event (the receiver)) as a Channel IDentifier. Then it becomes a matter of addressing a specific script by its Channel ID and each link_message event wraps its code within a test to see if it is being addressed or not. However, the test within link_message can't be a simple "if (num == myChannelID)". Though that would work, when a script had to address all the others it would require (in the case of having 10 scripts) nine separate calls to llLinkMessage to broadcast it. No very efficient at all! The solution is to assign the Channel IDs using the Power of Twos (2^0, 2^1, 2^2, ...): One script would use a ChannelID of 1, the next 2, then 4, 8, 16, 32, etc. So, the code each script would have is: // Defined globally as a constantinteger myChannelID = [the script's unique Power of Two integer goes here]; default } link_message( integer sender_num, integer num, string str, key id ) { if (num & myChannelID) { // coding block to process message (which may consist of both str and id!) } } } The "&" is a bit operator- one of the fastest and most efficient in programming ( http://lslwiki.net/lslwiki/wakka.php?wakka=bitwise ). If it fails, everything within the following braces gets skipped and the code immediately "falls through" the event. If it evaluates to TRUE, then (and only then) does it enter the coding block. No chat history comparisons with layered masking comes into play. So, all that remains to be done is to implement the transmitting of messages. To send a message to a specific script is trivial, one just uses "llMessageLinked( link, specificChannelID, str, id );" where specificChannelID is as we've defined it for each script. But, since we've chosen to use Powers of Two for the ChannelIDs, broadcasting to multiple scripts becomes much more powerful than llSay could ever be. Using one prim with ten scripts, you'd have assigned ChannelIDs from 1 (2^0) to 512 (2^9). Right? So, to address them all, you'd broadcast to a ChannelID of 1023 (2^10 - 1 = 0b1111111111). But this would evaluate to TRUE within all your scripts' link_message events, including the sender. So, to avoid that, we'd send to "integer broadcastChannelAllButMe = 1023 - myChannelID;", which is better written as "integer broadcastChannelAllButMe = 1023 ^ myChannelID;", using the XOR bit operator instead of the (much slower) arithmetic operation. But wait there's more! Using this design decision, one can address specific groupings of scripts within that set and no others. Prior to transmission, one just has a line to define the broadcast grouping, such as: "integer groupChannelID = aChannelID | bChannelID | fChannelID | jChannelID;" This statement OR's the ChannelIDs (which are defined earlier as integer constants) of the scripts we wish to address (in this case, scripts a, b, f and j). Using "llMessageLinked( link, groupChannelID, str, id );" , only scripts a, b. f and j will have their code blocks within their link_message events evaluated. Bottom line is, there is no reason to ever feel a variant of llSay is appropriate for communicating within an object. Correct usage of llLinkMessage will win out every time. And, keeping in mind Murphy's Law, one will never have to contend with a channel conflict with another object.

Penny Patton wrote: I'll miss LucasArts, but the LucasArts that made those great games died a long, long time ago. I'm hoping this new situation will let the people who created those games (all long gone from LucasArts) will be able to get their hands on those franchises again. True that, Though the body was finally buried earlier this month, the spirit had left well over a decade ago. Still, as long as LucasArts was still there, one could've hoped for a return of the creative uniqueness that did, for too brief a time, make for some of the most enjoyable entertainment. I still baby an old computer simply because I can run Monkey Island and Full Throttle on it.

... outside of a biker bar? RIP LucasArts, there'll never be better.

Oooohhh- nice one that! ty

Actually, a script sending a link message can hear itself if and only if it addresses the prim it resides in.

ChicByTrinity wrote: How could I achieve that? I have no clue how to write scripts myself. I'm a visual designer and builder, scripts are my weak side. https://marketplace.secondlife.com/p/Renes-Free-Lighting-System/3463246 Works right out of the box, just follow the instructions...

Though the answer is "yes", high poly = high lag, the problem fashion puts on the user experiance goes a lot further than that. I recently rezzed a male hair on the ground to examine. It was made some 5 years ago and consisted of 240-odd sculpties. Only 3 sculpt maps, mind you, but used repeated for each curl and lock. I also examined a female hair made around that time, it had a little over 100 flexie prims (a major source of client side lag). So, yeah, one can rightfully say: for the all those prims we wear, no one seems to much care.

After my posting, I got to thinking- since it was a texture animation problem, what would happen if you turned it off after each opening and closing of the door? This will not only work, but get rid of the first problem you were having with the door going invisible on you at times. Replace all occurances of: llSetTextureAnim( ANIM_ON | SMOOTH, ALL_SIDES, x, y, 0.001, 1.0, speed); //adding this line fixed ... With: llSetTextureAnim( FALSE, ALL_SIDES, 0, 0, 0.0, 0.0, 1.0);

The good news is- I can tell why that is happening. The bad news is- there's no work around apparently. When you do a "Take Copy" or "Save to Inventory", you are doing (equivantly) the same action as a shift-drag copy. A number of prim properties (client-side rotation, particles, hover text, etc) are lost when this happens, one of them being texture animation. Unfortunately, though it has been discussed before, no one has yet come up with a way to detect that since the script is not reset when the copy takes place..

That makes perfect sense to me, thank you!.Now I finally found a use for that pattern I picked up at YadNi's Junkyard so long ago!

Thank you for such an informative posting! I thought all that would've been needed was to carefully crop that screen capture to get this: And then scale it up to 1024x1024 to get the actual texture as it was laid out (though somewhat blurred and noisy). It's always so enlightening to see how professionals do these things!

IIf you're looking for a script, this is the wrong forum. Please use the Wanted forum. If you don't have permission to view/modify the script you have, there is nothing to be done about it, sorry. Perhaps you could find one you could modify in the Wanted forum. If you have a question about a script that you can view/modify, please post the code for it so we son't have to guess what you're asking about.

Alicia Sautereau wrote: You guys didn`t knew about this? :matte-motes-agape: Been using this trick since mesh was implemented to reduce the prim cost Exactly why I made this posting as I did. Most of the information articles for the new mesh accounting is technical and not aimed for a non-builder. I hoped simply to show the average user how they can benefit from it.

Emma Krokus wrote: Where can i get a large enough mesh? :matte-motes-big-grin: There are a number of mesh houses in many sizes and styles on the marketplace which fit the bill perfectly. In fact, housing is the perfect use for this since many players are on a small lot with little more than their house and furnishings. When linking to houses, there are a few considerations to keep in mind though: First of all, you must have Modify permissions for the structure, without that you'll be unable to link into it. Most houses consist of a set of linked objects, especially if they're scripted. In other words, all the doors may be linked together, the windows in a separate link set and the rest of the house (floors, walls and roof) in a third link set. This can be determined in edit mode by clicking around. So, it's the mesh floors, walls and roof that you always want to use as your "prim sponge". Otherwise you might mess up the scripted doors for your house. When linking an object into your "prim sponge", select it first with the Edit menu and examine it using "More info" and pay attention to the Physics cost. Some tortured prims can have extraordinarily high Physics which remains hidden until it falls under the mesh accounting system, best to leave them out! Only when all looks well, right click on your sponge which will select it as well and then Link them together. Reexamine the numbers in "More info" to ensure you're progressing in the right direction. Objects you shouldn't consider putting into your "prim sponge" would be anything scripted or that uses pose balls (clocks, chairs, couches, beds etc). Many of these work only because they are NOT linked to anything else. All is not lost though if you do lose the functions of something as long as it's not No Copy (be very careful if you have an item with No Copy perms!). Simply unlink it, rez another, working copy and leave it out. How to unlink or edit items within your "prim sponge": So you've added the wrong item or you simply decide you want to change out the picture over the fireplace, here are the steps to follow- In your Edit menu, check the "Edit linked" option at the top and left click the item you wish to deal with. Now you can move, recolor or retexture, rotate, etc this one item independently of everything else. And if you click "Unlink" , that item will separate itself from the rest and you'll be left holding just that. At that point, you could delete it or whatever you wish. Oh, and many things you decide to add may, in fact, be composed of more than one prim. When link sets are combined, they melt together into a new set and the definition of each is lost. So to delete (what was) a three prim object from the whole, you'll have to repeat that above step 3 times, one for each prim. OK? Anyway, I hope I didn't get too technical. If something isn't clear enough, feel free to speak up.