Rolig Loon

If you were working from a PC with an NVidia card, the answer would be to disable the Threaded Optimization option. That's the usual cause of this behavior. Since you're not on a PC, though, I suspect that you have a hyperactive anti-virus programm on your machine. There is at least one anti-virus program which will scan every file placed on your computer, even if created by an authorized program. This affects any viewer, because it will scan each and every texture placed in cache, slowing down performance of the viewer significantly, and keeping CPU usage high. If you find yourself in this situation, see if you can exclude the viewer cache folder from being scanned. Ideally, you should exclude the entire settings folder as well. You can determine the current location of your cache by looking at Preferences → Network & Folders → Disk Cache Location and Sound Cache Location (if this is set). See http://wiki.phoenixviewer.com/antivirus_whitelisting for whitelisting instructions for any of the common AV programs.

It is odd, I agree. If you've watched a crowd of people all dancing off the same dance ball, though, you've probably seen a similar thing happen. Every once in a while, one person in the crowd will freeze for a while (occasionally it's you). Funky connection at work. I'm still guessing that's your problem. You can simplify your setup significantly, though, to eliminate all those extra scripts. If nothing else, it will reduce your script overhead, and it might make a differnce to this problem too. You will have noticed that I aimed that llLinkSitTarget at link #2. If you have four seats on different prims, you can as easily put link sit targets in each one from that same script and avoid needing to put any scripts in the other prims. If those scripts are dealing with animations as well as the sit targets, you can use llAvatarOnLinkSitTarget in your changed event to identify each one, request permissions, and start the animations. The scripting to do that is mildly tricky. but not a major challenge. When it comes to setting the offsets and rotations, you can use one of the commercial products like Dora Gustafson's sit target calculator, but I find that it's almost as fast to just use trial and error.

Nope. It works like a dream for me. I suspect that your friend has a funky Internet connection. She's not on wireless, is she? You'll have to adjust the sit target for your own train, of course. But she should see herself seated at the same position that you do, once you get it set. Again, if she doesn't, there's something screwy with her setup.

1. Stand in your house 2. Take all of your belongings back to inventory, one at a time (NOT in a lump) 3. Click World >> About Land >> General >>. Abandon Land 4. You're FREE!

What's a blackbox? The Unix system, maybe?

When you add information to the JIRA, would you please include as much information about your system as you can, to help Linden Lab's developers isolate the problem? Also, include the information that you posted here.

It has "sprung up" well before today. We've seen occasional reports here in Answers for over a year and there are expired JIRAs that go back to 2009. The message itself is a Windows message that reports a RAM error, not a SL message, but I do worry about what is triggering it. I also worry about why we have had a half dozen reports since the end of May. That's why I opened the JIRA this afternoon, to alert Linden Lab's developers, so that if there IS something in SL that's triggering the error, they at least have a heads up. Thank you for commenting on the JIRA. Would you please add your system information so they have more to work with?

The LSL wiki page for llHTTPRequest notes that Requests must fully complete after 60 seconds, or else the response will be thrown away and the http_response status code will be 499.I suspect that once you flood the sim's servers with requests from several scripts or objects, it takes a while to clear the queued requests, each of which then returns 499 because it has gone past the 60 second limit.

Easy. Just replace llGetOwner() with "".

"Thinner" means only a very few pixels wide. The crotch is very poorly designed on the avatar mesh, so you will always see bleeding (sounds nasty) if you draw outside that 2 to 5 pixel wide zone. That accounts in large part for the popularity of thong underwear -- an abominably uncomfortable style in RL -- in SL wardrobes. It's either that or boxer shorts. :smileysad:

Yes. I opened that JIRA this afternoon to consolidate the handful of cases we've seen here in the past month or so. I'm not convinced that there's anything the LL developers can do, because it's a Windows error. Still, if there's any chance that a SL viewer contributes to the problem, it's worth alerting them. It would help if people who add comments would cut & paste their own system specs into their comments.

When you're using llTargetOmega, the object isn't actually moving at all, as far as the servers are concerned. The only motion is in your own viewer, generated by your GPU. If something happens to stall that -- a local blip in your Internet connection of some kind -- the motion might stop in your own viewer but not in anyone else's. You might try forcing the object to update its actual rotation every once in a while by applying something like llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROTATION, llEuler2Rot(<0.0,0.0,PI/4>)*llGetRot()]); for example. That should be enough to convince your graphics card to keep the llTargetOmega rotation going. EDIT: Corrected LINK_SET to LINK_THIS. So long as your script is in the root prim of the linkset, this works. Here's a sample script to show what I mean... integer gON;default{ state_entry() { llLinkSitTarget(2,<0.3,0.0,0.6>,ZERO_ROTATION); // Sit target is in the "train" child prim } touch_start(integer total_number) { gON = !gON; if (gON) { llTargetOmega(<0.0,0.0,1.0>,PI/3,1.0); llSetTimerEvent(1.0); } else { llTargetOmega(<0.0,0.0,0.0>,1.0,1.0); llSetTimerEvent(0.0); } } timer() { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROTATION,llEuler2Rot(<0.0,0.0,PI/4>)*llGetRot()]); }}

If you're using Firestorm, you should be able to type CTRL + H to open your Chat History while you are in mouselook or CTRL+T to bring up conversations window in mouselook. I don't use the V3 viewer, but I suspect that something similar works in it as well.

Aside from offering generic advice, there's not much we can say without knowing more about your computer, its Internet connection, and how you have your viewer configured. It's possible that some changes in the last round of server upgrades have made a difference. Other than that, I suggest checking through the ideas at http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 . If you post more details about your own system, we might have more specific suggestions. Just click on the Options link in the upper right corner of your question and select EDIT. Please do NOT start a new thread.

You didn't explain why you can't upload, or what happens when you try, so all I can do is show you the instructions ... You add items to your Marketplace listings by using a window called the Merchant outbox, which uploads your items to the Marketplace website. After uploading new items, you may then create item listings for them on the Marketplace website. Uploading items using the Merchant outbox Open the MERCHANT OUTBOX window in the Second Life viewer by choosing Me > Merchant Outbox. Drag items you wish to sell from your inventory into the MERCHANT OUTBOX window. Organize items into folders in the Merchant outbox if they are meant to be sold together. You do not need to box items in order to sell more than one item in a single listing on the Marketplace. Click the Send to Marketplace button to upload all items from your Merchant outbox to the Marketplace website. Adding the item on the Marketplace website On the Marketplace website, choose My Marketplace > Merchant home in the upper-right. Click Manage Inventory on the left side of the page. Under Unassociated Marketplace Inventory, click the name of your item to start editing the item listing, then complete the required fields. You can find a description of all the listing fields here. Second Life Tutorial - Converting item boxes to Direct Delivery folders.wmvRead more infomation about creating and managing your Marketplace store at http://community.secondlife.com/t5/English-Knowledge-Base/Selling-in-the-Marketplace/ta-p/70019 . If you have a specific question about something that's not working for you, click on the Options link in the upper right corner of your question and select EDIT to add information. Please do NOT start a new thread.

MOAP is a very handy feature. It should work fine in your HUD, and others shouldn't be able to see it. After all, the prim that it's on is not visible in world. It's on your own screen. You should be aware, however, that many SL residents keep streaming media switched OFF in Preferences because they are afraid that someone will be able to capture their IP address when it's activated. Those people will not be able to see the web site if they are using your MOAP-enabled HUD. As an alternative (or perhaps a supplement) you may want to consider using llLoadURL and simply opening the web page in the user's default browser. I have created several MOAP displays that give users that option.

So far, so good. The screen is supposed to go a bit darker and you're supposed to get a window to select the image to upload. The system won't let you upload a pic unless it is in the right format, though. It has to be PNG, JPG, TGA, or GIF. Also, your image's largest dimension should be 700 pixels. Marketplace will downsize images that are too large, but that is a very slow process. The sequence may time out before it finishes. For more information about photos for Marketplace, see http://community.secondlife.com/t5/English-Knowledge-Base/How-to-market-your-products/ta-p/700181#Section_.3

"It" might be your browser. For reasons that nobody can explain, SL's web sites have always had trouble with the Internet Explorer browser. Try using Firefox or Chrome instead. They work for most people.

When was the last time you cleaned the dust out of your computer and checked to be sure that the fans are spinning properly? The first thing I suspect when someone crashes within a few minutes every time he logs in is that the computer is overheating. Crashing is your computer's self-protection against burning up vital components. Even if it's not the answer in this particular case, check it first and get in the habit of using a can of air to blow out dust bunnies and cat hair once a month (more often if you have a big cat). If that doesn't do the trick, click on the Options link in the upper right corner of your question and select EDIT to let us know so that we can try something else. Please do NOT start a new thread.

I don't know why, but we have seen 3 or 4 people this week with that error message. The message that says (0xc0000005) is not a message from Second Life. It's a Windows message, described in this thread >>> http://www.updatexp.com/0xC0000005.html , for example. The implication from this and similar sites that you can find with Google is that this is a RAM error --- a failing memory chip somewhere in your computer.

Always download graphics card drivers from the manufacturer of the card, not the company that made your computer. Intel Video Driver Intel driver download page Intel does not have a universal driver set. Please go to Intel's site and select the appropriate download.You should be aware, though, that the Dell Latitude D620 is a business notebook that's designed for handling office tasks like spreadsheets and database management. It's not likely to give very good performance at all in SL. You may get your best performance with graphics set on Low and with a short draw distance. Do NOT use wireless. If you are lagging badly with the standard V3 viewer, consider installing a third party viewer like Phoenix, Imprudence, or CoolVL that will put fewer demands on your notebook.

So put a llRegionSayTo statement in the touch_start event of each script, aimed at the other object, and accompany it with a listen event in each object that listens for the message. Put your texture change command in the touch_start event and the listen event in both objects. That way, no matter which object you touch, the touch will change its own texture and the message it sends will change the texture of the other object. Just be sure that you change textures with llSetLinkPrimitiveParamsFast, not with llSetTexture. llSetTexture has a 0.2 second delay, which will mess up your synchronicity.

Now I'm getting worried. This is the second time today for this same rare message. I wonder if it's the heat? The message that says (0xc0000005) is not a message from Second Life. We've had a small handful of posts about this problem. It's a Windows message, described in this thread >>> http://www.updatexp.com/0xC0000005.html , for example. The implication from this and similar sites that you can find with Google is that this is a RAM error --- a failing memory chip somewhere in your computer.

Firefox won't recognize a SLURL unless you have told it what one is. You might have to do that manually unless you have a viewer that does it for you. In Firefox: 1. Click on the Tools >> Options >> Applications menu 2. Scroll down until you see "Secondlife" in the left column 3. Use the dropdown menu in the right column next to it to identify your viewer's exe file 4. Click OK to close the window. Thereafter, Firefox will know that if it sees a SLRUL, it is supposed to pass it to your viewer for execution.

When you write your LSL script, you use llRequestPermissions, which then acts as a trigger for a run_time_permissions event in which the script checks to see whether the permission has been granted. Here's the example from the LSL wiki page... default{ touch_start(integer detected) { llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION); } run_time_permissions(integer perm) { if (perm & PERMISSION_TRIGGER_ANIMATION) { llStartAnimation("sit"); llOwnerSay("animation will end in 5 seconds"); llSetTimerEvent(5.0); } } timer() { llSetTimerEvent(0.0); llStopAnimation("sit"); }} When someone (llDetectedKey(0)) touches the scripted object, the llRequestPermissions function is called, asking PERMISSION_TRIGGER_ANIMATION. Then the run_time_permissions event checks to see if (perm & PERMISSION_TRIGGER_ANIMATION) [that is, whether it was given]. If so, the script goes on to start the animation and a timer.