Rolig Loon

Check to be sure that 1. You have enabled streaming music in Preferences >> Sound & Media 2. You haven;t set your Maximum Bandwidth (in Preferences >> Network) higher than 75% of your Internet connection's measured download bandiwdth. 3. You are in a parcel that has a music stream, and you have accepted the stream (if you have the media filter in your viewer activated) 4. You have toggled music ON (the musical note in the upper right corner of your viewer screen). 5. You have moved the volume slider for Music (in the dropdown menu under the speaker icon in the upper right corner of the screen) far enough to the right. 6. You have your computer's speakers turned on and activated. If it still doesn't work, try relogging.

Hmmmm... You are still saying the words "Devil", "Chariot" and so on, only now you have added the word "(String)" to each one. You're still not getting the idea of reading a variable from one of those lists. Each time you do your randomize and squash exercises, you end up with a list that has only one variable in it. There are two ways to say that variable. One way is to say llSay(0, llList2String(Devil,0)) or whatever the list is. The other way is to say the entire list as a string, like this ..... llSay(0,(string)Devil). Either way works in this case, because you only have one variable per list. The first way is more generalizable, so that's what most scripters would prefer. Now, you really don't need all those lists. They're a waste of memory and they make for an unnecessarily long code. Here's a way to compress it into fewer steps. list gCards = ["The Fool","The Magician","The High Priestess","The Empress","The Emperor","The Hierophant","The Lovers","The Chariot","Justice","The Hermit","Wheel of Fortune","Strength","The Hanged Man","Death","Temperance","The Devil","The Tower","The Star","The Moon","The Sun","The Judge","The World"];default{ touch_start(integer total_number) { list cardlist = []; integer i; while ( i< (gCards!=[]) ) //(gCards !=[]) == llGetListLength(gCards) { string Side = llList2String([" (Truth)", " (Reverse)"],llFloor(llFrand(2.0))); cardlist += [llList2String(gCards,i) + Side]; ++i; } llSay(0," \n" + llDumpList2String(cardlist," \n")); }}

Yes, there are several gadgets like that and they are all unsatisfactory. The way they work is by tilting the skirt forward at the waist when you sit, so that it tilts up and rests on your thighs instead of penetrating them. It sounds like a smart idea except that.... 1. Rotating the skirt forward means that the waist goes UP in the front and DOWN in the back, exposing a butt crack. 2. It's activated by anything that its script interprets as "sitting". That includes dancing, standing on a pose stand, using a "sit" teleporter, and many other things. These can be embarrassing...... 3. It's meant to adjust for when you walk too, so that th skirt doesn't fly up behind as you walk. But if you take only a step or two at a time, the skirt starts flapping up and down like it's bewitched. In short, don't bother. ETA: Oh, OK... but don't say that I didn't warn you. You can find several of those things by going to Marketplace, setting its search to look in the Scripts section, and typing in the keyword "Skirt".

If your billing agreements are not updating properly, it often has something to do with the bank or card issuer. Some credit card companies will automatically decline or hold for review international charges (or "online gaming" charges) as a safeguard against fraud. If you are located in the U.S., delete and re-enter your payment method. This will make it go through the domestic processor, which reduces the chances of your financial institution putting a hold on the transaction. Important: Credit and debit cards require up to 30 minutes to update in our system. Even if you receive the message “your payment information has been successfully updated,” you must still wait up to 30 minutes before attempting purchases. If you're having trouble getting a billing agreement to update: If you have waited at least 30 minutes and have attempted several transactions that failed or information is still pending update, delete and re-enter your billing information or try an alternate method of payment (credit or debit card). To do this:Go to Your Dashboard. Click Account. Click Billing Information. Update your billing information then click Submit. If the update is sucessful, you will see the message "Your information has been successfully updated". Wait 30 minutes to get approval from your payment processor. After the second attempt, if transactions are still failing or information is still pending update, contact your credit or debit card issuer:Ask to speak directly to the risk and security department. Explain that you wish to authorize your card for charges from Linden Research and Second Life. While on the phone, clear and re-enter your billing information. The bank or card issuer should then see (and approve) a $1 verification charge; which will be refunded. If you are still unable to complete a transaction after following the above steps, contact Linden Lab billing support BTW, please note that a common cause of payment method failure is the use of unsupported card types. At this time, the majority of prepaid cards are not compatible with our system, even if they bear the VISA/AMEX/Mastercard logo. This includes cards purchased at retail stores, rechargeable credit cards, and bank-issued check cards.

Visiting relatives in Slobovia? Studying abroad? Hiding from the Mafia or the tax authorities in a third world country? :smileytongue:

Try asking the visitor. That's the only legal and reliable method (unless they're lying).

