Rolig Loon

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:

It may be a lag problem. IMs can sort of pile up and then get dropped if the servers are too busy. If it's happening consistently with one avatar, though, that's not a likely answer. It's possible that your friend has muted that one av, either on purpose or by accident. You might ask. Can he receive normal chat from you in world?

It's still there in Phoenix, and there are several good free translators available in world too. I use the Phoenix system now, but I have used the Simbolic translator and found it fairly reliable. Many people I know also use the Universal translator, also free. None of the systems is perfect, but if you stick to simple, short sentences and avoid slang (and typos, my downfall), then they are good enough for most conversation.

Ah, OK. I see what you want to do. You still can't do it, but let me show you why. Put the jacket on and then go into Appearance mode. Select the tab that says "Jacket". You'll see a display that has three square windows on the left side and a series of windows on the right that have sliders for changing various properties of the jacket. The windows on the left are labelled Upper Fabric, Lower Fabric, and Color. Those two fabric displays are not just thumbnail pictures of the fabric; they are also pattern pieces cut to the shape of the jacket. If you had that pattern in your inventory -- you don't, because LL doesn't supply it -- then you could download it, modify it, and replace what's there. You could also drop any other pattern in there, if you had one. Making those patterns -- a clothing texture -- is what creative artists in SL do. If you're interested in learning, take a look at some of the excellent tutorials HERE. You can change the color of the jacket in a limited way. Try clicking on that square window labeled "Color." That will open the color picker, from which you can chose some other hue. In this case, your choices are severely limited because the base texture is black although the applied color is white. Try changing to something strong like red, though. You'll see that it does have some effect. I'd suggest that you look in world for freebie clothes and try doing this same experiment on them. So long as the clothes can be modified, like this jacket, you can play with the color as much as you like. You'll have best luck if your work with white or pale-colored clothes, obviously. Good luck. I know this was a frustrating start, but if you have an artistic mind, you can have fun doing this sort of creative work.

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.

Oh, you can dye your jacket, or replace its fabric with any other fabric that you own (as long as you have mod permission on the jacket itself, which you apparently do). You just can't copy the existing texture unless you have permission from the artist who created it. It's not a SL restriction. It's a legal restriction in almost every country. Intellectual property.

From what I can tell from a quick Internet search, your system is having trouble finding the OpenGL drivers for your graphics card. It seems to be a problem with Windows 7 on some systems with ATI graphics cards. The newest drivers are apparently faulty. Here's a suggested fix posed on ONE TECH FORUM: in order to use openGL, copy : %WINDIR%\system32\opengl32.dll - to : %WINDIR%\system32\.dll yes... ".dll" without name. Will work with the following command: start -> execute (or shortcut WindowsKey + R) : cmd [ok] cd %WINDIR%\system32 copy opengl32.dll .dll If UAC's still active you may have to run command prompt as administrator. This is relevant *only* if you're using an ATI videocard *and* you're under Vista or 7. I have absolutely no idea whether this works or not. I simply copied it from the site I referenced above.

If you don't have a full perm copy of the texture in your inventory, then you can't export it to your hard drive to make any modifications. You would need to have either made the texture yourself or bought it with full permissions. Making a copy of a texture that you do not own is a violation of the TOS and DCMA, so I don't recommend it. If you do own the full perm texture, however, all you need to do is open it in world and select File >> Save Texture As ... to export it to your computer. Then you can use Photoshop or GIMP or whatever.

I think it's a matter of poor statistical sampling. The new forums just haven't been around long enough to build a steady user base. A lot of people are still stumbling around, trying to figure it out. Frankly, I find the new Knowledge Base difficult to search myself, so it doesn't surprise me if the usage statistics there are all screwy. I agree with Charolotte that I've seen a rather healthy increase in the number of posts in Answers from non-English speaking residents. Hardly a day goes by that I don't find myself responding to someone who posted in French or Italian. Fewer Germans so far, but again we may just be dealing with the statistics of small numbers.

It's a bit hard to tell from your description, and I can't get in world to look for myself, but are you sure that it isn't just a set of megaprims with an alpha texture applied to them? That's how I would do it if I had to.