Rolig Loon

As a recent post to the Scripting forum pointed out, unpacker scripts scatter no-copy items all over your inventory. This can mean that you get a lot of IMs from frustrated and confused SL newbies who open one of your gift boxes and then can't find where everything went. There's no new magic to this short script -- you still have to give no-copy items individually, after all -- but it does send the new owner a friendly message that tells where to look for each unpacked item. list gItems; list gNocopy; list gList_types = [INVENTORY_NONE,INVENTORY_TEXTURE, INVENTORY_SOUND, INVENTORY_LANDMARK,INVENTORY_CLOTHING, INVENTORY_OBJECT, INVENTORY_NOTECARD, INVENTORY_SCRIPT,INVENTORY_BODYPART, INVENTORY_ANIMATION, INVENTORY_GESTURE]; list gList_names = ["None", "Texture", "Sound", "Landmark", "Clothing", "Object", "Notecard", "Script", "Body Part", "Animation", "Gesture"]; default { state_entry() { integer All = llGetInventoryNumber(INVENTORY_ALL); while (All) { string name = llGetInventoryName(INVENTORY_ALL, All - 1); if (name != llGetScriptName()) { if(llGetInventoryPermMask(name, MASK_OWNER) & PERM_COPY) { gItems += [name]; //Copy perm items } else { gNocopy += [name]; //No-copy perm items } } --All; } } changed (integer change) { if ((change & CHANGED_INVENTORY) || (change & CHANGED_OWNER)) { llResetScript(); } } touch_start(integer num) { llOwnerSay("Look for unpacked items in a folder named " + llGetObjectName() + " in your inventory."); llGiveInventoryList(llGetOwner(), llGetObjectName(), gItems); integer len = llGetListLength(gNocopy); if (len) { llOwnerSay("Also, look for the following one-of-a-kind items:"); while (len) { // Determine what kind of inventory this is, and find that type in the gList_types list integer idx = llListFindList(gList_types,[llGetInventoryType(llList2String(gNocopy,len-1))]); // Then use idx to find the name of that type in the gList_names list and say it if (~idx) { llOwnerSay(llList2String(gNocopy,len-1) + " will be in your " + llList2String(gList_names,idx) + " folder."); llGiveInventory(llDetectedKey(0),llList2String(gNocopy,len-1)); } --len; } } } }

PosJump is working fine for me this morning and I haven't had any trouble recently. What does "not working properly" mean? It lands you at a strange destination? It doesn't TP you at all? PosJump will give you trouble if you have to pass through a No Entry parcel on the way to your destination, so you should use the safe version to at least prevent you from being thrown off world.

The Scripting forum is meant as a place for scripters to learn from each other. It's not really a place to look for scripts. If you are looking for someone to write a script for you, the best place to ask is in the Inworld Employment section of the Commerce Forums (http://community.secondlife.com/t5/Inworld-Employment/bd-p/InworldEmployment). If you are looking for a script that already exists, try Marketplace or the LSL Scripting Library (http://community.secondlife.com/t5/LSL-Scripting-Library/bd-p/LSLScriptingLibrary) or the Wanted section of the Commerce forums (http://community.secondlife.com/t5/Wanted/bd-p/Wanted). You will have much better luck.

This is a tough script to read. Style is a very personal matter and we each use whatever works best for us. Still, if it were my own script I wouldn't pack multiple functions on a single line. I'd find it hard to debug. Just sayin' .......... You'll need to include a dataserver event in your default state to read the notecard and a llGetNotecardLine function to trigger it. See the short example HERE.

I've found that the best way to sell a script on Marketplace is to embed it in a notecard. That has the added benefit that you can include any description, instructions, or greetings in the same notecard and be sure that they will be stored together in inventory when the customer receives them. You can also include a LM to your in-world shop.

I am out of town and away from my computer so there's no way I can test this, but I think you can get rid of that wonkiness by just dividing the variable rot where it appears in the two places in Kaluura's function by llGetRot(). You may also need to divide the quantity Hinge + (Door * rot) by llGetRot() as well. Of course, I could be wrong ..... :smileytongue:

That;s true. That's why I put some weasly qualifiers in my post earlier. The prim does have to be fairly large and you can't move around faster than the script's response rate or you'll outrun the thing. Even then, it's not perfect. Still, it's a nice toy and it does draw your eye away from the annoying white dot most of the time.

Or use Photoshop CS4 or CS5, both of which allow you to work on your design in 3D, so that you can paint directly on the avatar body. That will let you see exactly where the seams fall and make it easy to align and adjust patterns across them. If you don't have that capability, you'll have to do a lot of uploading temporary textures to SL (they are free if you use Phoenix or Imprudence, or if you upload to the Aditi grid), trying them on, photographing seams, and then adjusting. It can be slow work, but doable.

Upload the template as a texture, apply it to a new shirt, and wear it. You'll see where all the lines go on the avatar body easily enough. Take a pile of photos from all different angles and save them on your hard drive for reference later.

Well, yes.... You are sending a message on a channel that is equal to -1234 times a hefty number based on the sender's UUID but the receiving objectis listening for a message on channel -1234. It will never hear a thing If you want it to hear on channel -1234, you have to send on channel -1234 If you are dealing with unlinked objects, this is one way to change textures and colors. If your objects are linked, though, it is much better to use llSetLinkPrimitiveParamsFast to do the job It's faster, and you save the sim overhead on running several scripts when one will do

Thanks, Peter. I've had this debate with myself many times over the years, and I usually come down on the side of pre-decrement, not for any rational reason but because it seems to be the way that my mind works. It just seems natural to me, so I seem to make fewer logical errors when I go that route. That's the essence of personal style, I suppose. (It also shows, perhaps, that I am a self-taught amateur instead of a properly-trained professional.) It does help to have the debate in the open occasionally, though, especially for the benefit of those who haven't made up their minds yet. :smileywink:

You want to learn how to create a dialog menu? Take a look at THIS TUTORIAL. It's about the best one I've seen. As Peter says, we can't help much without seeing your script. Off the top of my head, though, the things that most commonly lead to a syntax error are Forgetting to open and close the scope of an event or condition test with { curly brackets }. It helps to indent each scope cleanly so that you can see where the brackets ought to be. Having unmatched parentheses (same problem as curly brackets). Having unmatched quotes around a string (same thing,...). Using the wrong variable type in a function (an integer where there should be a string, for example). There are others too, but those four are at the top of my D'uh list. I trip over at least one every day, despite best intentions. The best way to beat them is to be neat and consistent, and to use a good script editor that explains what your mistake was.

I've heard the same myth. Some day, when I remember it in time, I'll have to test and see if there's some truth to it. This is not very high on my priorities, frankly. :smileyvery-happy:

For what it's worth, I have had a version of that problem since I joined SL in 2007. I have to change a profile pic two or three times before the new one finally sticks. It's done that with every viewer I've used, so I figure it's just one of those fun, undocumented "features" of SL. (I know nothing about sidebar or chat icon pics, since I'm not using V2, but my guess is that those would do the same thing for me.)

Well, there was only one small error and one oversight on my part. The error was in the end of the touch_start event. I used llGiveInventory to give a no-copy item and then tried to get its inventory type. That won't work, because the item is no longer in inventory at that point :smileytongue:, so I simply changed the order of the statements to make it work as advertised. The oversight --- the thing that made it not work for you -- is that I should have included a changed event that would reset the script if the inventory in the box changes. The script didn't work for you because you put the script in the box first, then added items and didn't reset the script. As a result, the setup sequence in the state_entry event never saw those items. The script thought the box was still empty. So, I fixed things by adding a changed event. Here's the repaired script, field tested. It works. :smileyhappy: list gItems;list gNocopy;list gList_types = [iNVENTORY_NONE,INVENTORY_TEXTURE, INVENTORY_SOUND, INVENTORY_LANDMARK,INVENTORY_CLOTHING, INVENTORY_OBJECT, INVENTORY_NOTECARD, INVENTORY_SCRIPT,INVENTORY_BODYPART, INVENTORY_ANIMATION, INVENTORY_GESTURE];list gList_names = ["None", "Texture", "Sound", "Landmark", "Clothing", "Object", "Notecard", "Script", "Body Part", "Animation", "Gesture"];default{ // Put this stuff in state_entry because you only need to do it once state_entry() { integer numberofitemsincontents = llGetInventoryNumber(INVENTORY_ALL); while (numberofitemsincontents) { string name = llGetInventoryName(INVENTORY_ALL, numberofitemsincontents - 1); if (name != llGetScriptName()) { if(llGetInventoryPermMask(name, MASK_OWNER) & PERM_COPY) { gItems += [name]; //Copy perm items } else { gNocopy += [name]; //No-copy perm items } } --numberofitemsincontents; } } changed (integer change) { if ((change & CHANGED_INVENTORY) || (change & CHANGED_OWNER)) { llResetScript(); } } touch_start(integer numberofagentstouching) { llOwnerSay("Look for unpacked items in a folder named " + llGetObjectName() + " in your inventory."); llGiveInventoryList(llDetectedKey(0), llGetObjectName(), gItems); integer len = llGetListLength(gNocopy); if (len) // That is, if len > 0 { llOwnerSay("Also, look for the following one-of-a-kind items:"); while (len) { // Determine what kind of inventory this is, and find that type in the gList_types list integer idx = llListFindList(gList_types,[llGetInventoryType(llList2String(gNocopy,len-1))]); // Then use idx to find the name of that type in the gList_names list and say it llOwnerSay(llList2String(gNocopy,len-1) + " will be in your " + llList2String(gList_names,idx) + " folder."); llGiveInventory(llDetectedKey(0),llList2String(gNocopy,len-1)); --len; } } }}

Hmmmm... Well, I warned you that I hadn't had time to test it in world. :smileysurprised: It's probably something small. I'll take a look at it again this evening. Meantime, though, do keep poking at it. I always learn a lot by trying to figure out how someone else's script is supposed to work. Maybe you will too. (This is my way of trying to pass of my scripting error as a "learning experience." )

As far as I've ever been able to tell, it's a randomly scheduled event, about once every week or so.

It can only be minimized, not removed. The problem is an OpenGL issue, not a SL issue, except to the extent that SL has been largely built and textured by amateurs who don't know how to work around alpha sorting as they design. There's only so much that LL or the TPV developers can do.

Any script posted in the library is presumed to be full perm. I would be very upset if I heard that someone were trying to sell the script itself, since I could have done that too but chose not to. You're quite welcome to use it in a product or anything else short of that, however. Glad that you find it useful. :smileywink:

Educators in SL debate this question all the time. If you aren't already on the SLED list, join now and pose your question there. You'll have more than enough answers in no time.

Hehehe .. I had time on my hands, and this is a nice short problem. Try this...... list gItems;list gNocopy;list gList_types = [iNVENTORY_TEXTURE, INVENTORY_SOUND, INVENTORY_LANDMARK,INVENTORY_CLOTHING, INVENTORY_OBJECT, INVENTORY_NOTECARD, INVENTORY_SCRIPT,INVENTORY_BODYPART, INVENTORY_ANIMATION, INVENTORY_GESTURE];list gList_names = ["Texture", "Sound", "Landmark", "Clothing", "Object", "Notecard", "Script", "Body Part", "Animation", "Gesture"];default{ // Put this stuff in state_entry because you only need to do it once state_entry() { integer numberofitemsincontents = llGetInventoryNumber(INVENTORY_ALL); while (numberofitemsincontents) { string name = llGetInventoryName(INVENTORY_ALL, numberofitemsincontents - 1); if (name != llGetScriptName()) { if(llGetInventoryPermMask(name, MASK_OWNER) & PERM_COPY) { gItems += [name]; //Copy perm items } else { gNocopy += [name]; //No-copy perm items } } --numberofitemsincontents; } } touch_start(integer numberofagentstouching) { llOwnerSay("Look for unpacked items in a folder named " + llGetObjectName() + " in your inventory."); llGiveInventoryList(llDetectedKey(0), llGetObjectName(), gItems); integer len = llGetListLength(gNocopy); if (len) // That is, if len > 0 { llOwnerSay("Also, look for the following one-of-a-kind items:"); while (len) { llGiveInventory(llDetectedKey(0),llList2String(gNocopy,len-1)); // Determine what kind of inventory this is, and find that type in the gList_types list integer idx = llListFindList(gList_types,[llGetInventoryType(llList2String(gNocopy,len-1))]); // Then use idx to find the name of that type in the gList_names list and say it llOwnerSay(llList2String(gNocopy,len-1) + " will be in your " + llList2String(gList_names,idx) + " folder."); --len; } } }} I haven't field-tested this script, so it's not guaranteed to be free of a loop index error, but it compiles and looks OK. If nothing else, it shows one way to hand out the copy-perm things in a single folder and the no-copy things individually, along with a friendly note that tells the owner where to find them. Play with it. :smileyhappy: ETA: Well, I did catch a loop index error, and fixed it. With luck, that's it.

That's a very good question indeed. There was a time when separate language knowledge bases would have been unquestionably the right answer. As translator software has improved steadily, though, we are getting to a point where that's no longer clearly the best answer. I can see a future not far off in which the KB is published only in English, translatable at the push of a button to the user's own language. You can anticipate that day now by writing KB text in nice short, simple sentences that use a minimum of jargon. Test how well they translate with Google Translate or your favorite software. When your own text (or the software) is good enough to withstand translation, you've arrived.

The problem is that llGiveInventoryList does not let you include any no copy items in the list. See caveats in the LSL wiki HERE: If inventory permissions do not allow copy, the transfer fails and an error is shouted on DEBUG_CHANNEL. You didn't ask for anything else, but while I'm here .... :smileytongue: You can simplify your list-building statement by writing if (name != llGetScriptName()) {items += [name];} The extra step of clearing the list before adding new items doesn't make any difference, and it makes your code clunkier. At the same time, although not strictly necessary, you should get in the habit of always inserting curly bracketsaround the scope of an if test, even if it's only one line. It's a good habit, because soone or later you'll forget the brackets and add a line that gives you a logic error.

Nope. When you start a timer, you specify llSetTimerEvent(X), where X is a number in seconds. There's a practical limit on how big X can be, because the largest number LSL can handle is 2,147,483,647. However, there are only 31.2 million seconds in a year, so SL isn't going to be around long enough to hit that limit.

I'm not sure what you mean. Dead is dead. The timer you write determines when the object dies. Once it no longer exists, there is no more. In this case, it sounds like the OP really wants to delete the object from inventory when he has given out enough copies. That's not llDie, but llRemoveInventory. ETA: Actually, as I reread the OP, it's not clear whether he wants the items in the vendor's inventory to disappear after a number of them have been dispensed, as I thought, or whether he wants the entire vendor to disappear. If it's the first of those, llRemoveInventory is the right choice. If it's the second, llDie is. In either case, it's a final action. Once something's gone, it's gone. :smileywink: