Rolig Loon

It's easy enough to write one. The only ready-made one that I can think of at the moment is the one that Bucky Barkley has available on the top floor of the main library on Info Island. I can't get in world now to grab a SLURL for you, but it's very easy to find. TP to Info Island, go to the south edge of the sim, and walk up the stairs.

Torley has a sandbox where you can rez Linden plants here: http://maps.secondlife.com/secondlife/Here/7/7/69 . Unless he's changed it recently, you ought to be able to rez there.

I'm easy to find. There are only two Rolig's in the phone book, and they are both me. :smileyvery-happy:

I haven't either. My shop is all non-mesh. I'm not moving into mesh clothing until I can make the clothes fit the woman instead of forcing the woman to fit the clothes.

Good point, Innula. That sensor event really ought to start with sensl = []; This is one of the best reasons for using Void's convention of tagging global variables with a "g". I always do that in my own scripts, so that I don't lose track of which variables persist across events and states. I wasn't paying attention to that one.

There's nothing we can do, because we're all SL residents like you, not Lindens. And Lindens never come here. Not that it helps now, but to remember for the future: (1) Don't overuse the shopping cart. It is easily confused if you put more than a couple of things in it. I almost never use the shopping cart myself. The Buy Now button works better. (2) Don't buy things from Marketplace (especially LOTS of things) unless you are in world to receive them at the time. We each have an "in box" that holds IMs, notecards, group notices, group invitations, and anything that is delivered to us if we aren't in world at the time. That "in box" can only hold 25 things, total. If anything else comes in, it isn't saved. It is gone ... poof .... forever. If you have a mess of things delivered from Marketplace and half your friends send you notecards, that in box will be capped and you will never know what happened. Anyway ..... It sounds as if you have done the best you can so far by contacting the merchants more than once. Remember that it is summer time and people do take family vacations. Merchants get sick, have equipment failures, and have dying relatives just like you and I do. They also have in-boxes that get capped, so they might never receive the IMs and notecards you send. Still, you've been patient.. I think your best bet now is to file a support ticket at https://support.secondlife.com/create-case/ , selecting Marketplace from the pulldown menu. See if Linden Lab's staff can help.

Don't worry too much about not being able to rent land for a house. Houses are nice, but not truly necessary. I spent my first year in SL with my "home" set on top of a library building and was a nomad for at least another year. Even now, although I have a house and a skybox on my parcel, I rarely spend much time in either one. If I'm working on a project, I usually rez a temporary platform high in the sky for that. If I had to work in a sandbox instead of my parcel, that's what I would still do. Who needs a building? BTW, SL is so sparsely settled that it's never hard to find somewhere quiet to change. After a while it finally dawns on you anyway that you can change in public with no trouble at all, since you never need to take things off before you put other things on.

Yes, any of the chat-type functions will work. Some make a better choice than others, though. Distance is obviously the biggest factor. You can't llWhisper to something that's halfway across the sim, and there's no point in llShout-ing if you know that you will always be within 20m of whoever you're talking to, where llSay is the best choice. llRegionSay is a good fallback choice for communicating between objects, because it can be heard anywhere on the sim. llRegionSayTo, on the other hand, can talk to other objects or to people. In your case, I'd use llRegionSayTo for talking to an attachment, because you simply send your communication to the person who is wearing the attachment --- no need to know the attachment's UUID. If the object won't always be attached, though, llRegionSay is the better choice. You never need to know the object's UUID to make llRegionSay work.

The way to check on "known issues" is always to look at the Grid Status Reports. I just did. There are no "known issues" with the billing system right now.

It sounds like you are trying to wear an item that is stored in one of your outfits. The things there are stored as links to the actual items, which are in folders elsewhere in inventory. If those links are broken, you won't be able to werar the items that way. Try just going to the items themselves. I assume that they are in your Animations forder or maybe your Objects folder, unless you have put them somewhere else.

It's not impossible at all. What you want is llSetKeyframedMotion.

This may be one that you need to sort out with the Linden Lab billing office. If you have a non-technical issue related to billing concerns, you can call the Linden Lab billing team at the following toll-free numbers: US/Canada: 800-294-1067 France: 0805-101-490 Germany: 0800-664-5510 Japan: 0066-33-132-830 Portugal: 800-814-450 Spain: 800-300-560 UK: 0800-048-4646 Brazil: 0800-762-1132 Long distance ( not free, but you can use Skype to save some cost ) : 703-286-6277 **Note: Support is offered only in English BTW, I understood you to say that you were having trouble buying Lindens. If that's not the case, but you are receiving an error message when attempting to use your credit card or PayPal to make a Marketplace purchase, please attempt to make the purchase using Linden dollars (L$) as the payment method. To purchase additional Linden dollars to complete your purchase: On the upper-right of the page, click Buy L$ In the Linden Dollars (L$) box, enter the amount of Linden Dollars necessary to complete your purchase Click Place Order Return to the Marketplace and check out using Linden dollars as your method of payment.

Visually challenged?

Maybe the sim where you have set as Home is off line. If you can log in at other places, explore for a while ..... go shopping ..... dance....... whatever .... and try TPing to your home later in the evening.

Here are some common reasons for credit card failure: You entered the credit card number incorrectly. You did not enter the billing address or entered it incorrectly. It should be the same address that appears on your bill. You did not enter the name on the card or entered differently from how it appears on the card. The credit card is not in the list of accepted payment methods (see http://community.secondlife.com/t5/English-Knowledge-Base/Billing/ta-p/700037#Section_.3) You did not enter the CVV (3 digits on the back, or 4 digits on the front for AmEx) or entered it incorrectly. The card is expired, or the expiration date was entered incorrectly. There are no funds available on the credit card to validate it. We send a US$1.00 authorization to ensure that a credit card is valid. This is not a billing, but the card must have at least US$1.00 available on it to pass validation. Your monthly payment limit is reached, and/or your bank is not authorizing any more transactions. The issuing bank has not pre-approved transactions with Linden Research, Inc. Contact the issuing bank to resolve the problem. If you are outside the US, your card may not be set up for international/overseas transactions (this is very common with Visa Electron). 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. If none of the above applies, contact your credit card provider to determine the cause. You may also contact Linden Lab Billing Support. Often the initial agreement can't be set up due to an unverified PayPal account. To use your PayPal account with Linden Lab, it must be verified and have a credit card on file as a backup funding source. Linden Lab does not accept e-check (bank account) payments through PayPal because they cannot be processed quickly enough to match the instant delivery of virtual goods and services. Therefore, we require that you have a credit card on file with PayPal as a backup payment source.

To downgrade your premium or Concierge account to basic, follow these steps: Log into the Second Life website. On the lef side of the screen, select Premium Membership. The Change Membership Plan screen opens, displaying a chart of Membership plans and prices. Select Basic Account. Click Save Changes. Your new plan becomes effective at your next billing date. Warning: If you downgrade to a basic account, you will lose all the land you own on the Mainland, and you will no longer have access to your weekly Linden dollar stipend or live chat support. You may continue to own land in private etstates. Make sure to sell all your land before you downgrade! Check the Land Manager menu in the left sidebar of your dashboard at secondlife.com. You may also wish to check your group land contributions and make arrangements to keep your group's land holdings in good standing.

WooHoo.

That's interesting. You actually get an error message that says slvoice crashed? It's not uncommon for voice to fail. It's a flaky feature at best, but it usually fails silently. One common reason for failure is having your Maximum Bandwidth set too high (in Preferences >> Network) . Ideally, it should be no higher than 75% to 80% of your connection's measured download speed (see http://www.speedtest.net/ ). For most people, that's about 1200 to 1500 Kbps (half that if you're on DSL or wireless). If you set Maxuimum Bandwidth higher than that, your viewer will be using all available bandwidth for its basic functions. You'll have less lag, but there won't be any bandwidth left over for voice or streaming media.

Yup.

It depends in a way on how fast the lights are supposed to blink and how perfect you want the synchronization to be. The faster they blink, the harder the problem will be to solve. You might tell your master script to do llSetTimerEvent(0.1);....timer(){ if (~(llGetUnixTime() - (gTime + 1))) { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, ALL_SIDES,TRUE]); gTime = llGetUnixTime(); llRegionSay(gChan,(string)gTime); } else { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, ALL_SIDES,FALSE]); }} EDIT: Ooops.. Got this master script backward at first.. Fixed now. Then tell your slave lights to do this llListen(gChan,"","","");llSetTimerEvent(0.1);....listen(integer channel, string name, key id, string msg){ gTime = (integer msg); gBlink = TRUE;}timer(){ if (gBlink && (~(llGetUnixTime() - (gTime + 1))) { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, ALL_SIDES,TRUE]); gBlink = FALSE; } else { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT,ALL_SIDES,FALSE]); }} That should make the master and the slaves blink at exactly the same llGetUnixTime, with no more than a 0.1 second error.

