Wulfie Reanimator

What you should do, is list them under that suggested category I guess. Or you might be able to appeal the decision with a support ticket. What kind of skin mods though? Are they head-only or something that adds to a skin (like materials, or tattoo-like add-on layers)? Or were they full-body, standalone skins? (The kind that are just a complete skin and nothing else.) The person reviewing your product can make mistakes, so making your product name/images/description as clear as possible is very important.

"I'm not usually into furries, but..."

Arguably, too much supply will have a negative impact on demand. Decision fatigue as well. The primary intention of BOM is efficiency. Reduction on texture usage and "onion bodies." Being able to wear 15 year old system layers and fixing alpha-sorting issues are a side-effect.

Sorry, I'm making too many assumptions. The bit of code I showed only fills that list, you can put it anywhere you want, where you need that list to be created. At the beginning of on_rez like you showed is fine. "++" means "increment," it can only be used with integer variables and it increases the value by one. It has some small technical details involved but that's not very important here. You should rewrite the loop in a way you understand. Lastly, you should not put llGiveInventoryList into the loop, otherwise you're sending a folder with one item, then a folder with two items, then a folder with three items... Put it outside of the loop, after it has finished, so that you only send one folder with all of the items found.

If you read the wiki page, it's really as simple as: list inventory; integer i; while(i < llGetInventoryNumber(INVENTORY_ALL)) { inventory += llGetInventoryName(INVENTORY_ALL, i); ++i; } Of course, if you (probably) don't want to send the unpacker script as well, you need to check if GetInventoryName matches GetScriptName. Then, if you think someone might put no-transfer or no-copy items into the contents, you can check for that with GetInventoryPermMask.

All you need is to loop through the object's inventory and store all the names into a list, then send them with llGiveInventoryList. I guess the confusing part was you trying to use the function to send one item at a time.

Oh, I guess not. Very good to know. Doesn't Firestorm also prevent you from dragging items into the contents of attached objects? I recall something like that being a constant problem.. specifically I remember trying to put "auto alpha" scripts by someone else into a (modifiable) body.

Since when? I script almost exclusively by making prims, adding a script, and then attaching it to myself for editing. I've never encountered this unless it's a new change within 2 days or so.

* Only if the avatar that stood up was the last person to sit down.

Failure to deliver - at least on MP - means that the item just.. never arrives. No notification or anything. The difference here is that if you get far enough to get the "X has sent you an object called blahblah, accept?" prompt, you already have it. I will go ahead and do some crash tests th-- Prokofy. When I say this, I say this with utmost respect. Of course there isn't anything to paste if you shut down the viewer. The SL viewer (official and others) have their own "clipboard" that it keeps in memory while the viewer is on. Closing the viewer clears whatever you've cut or copied, but all it is, is a reference to the original. Not the original. Your test object isn't gone. It's still in its original place where you had it when you cut it. If this was a rare gatcha, it would be perfectly fine in your inventory.

"Attacking a business" is not even close to the same thing as attacking a person. And I haven't attacked your business, I only said you should follow the rules like everybody else, as it appeared you weren't doing that, based on what information you shared. Then, after the issue literally disappeared, I gave you genuine advice -- turning up your graphic settings for one minute to take a nicer looking screenshot, which would've also avoided this whole thing -- and left it at that. You on the other hand have acted pretty arrogantly in response, and now you're dismissing concerns and advice by literally attacking the personal lives of those people. I think you as a person need to learn to detach yourself from the you as a business. The reputation of your business suffers if you act rude towards others while presenting yourself as a business.

Me and my empty life are very offended that a landlord like you would make such personal attacks. Do you do this to difficult tenants as well? P.S. I wasn't going to post anything when I saw your first post.

Of course, because I didn't have any sounds to test with, I didn't make it play sound. The script is practically complete though, so there's an absolute minimum amount of changes you'd have to make to make it play sound. You can use llListen multiple times, and the script will then listen to multiple channels. You'll just have to make sure you're only listening for what the owner is typing, because otherwise your text-to-voice will be repeating what anyone (including objects) are saying on all of those channels... I understand how that feels, but the wiki's style of very specific documentation is absolutely necessary. The wiki has pages dedicated for tutorials as well, but there's no tutorial that's going to show you how to make a script that plays chat as audio. This is where the "memorizing the functions" through long-term experience and googling comes in. You need to break down what your script has to do in steps -- listen, clean up, parse, search, play. How do I listen? Google "lsl listen chat," find llListen, read the wiki on how to use it. Why do I clean up? How do I clean up? What do I need to clean up? If I say a word, it works, but if I say a word and put a question mark after it, no sound plays.. How do I remove or ignore the question mark? How can I read the words separately? How can I find the sounds I have? How should I store them for my script? How do I play a sound? etc.

It would. But that is a very important detail to know, depending on what your script does on _start or _end. If your elevator immediately reacts to either of those events, it'll likely break, depending on what it's doing and how.

Your first method is right on track, it'll take a tiny bit of math because there is no (well, maybe one) way to detect which face was collided with. The second method would also work fine for one person. What if someone is already in the elevator and another walks in with them? It's not impossible to work around, just something to keep track of. The one possible way for face detection I mentioned is with llCastRay. Essentially, you instantly draw a line from A to B and see what the line collided with. You can find out which way the prim's face is... facing... but you'd still need to do the same "directional math" as with an avatar collision. I don't recommend doing this as a practical solution.

You need to request editing rights via support ticket.

