Rolig Loon

That's what the script does.

Pardon me for responding. We get variations of this question quite often, usually from people who are new to SL and do not know as much as you evidently do. It's easier to explain than to guess at what you might already know. No, you are wrong there. It has nothing to do with your credits score (mine is excellent, BTW) or with how well PayPal works for buying things on other on-line sites. Linden Lab requires that a payment method be capable of (1) sending and receiving funds and (2) doing it instantly. You may certainly use PayPal as a payment method but if you do, you must always have sufficient cash balance in the PayPal account to cover purchases. Failing to do that is a very common reason for the Lab to cancel the transaction. If your PayPal account is backed up by a credit card, it is generally (but not always) backfilled very quickly, so it meets criterion #2 above. If it is backed up by a bank account, it generally takes the bank up to two days to backfill PayPal. Linden Lab will not wait for two days, so your transaction will fail criterion #2. This happens to SL residents often enough that it's one of the first things we are careful to point out when we get a question like the one you posed.

No, it's the number of that link. And SLPPF is llSetLinkPrimitiveParamsFast. if you don't already know the number of each link, then you can ask the script to find it as it starts, provided that you have named the links appropriately. For example, if you have named them "Star" and "Heart" (nice logical choices), then you could add lines in the state_entry event like: integer i; while ( i < llGetNumberOfPrims() ) { string strName = llGetLinkName(i); if ( strName == "Star" ) { link_number_of_the_star = i; } else if ( strName == "Heart" ) { link_number_of_the_heart = i; } } and then be sure to make link_number_of_the_star and link_number_of_the_heart global variables, just like iON is now.

A Premium account should renew automatically. That's right in the TOS (LL TOS, Sect. 4.3). If it doesn't happen because of a "Problem with your account...", the problem is often that the system either no longer recognizes your payment method or your payment method does not have enough money in it to cover the changes. First thing, open your dashboard and look at Account >>> Billing Infprmation In the part that I highlighted, if it doesn't already say "Land, premium, and other recurring fees", click Change and adjust it. Otherwise, you haven't authorized Linden Lab to use that payment method for paying your Premium bills. You may have authorized it to buy L$ or something else ... Then, be sure that your payment method is really PayPal or a credit card, not a debit card or a pre-paid card of some kind. Almost all prepaid cards and debit cards will fail. So, replace it if that's the case. Finally, if you are using PayPal, be sure that the cash balance in your PayPal account is at least large enough to pay the charges from LL. Your bank or credit card will not backfill PayPal fast enough to satisfy Linden Lab. They want payment now, not two days from now when the bank gets around to transferring cash to PayPal.

If the star and the heart are linked in the same object, all you need to do is put a SLPPF command in a timer and turn the effect on/off in successive steps in the cycle. So, something like: integer iON; default { state_entry() { llSetTimerEvent(3.0); llSetLinkPrimitiveParamsFast(LINK_SET,[34,link_number_of_the_star,PRIM_FULLBRIGHT, ALL_SIDES, iON, PRIM_GLOW, ALL_SIDES, 0.05*iON, 34,link_number_of_the_heart,PRIM_FULLBRIGHT, ALL_SIDES, iON, PRIM_GLOW, ALL_SIDES, 0.05*iON]); } timer() { iON = !iON; llSetLinkPrimitiveParamsFast(LINK_SET,[34,link_number_of_the_star,PRIM_FULLBRIGHT, ALL_SIDES, iON, PRIM_GLOW, ALL_SIDES, 0.05*iON, 34,link_number_of_the_heart,PRIM_FULLBRIGHT, ALL_SIDES, iON, PRIM_GLOW, ALL_SIDES, 0.05*iON]); } } assuming that you know the link numbers of the star and the heart, which you need to replace above. You can of course adjust the timer and the intensity of the glow as you wish. As usual, any scripts posted as part of responses in this forum should be understood to be examples, not necessarily optimized or tested in world.

Also, to be clear, I didn't think that you were suggesting that the OP should break the law either. I wanted to be sure that he understood that he shouldn't take your question that way.

I hope not. I mean, the fact that you can appear to be in an embargoed state by virtue of using a ISP in one seems to imply that you can do the reverse. If a VPN lets you skirt the laws in your own state, though, then you are clearly doing something illegal. If the authorities catch you, they won't be happy. I don't sympathize much either.

Certainly. Go for it.

Tom Lehrer was always one of my favorites, and the Vatican Rag was one of his best. Thanks, Maddy.

If you Internet Service Provider is in a state that does not allow on-line gaming, then it's the same as if you lived there yourself. Connecting to SL with an ISP in a different state puts you in a mess of legal jurisdictions.

If that is all that you want to do, you don't need any script at all. All that you need to do is put your object into a prim box and set the properties of the box to sell its contents. Read this Knowledge Base article You can make your box as simple as you like, or you can put a texture on the outside -- perhaps a photo of the thing that you are selling. Once you have set its properties, the box is a vendor, the simplest, easiest vendor you can make. I suggest practicing a bit before you set a vendor out for other people to use. Follow the instructions in that article, make a vendor, and have your alt or a friend test it to see that you have done it right.

The Debug Setting RememberPassword if designed to Keep password (in encrypted form) for next login. It's set to TRUE by default but you can set it to FALSE so that it forces you to type the password manually each time. It looks like the Debug Setting AutoLogin is supposed to default to FALSE. If yours isn't. you can set it to FALSE so that your viewer should not login automatically using your last username/password combination. As far as I can see, though, there's no setting to leave the login name field \blank. The best you can do, as Sasy suggests, is to pretend to log in and type nonsense in that field so that the last name it saves will not be yours.

Horse party!