I'm not exactly clear about what's going on here. If you have made the objects yourself and have used only textures, objects, scripts, animations, and sounds that you have full perms for, then your builds should still be full perm until you change them. The overriding rule is that next-owner perms for an object take on the most restrictive permissions found in the object. So, unless you change your own full-perm build to, say, no-mod, for the next owner, it should remain full perm. If you included a no-copy texture in the object's contents, the whole object would become no-copy when you sell it. (If you buy it back, it would remain no-copy too. You give up creator perms when you sell the object.) That's the way it's supposed to work. There can be a problem with some objects, however. If you include a no-trans sculpty or texture in an object, save it to inventory, re-rez it, and then remove the no-trans component, the object can sometimes refuse to go back to being full perm. There was a thread on this topic recently in the Building and Texturing forum. That's an old bug, sttill unresolved. The only solution is to rebuild your object. ETA: Permissions can be very confusing. One aid for cutting through the confusion is the Advanced Permissions menu, which you toggle on at Build >>. Options >> Show Advance Permissions Menu in your viewer. Take a look at http://wiki.secondlife.com/wiki/Debug_Permissions to see hat that does for you.

All of the V3-level viewers can handle mesh, alpha layers, and multiple layers. Many of the V1 level viewers like Phoenix, CoolVL, and Imprudence (I think) can too. Avoid the 1.23 viewer, which is almost impossible to find now anyway, and of course the text-only viewers like Radegast.

Hehehe.. I think we are chasing each other today. ... I am going for lunch now, so I'll get out of your way for a while.

It's Tuesday and Linden Lab is doing the previously announced server upgrades. Just wait. [updated] Second Life Main Channel Rolling Restart [updated 5:00am PDT, 21 August 2012] We will be beginning rolling restarts for regions on the main Second Life server channel shortly. Please refrain from rezzing no copy objects, making inworld L$ transactions and remember to save all builds. [Posted 12:05am PDT, 21 August 2012] We will be performing rolling restarts for regions on the main Second Life server channel. They will begin on Tuesday, August 21st at approximately 5:00AM PDT. Please refrain from rezzing no copy objects, making inworld L$ transactions and remember to save all builds.

Utilisez exactement la même méthode que vous avez utilisée pour créer votre premier avatar. Chaque compte est unique, tout comme si vous étiez deux étrangers de créer des avatars. Votre nouvelle alt est votre ami - peut-être votre sœur dans SL - mais vous êtes des gens différents dans la mesure où Linden Lab est en cause.

Yup. Just wait. Usually rolling restarts only affect your sim for about 15 minutes, but if they are having problems with the machine your server is on, it could take longer. In July it took my sim half a day during one upgrade. If you're still not up by this evening, submit a support ticket to prod LL into doing something extra.

I agree. That does sound annoying. You might check with your ISP or, if you are in a university or corporate setting, check with the IT department. They may have recently installed a pickier filter. I have never had a firewall problem myself, but I know that firewalls and antivirus issues often crop up for SL residents when they install a viewer upgrade. BTW, do you mean that you don't have ANY firewall or antivirus routine running on your computer? That's very dangerous these days. You';re wide open for a virus attack or identity theft.

Because 99% of the time, the problem is with the user's computer. A high percentage of the time, in fact, it's the user's Internet connection or the fact that he's bought an underpowered computer. I have no idea what the situation is in your case, since you didn't describe a problem in this post. I notice that you have asked about the traffic calculation recently, though. That one IS a Linden Lab problem, and it's an annoying one for people who care about those things. As a merchant, I sympathize. There are several JIRAs on the issue, so you'll have to put a watch on them and see what progress the developers are making.

OK, so what's broken? I can send out group notices just fine. Can't you? Why not? Under what circumstances?

To add to Kwakkelde's excellent explanation, let me point you to Innula Zenovka's very lucid discsussion in this recent thread >>> http://community.secondlife.com/t5/LSL-Scripting/Redoing-phantom-child-objects/td-p/1641681/page/2 . Look at the latest of her posts.

Scooter Hollow wrote: A single 256 frame blown up to the size of most of a person's screen is going to look blurry, there's nothing you can do about that. If you're doing a 10mx10m screen maybe you could use llSetTexture with full 1024 images, if you can deal with having the sleep and load time. That's probably the best alternative in this case, but I'd recommend using llSetLinkPrimitiveParamsFast, which doesn't have the 0.2 second rez delay of llSetTexture. Also, I'd preload each texture on a hidden face first, so that they rez instantly (assuming that each person's GPU can download and render them fast enough even then). I still balk at the thought of anyone putting that many 1024x1024 textures on a sim, although I know that some people do it regularly.

Well, one big problem is that your image in SL is not 1024 x 768 pixels. That may be what you created in GIMP, but when it's uploaded to SL, that will have been squished to 1204x512 pixels. All images in SL have dimensions in powers of 2 (32, 64, 128, 256, 512, or 1024 pixels. If you upload an image with non-standard dimensions, it is resized to the next lowest power of two. Your 4 x 3 frames are actually 4 x 2. When you stretch the frames to be on a prim face that's 4x3, you are introducing a false magnification, so they look blurry. It's probably less apparent when you view the entire texture as one, especially if you haven't stretched it yet.