A "cut" doesn't delete the file until after you have pasted it. Make a couple blank prims and try this out: Cut one box, don't paste, and cut another box instead. The first box is unaffected. Now, while you've cut the second box, relog. The second box is unaffected. There's no possible glitch that could happen here because of how cut/paste works. This is entirely valid. Personally, my mouse sometimes releases a mouse click because there is dust in the mouse and/or I don't apply enough pressure while moving the mouse. This is a matter of preference (annoying), habit (confusing), and lastly doubtful. I'd like to see the risk of content loss demonstrated (not a story of what happened), because even if an unpacker sends you a folder and automatically detaches itself, you can still accept the folder and "receive" it. Fun fact: When someone/thing gives you ANYTHING, it is automatically put into your inventory before you even accept the prompt. Accepting or refusing it just tells your viewer what to do. On accept, the viewer will probably just bring up your inventory with the item selected (or whatever it's set to do), on refuse the viewer will move it to trash. DOING NOTHING (eg. crash) will leave the item in a default system folder, or main inventory if it was a folder.

You can't make a script open stuff onto your screen, besides a map. If you've seen textures and those "play animation" windows pop up, you had your viewer set to do that.

Replying to myself for the first(?) time, interesting.. Here's what I was talking about: list words = ["you", "are", "awesome"]; list sounds = ["uuid1", "uuid2", "uuid3"]; default { state_entry() { llListen(0, "", llGetOwner(), ""); } listen(integer c, string n, key k, string message) { // Convert to lowercase, because case doesn't matter. // Then parse the message and remove spaces and punctutation. message = llToLower(message); list heard = llParseString2List(message, [" ", ",", ".", "!", "?", "-"], []); // Just for debugging, show the list as Comma Separated Values llOwnerSay( llList2CSV(heard) ); // THE LOOP: Go through the "heard message" list until we reach the last word. // (Note: The last index in a list is "the length, minus one.") integer iteration; // Default value is 0 while(iteration < llGetListLength(heard)) { // First you get the next word you're going to check from the known words. // (Note: ListFindList will return -1 if it does not exist.) string check = llList2String(heard, iteration); integer known_index = llListFindList(words, (list)check); // Again, just for debugging, shows the word we are checking and where it was found. llOwnerSay( llList2CSV([check, known_index]) ); if(known_index != -1) { // The word exists, and we have the index it was found in. // (Note: We only know the correct index because "words" and "sounds" are equally long lists with the correct words/sounds in the correct order.) key sound = llList2Key(sounds, known_index); llOwnerSay(sound); //llPlaySound(sound, 1); } // We must also remember to increase the "iteration counter" by one. // Otherwise the loop will never move to the next word and will repeat forever. // (Note: "++" is a special operator for integer only.) ++iteration; } } } Which outputs.. Learning a "programming language" is very much the same as learning a real language. "Real languages" and programming languages both require a vocabulary, structure, arrangement, and punctuation, but the difference is that if you make a small spelling mistake while programming, the computer has absolutely no idea what you were even trying to say. Most importantly, you must learn the punctuation, then structure/arrangement, and then you can start to finally and safely memorizing the vocabulary by using the language. It is difficult to solve a problem logically when you don't know all of the tools you have available. Would you know how to cut down a tree if nobody showed you how to do it and you'd never seen a saw or an axe?

I wrote almost the exact same thing word for word, but then I figured there'd be no way to differentiate from plurals and words with a natural S at the end, unless you cut every possible word sharply at the end so that an S was more "modular." (Attach smoother to the end of the previous sound, for words that would have it anyway.)

For a thousand items, probably not noticeable, at least from a single function like ListFindList. If you were writing a loop to manually go through the entire list of "known words," probably noticeable delay. I'm unsure what the answer would be for thousands. Also, you could make duplicate list pairs by having "do not" and "don't" use the same sound. You don't have to do punctuation either, my advice was about removing punctuation from the messages. I can write a simple draft once I get home.

To expand on what Xiija probably means, is that you can check for multiple conditions with the && (AND) and || (OR) operators. What I would also point out is that you can use the < and > (less/greater than) operators. E.g. "if this is greater than A AND less than B, OR this is greater than C AND less than D..." E.g. if( (this > a && this < b) || (this > c && this < d) ) It's still going to be either long lines or lots of short lines. LSL doesn't have an explicit function for a range of numbers, unless you write one.

As a professional inventory organizer, I say DOWN WITH BOXES AND UNPACKERS! We, the good working people have had enough of this oppression of clutter! Give us folders, give us freedom! How much longer do our Objects and Received Items folders need to be violated with the useless unpacker trash only intended for the incapable majority? We have a voice! #FreeTheFolder #UndoTheUnpacker #CopyTheContent

You can make this work with 1-2 lists. I'm posting from my phone so I can't make a code-block and won't use proper syntax. list words = [you, are, awesome]; // strings list sounds [uuid1, uuid2, uuid3]; With those, arranged so that "you" and "uuid1" are a matching pair, you can parse the received message into a list with llParseList2String (after you have converted the message to lowecase with llToLower) and write a loop to llListFindList every word in that parsed list to see if the individual words are found in the "words" list. If they are found (llListFindList isn't -1), you can use the resulting index to play a sound from the "sounds" list: llPlaySound( llList2Key(sounds, index), 1.0); P.S. You should use many separators, like space, period, comma, !, ?, and any other symbols that a user might put right after a word. This is because "you" is not the same as "You?" or "YOU!" or "you."

My question to you is: Do these prims HAVE to change appearance at the same time? Scripts on SL can be interrupted (or rather ignored) during any given "frame" of processing time. If you have multiple calls, other scripts might (and they will) be prioritized over yours, leaving only the first few prims with new appearances until the rest of the script gets to run. If you only have one call, even though it can be delayed, it will affect all prims at the same time. Personally, if my intent was "simultaneous change," I would use one big call. I think there is no significant difference in memory usage, and the code can be neatly formatted on multiple lines. One call might be faster as well, but I have no proof.