I am very pleased with my Realistek Appaloosa stallion. He's the horse I have been riding on some of my travelogue wanderings in Bellisseria this summer. It took me a little while to figure out which features work on the worn version rather than the rezzed version (or vice versa), but I've used both successfully. When I'm not riding, he grazes peacefully on my region. He's a fine traveling companion. He even has a nice whinny. Someday I really have to name him.

It's mildly complicated but, as with each of the other topics you have asked about, I'm sure that you can work through the logic. Here's the basic challenge: You want to create a list of people who are allowed to do stuff with your script (open doors, teleport, get gifts,... whatever your script does... ). So, you need to create a global list variable to put the names (or UUIDs) in. Then you need a way to add names. For that, you need to have a way for the user to open a Text Box (with llTextBox), so use one of your dialog buttons to open it. Then tell your listen event what to do with whatever the user types in the text box >>> add it to your global list. That's all there is to it, except .... What if the user wants to remove a name from the list? What if the user tries to add the same name twice? What if the user types a name that does not exist or is not a username? Again, I'm sure that you can work through the logic of questions like this, but here are some things to think about: 1. You can easily set a flag during the action that opens a text box, and then use that flag to tell the listen event whether it's hearing a name that is supposed to be added or one that is supposed to be removed. If it's a name to remove, you'll need to find it in the list and then use llDeleteSubList. 2. You can use llListFindList to see whether any particular entry is already in a list you have created. 3. You can use llRequestUserKey to see whether the UUID associated with a name is a real avatar UUID or is NULL_KEY. And so on. The basic business of creating the list isn't the hard part. It's the tests that you have to include to detect when the user has tried to do something impossible or unexpected. Then once you have the list, all you need to do is look to see if llDetectedName(0) is on it. If so, the user is allowed to proceed.

As much as I truly love what's going on in Bellisseria, I haven't been moved to upgrade to Premium yet. That's a puzzling reaction, as I think about it, but I think I understand better now that the camping trailers have appeared. I love being outdoors. Decorating indoors has never held much appeal for me, because indoors is just a place for sleeping and eating. When I take RL vacations in RL, I head for the countryside (Scotland, Croatia, the Canadian maritimes, Iceland ... ). When I'm at home, I look forward to taking a long walk in the woods or around a nearby lake. I'm finding great joy in wandering around Bellisseria and seeing the landscape, just as I do in RL. The camping regions are stunning, the best I have seen yet! If I were exploring a RL place like this, even at my advanced age, I would grab a tent and a sleeping bag and hike off into the hills. The trailers are wonderful. I just don't want to live in one. I get more than enough enjoyment by visiting. 😊

How about this ...... If you open your mini-map as you wander around watery regions, you will occasionally see dark areas in the water. Small dark things are likely just a rock or a sunken rowboat. If you see a BIG dark area, though, it's a structure of some kind. Mermaids love to hide things in underwater structures. It turns out that there really aren't a lot of them in Bellisseria. You just have to spend some time exploring. Even if you don't find the hunt prize, you will find other cool stuff. That's at least partly why Patch is doing the hunt anyway. That's also why I have been sharing travelogues of some of my explorations in the Linden Homes Photo Thread (aside from the fact that I am having fun).

I'm late to the party. As you can see from the posts above mine, you will get a range of opinions on almost any question that you ask. In the end, you'll just have to decide for yourself. Check out possible spots on the mainland to see what the neighborhoods are like. Check rental prices and covenants on private estates too. As a Basic member, I can rent anywhere, so I never felt a great need to upgrade to Premium just to have a spot for a shop. Over the years, I rented shop space on several regions on the mainland and in private estates and was happy in all of them. Now that I am selling only through Marketplace and own my own estate, it's no longer an issue for me. If you're considering an upgrade yourself, I think you'll find that other Premium benefits (like the sandbox, the weekly stipend, the access to Live Chat, and the Premium gifts) are likely to be more important than the ability to buy land on the mainland --- unless you plan to live there or in a Linden Home.

So, get a wearable Bento horse like mine.

It's a bit obscure (but probably not to people who live in graphics world). The limits page that I referenced above says Aspect ratios of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000: which implies to me that the "native" aspect ratio is the ratio that customarily appears on your own monitor and it also what your viewer presents as long as you haven't messed with UI size. In other words, the "native" aspect ratio is the aspect ratio that anyone ought to see on their own monitor unless they have monkeyed with it by stretching the image.

Justice Ginsburg

I've never heard of a limit on how close you can cam to an avatar. In my 12 years here, I have always been able to cam inside avs, just as Qie has. It's not something I do every day, but it's useful when you're trying to help someone find a lost piece of jewelry.

And you said that you weren't a scripter! This is how we all begin. A small challenge pokes us into trying something, and it works. I should warn you ... once the bug bites, there's no turning back. Scripting is like doing crossword puzzles or whatever your favorite puzzle is. It's addictive, and very rewarding. Keep at it. As you get stuck on whatever you are working on, feel free to bring it here to share. This forum is a place for scripters to share insights and to commiserate about things that aren't quite working right yet.

A system like that comes with a well-written set of instructions for doing all sorts of magic. If you follow instructions, it's not hard at all. If you are setting up a handful of vendors in a single shop, a system like that may be more fancy (and more expensive) than you need. If that's the case, if I were you, I would look instead for a smaller system that cannot make refunds.

Yes, I agree. If you were a scripter, you could do just that. This particular script is a very simple, bare bones script that could be modified in lots of ways, including managing several doors. So, you have a choice. You could either figure out how to change it yourself -- not a terribly difficult job -- or you could hire a scripter to do it for you. Or, you could just go ahead and use two separate copies of this script, one in each door. Frankly, the small inefficiency of using two scripts is almost negligible, and that's by far the easiest option you have. If you were scripting an entire house full of doors, I'd think abut the modification.