That sounds very frustrating. I'd be annoyed too. Here are a few things to check .... 1. Look at the prim allowance on your land (in About Land >> Objects). If your house + furnishings + outdoor stuff are close to the maximum you are allowed, it should be impossible to rez anything else. However, there are circumstances under which rezzing too many things will force something else that was already rezzed to vanish. For example, if a griefer dumped a self-replicator object somewhere else on the sim, it could easily overload the entire sim's prim allowance and cause your things to disappear. 2. Look at the Options tab in About Land too. For maximum peace of mind, your parcel should be set to allow only you (or maybe group members) to rez things, and should only allow you or group members to bring object into the parcel. Setting those two options will prevent visitors from, say, rezzing a skybox at 3000m or lobbing grenades across the border. 3. On that same tab, check to be sure that you don't have the Autoreturn box checked or, if you do, check your objects to be sure that you were wearing the proper group tag when you rezzed them. (I can't believe how many times I have made that mistake. :smileyembarrassed: ) Incidentally, Firestorm has an option in Preferences that will force newly rezzed objects to take the correct tag for the parcel, even if you forget. It's GREAT. 3. If you are using Firestorm or Phoenix, which let you maintain an asset blacklist, check the blacklist to be sure that you haven't accidentally derendered your house. The other way to check is to ask a friend or your alt if they can see your house when you can't. 4. If you are using Firestorm or any other viewer that has an Area Search feature, use it to look for your missing objects. They may still be on the sim but not where they belong. That begs the question of how they might have moved, but at least you'd be able to find them. I'm sure there are other possibilities too, but these are the first ones that pop to my mind.

Actually, even the corrected sensor event that I just gave you contains a flaw. If the detected name is more than 24 characters long, it is truncated before it's stored in sensl. If the same name is encountered a second time, the long version is compared against the truncated version. The two obviously won't match, so the truncated name will be added again .... and again... and again.... What you really want is sensor(integer num_detected) { integer i; string name; for(i=0;i<num_detected;i++) { name = llDetectedName(i); if(llStringLength(name) >24)//if name characters are greater that 24 { name = llGetSubString(name,0,23); } if (!~llListFindList(sensl,[name])) { sensl += [name]; } } } BTW, I assume you know that the sensor event will only detect the 16 closest avatars that are within its range. .

Exactly. But your sensl list is never being loaded correctly because your sensor event is all messed up. When you have a problem like this, the best way to see what's going on is to pepper your script with strategically placed llOwnerSay commands. Try asking llOwnerSay(llList2CSV(sensl)) at the end of the sensor event and then again in the listen event.

LOL... The OP knew that in the beginning. He said... "Now as far as i can see you could only do this by checking the persons ip address which i think would be in breach of terms of use so i dont think il bother with it. Any ways i thought i would ask on here if there was any other way like get data ...."

Well, that's what you told the script to do. Your listen event says ... 1. If the message is "Add", create a new Dialog 2. If the message is anything else (like "Remove"), check to see if it is already on the list called sensl. 3. If the message is not on the list called sensl, add it to the list called accessl, and let me know. So that explains why the word "Remove" is added to the list. So why aren't any of the detected names added? Look back at the sensor event. The entire for loop is being ignored because there are no curly brackets around its scope. The sensor event should be written sensor(integer num_detected) { integer i; string name; for(i=0;i<num_detected;i++) { if (!~llListFindList(sensl,[llDetectedName(i)])) { name = llDetectedName(i); if(llStringLength(name) >24)//if name characters are greater that 24 { name = llGetSubString(name,0,23); } sensl += [name]; } } } The way it's written now, no names are being added to the sensl list at all. EDIT: It would help if I could write something without making typos. Sheesh. Fixed.