Innula's right. Unless you plan on writing the LSL script yourself and need some help in doing it, please do not repost this in the LSL Scripting forum. Your best bet is to look in Marketplace or post a note in the Wanted forum to see if anyone has a script that does what you want. If you are a little more adventurous and know enough about scripting to know what you are doing with it, you can also look among the various script libraries here in the forums, in the Second Life wiki, or on the Internet. It may be easiest, though, to simply hire a scripter to write what you want. It's not a terribly hard script to write, so you should get quick responses. Post your request in the InWorld Employment forum.

For each object in the Second Life world, Second Life compares three important performance factors: download weight, physics weight, and server weight. It then chooses the highest of these weights and assigns it to the object as that object's land impact rating. Here's a very quick overview of the different weights; for more information on each, follow the links below: Download weight: Calculated by determining how much bandwidth is required to download and view the object. Larger and more visually complex objects have a higher download weight. You can reduce the download weight of complex objects by generating or uploading less complex meshes for differing levels of detail when you upload a model. Physics weight: Calculated by determining the complexity of the object's physics model. You can reduce the complexity of a mesh's physics model by using the analysis and simplification tools in the Upload Model window, by uploading your own less-detailed physics model, or by choosing a different physics shape type, such as Convex Hull, on the Features tab of the Build Tools window. Vehicles must have a physics weight of 32 or lower, but may have higher download or server weights. Server weight: Measures the impact an object has on Second Life's server resources. Objects that are composed of many prims and have physics enabled and/or contain scripts tend to have high server weights. In summary, the whole is greater than the sum of its parts, and sometimes in ways that are non-intuitive.

Ah, now here's a thought, suggested by a distant voice .... "llTakeControls needs to be set to accept == TRUE, pass == FALSE" Give that a try. :smileywink:

You went to all the trouble of winnowing the lists named "Fool" and "Magician" down to one name each and then you ignored them in the end and wrote list cardlist = ["Fool", "Magician"]; llOwnerSay((string)cardlist ); Of course it's going to say either "Fool" or "Magician". Those two words are the only choices in the list called cardlist. If you want to say the contents of the list named "Fool" and the list named "Magician", forget about cardlist. Just write llOwnerSay ( (string) Fool + " " + (string) Magician); :smileywink:

There could be a number of things going on. First, have you looked at the texture on a prim face without animating it? The largest texture dimension you can use in SL is 1204 pixels, so if you have more than 8 frames in a row, each one will be at most 128 pixels wide. That's not enough pixels for a real high definition image in each frame. (BTW, the PPI is totally irrelevant here. After all, a pixel is a pixel. The effective PPI is a function of how wide the object you have it on is, how much a person has zoomed in on it, and what the person's screen resolution is. And it's PPI, not DPI. DPI is for print media.) Then, have you been careful not to stretch it on the prim face you're viewing? If your frame is 128 x 256 pixels, and you are stretching it to fit on a 256 x 256 prim, it will have false magnification in the direction that you stretched it, so it will be lower resolution than you intend. Next, have you given the image enough time to rez? All frames will rez at once, of course, since they are all in the same texture. Remember, though, that the larger a texture is, the more time it takes to download to a viewer's GPU and get rendered. When an image is first made available for view, it is always blurry. A 1024 x 1024 texture can take an age. The way to beat that is to preload it so that each person "sees" the image before it's displayed. Hide it on a black prim face somewhere nearby but in the viewer's line of sight.

Start simple. Unless you already have 3D modeling skills and are prepared to make mesh items, work with system clothes and prim attachments first. You can do amazing stuff with them and they are still the foundation for building things in SL. Take a look at Natalia Zelmanov's tutorials. They are a little dated by now but still some of the easiest, best illustrated tutorials for beginning clothing designers.

If your avis always supposed to stand up as part of the shut-down process, you can try deliberately stopping all animations just before she stands. Something like this ..... listen (integer channel, string name, key id, string msg){ if (msg == "Shutdown") // From a dialog, maybe? { Shut_off_engines(); /// Whatever you do to turn off the engines....... llReleaseControls(); list temp = llGetAnimationList(llAvatarOnSitTarget()); integer i = (temp !=[]); while(i) { --i; llStopAnimation(llList2String(temp,i)); } llUnSit(llAvatarOnSitTarget(); }} You'll still have a problem if your av stands up without going through the sequence, but this should kill all anims so that your AO can start fresh once you're standing. ETA: It just occurred to me that you could also be running "striding", actually) because you're interacting with a physical object. See if it helps to put llSetStatus(STATUS_PHYSICS,FALSE) in that shutdown sequence.