Wulfie Reanimator

Regarding the title and "so that it can go off my private region," I don't think what you're asking is particularly possible, if it is what I think it is. Objects can't leave the boundaries of a region, with some caveats. The root of an object must be inside of region boundaries, but individual links can go beyond. A vehicle could theoretically get about 64 meters outside the region boundaries if it was scripted in a very specific way, but I don't think that kind of technique is something that would be even remotely easy (or brief) to explain to a beginner.

Not possible.

What you see or experience as an end-user is no testament to what the script is actually doing. You are literally oblivious. Refer to the script I provided above.

Trust me, I know very well how to write the scripts for the things you're talking about. I'm very experienced with LSL with a long history of helping others here and in-world. Did you check the page I linked earlier? Here it is again: http://wiki.secondlife.com/wiki/LlRequestPermissions I'm starting to run out of ideas on how to communicate this to you any more clearly than I've already tried. Scripts have to request permissions for a lot of things or they will shout errors at you. Most permissions are granted automatically under certain circumstances: Attachments will automatically get permissions to: Replace animations (walking, standing, jumping, etc.) Detach themselves from the avatar Objects that you're sitting on OR wearing will automatically get permissions to: Know where your camera is Control your camera Take control of your movement keys and keep track of them Start and stop animations (dance balls, shopping bags, furniture, vehicles, weapons, etc.) "Automatically" means that you won't see a dialog asking for permission. When the script makes a request with llRequestPermissions, the script will just instantly get the permissions it asked for without you even knowing that it tried to ask for it. For example, the "start animation on attach, stop on detach" script is basically this: default { on_rez(integer start_param) { llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION); } run_time_permissions(integer permissions) { if (permissions) { llOwnerSay("I was given permissions!"); } else { llOwnerSay("Why are you mean to me?"); } } } If you put that script into a box and then wear the box, you'll see what happens. If you then detach the box and rez it on the ground, you'll see that something different happens. (Note to other scripters: I wrote it the way I did intentionally.) Edit: @KT Kingsley, there are some cases where an animation will get stuck during detach but I don't know off the top of my head what those cases are. I also know there's limited time during detach but certainly enough to stop at least one animation. (In my experience you get about 4 function calls' worth of time, not exact of course.)

I would love to see an example of your script that plays an animation without requesting permissions. I would also love to see a case where an animation stops when the attachment is taken off without the script doing that explicitly. The distinction is that vendors and tip jars don't "take" money. You "give" money, as in, the transaction is initiated by your viewer and not by any script. There are only two functions that can "take" money from you. llTransferLindenDollars and llGiveMoney (which is an older version of llTransferLindenDollars). They both have "scary" warnings because they can initiate transactions on their own at any time, as many times as they want, after the script has been given permission to do it once. That is a real concern no matter how useful those functions are. The bottom line is that as things are right now, what you're suggesting is impossible. Whether or not something new could be suggested is another conversation, but I don't think you'll find many people voting for automatic debit-permissions.

Permission to animate an avatar is automatically granted if the request is coming from an object that is attached to the target avatar. The request still needs to be done. If you rez your object on the ground instead of attaching it, you'll see the permission dialog (unless the script is written smartly in such a way that it won't try to request permissions if it's rezzed.. in which case it won't animate you either). Many permissions are granted automatically if the target is sitting on the requesting object, or has it attached. See this page. You being able to pay an object is completely different from the object taking money from you. They're like the opposite lanes of a highway. You definitely shouldn't confuse the two.

Quoting myself as well because I can't edit that post anymore. I'm not sure why I didn't realize this at the time but the rez solution has the same ownership problem as the demo/HUD. The rezzing has to be done by you, so you'd be the owner. So if you pay the vendor... you get your own money.

It looks like either your texture has an alpha channel (most likely, based on the screenshots), or your face normals are pointing the wrong way. To fix the alpha issue, edit your object, go into the Texture tab, and set "Alpha mode" to "None." To fix the face normals, look up "flip normals", "recalculate normals" or "fix normals" for Blender. Another question, how many triangles is your object?

The algorithm for sorting places is not always by traffic alone. The Websearch defaults to "relevance" which could be anything as far as I can tell: I'd show the legacy search for comparison but the results are quite wild. Well, if your goal is to meet people, the first place to look for most people is not low-traffic sims. It's a rich-get-richer type of thing from the average users. And ironically the ones that are "hidden away" are by far the easiest to find and instantly identify. This trend of "afk" hangouts makes it basically impossible to identify traffic bots in plain sight. Even real people use text viewers so they can afk more efficiently. Regarding the enforcement of traffic bots, it seems pretty hit-and-miss. I've noticed a handful of places get cleaned up a few days after my reports (I used to hunt for bots for entertainment), but I don't know whether that was because of reports or because nobody else actually visited the places and they just shut down. There are certainly some big places that have been around for a very long time that just don't seem to get touched at all. There's literally nothing that couldn't be faked by a bot. You can create artificial keyboard inputs and mouse movements, it's not worth chasing that goose when the viewers are open-source. Ideally, traffic would be changed to "activity" and it would take all aspects of what avatars can do into account, maybe with slight weights on things that promote social interaction the most, but that's probably not as important as it's very subjective. An avatar that does nothing should not count towards activity.

People won't stop selling skins though. Even if appliers go away, people will sell system skins at the same price. I don't think appliers will go away anytime soon, especially for backwards-compatibility, but still.

When it comes to appliers for a specific body, that's the ideal case because it means the texture is probably made with a template of that specific body. When it comes to "universal" appliers like Omega, there's only downsides compared to BOM. Omega does not make the textures universal, the only thing special about Omega is that it can talk to multiple bodies at once. The textures were still made with some specific template -- either a specific mesh body or just the base LL body. The texture will only match one body as perfectly as the creator made it, while the others will have at least minor defects. An easy example if you have Maitreya and Belleza bodies: Get your Omega applier and apply it to both bodies, then look at the toes. TLDR: Omega will die to BOM.

You are. You clicked the HUD to apply a skin texture. That overrides BOM. This is a mistake.

BOM stands for "Avatar Bakes On Mesh." The Avatar is silent. "Bakes" refer to the "baked" or "combined" textures on your base LL body. If you want to use BOM, you can't use any texture appliers on your mesh body's skin. You must use system layers to alter the look of your avatar's skin (and tattoos, etc).

Sure, you can charge how ever much you want for what ever you want. 300-600L for a shape is whatever. However, I question the people who buy shapes and/or complain that they don't look right on a body the shape wasn't created with.

The rezzable vendor would work without problems. The crux of the issue is that if it's attached to an avatar, you cannot pay it. As long as it's not a HUD (or worn on your foot or whatever), there are no issues.

Okay, let's go with hypotheticals. Hypothetically speaking, let's say there was a way to wear a HUD that was owned by someone else (like you). How am I supposed to be able to make a purchase through this HUD? I can't pay an attachment. The attachment cannot charge me. Edit: (Also yes, temp-attached things change ownership.)

llMessageLinked takes a parameter link, which determines which link(s) in a linkset will receive the message/event. LINK_ALL_OTHERS means all links except the one this script is in. It's not the same as LINK_SET (all links) or LINK_ALL_CHILDREN (all links except root). I point this out because "the rest of the linkset" depends on a lot of things.

Since the question specifies "objects in a linkset" and "a linkset of two objects," I assume this is a linkset and not two separate objects? If that's the case, you shouldn't be using RegionSay, but llMessageLinked and the link_message event.

The fastest way to learn is to be wrong. It's how I like to learn.

Your PC is not the problem. It's 100% the viewer's fault in this case. You don't have to uninstall the SL viewer before you try the other ones. The texture memory setting can be found here in Firestorm:

Sorry but no. https://puu.sh/FG46v/972b3ae121.mp4

The main issue is texture memory usage in the area you're in. The SL viewer allows 512 MB of texture memory. When your texture memory gets full, the viewer starts discarding textures to reduce the memory usage. Then it tries to load up more textures because it has free memory... and then memory gets full and it has to discard... repeat on and on. It's a common bug that has existed for a long time, I don't think there's a permanent fix for it until the viewers fix it. Lowering your draw distance definitely helps since there will be less textures on screen. You might also use another viewer (like Firestorm) which allows 1024 MB of texture memory.

Teach me, you beautiful person, you.

Your whole post was really hard to follow for some reason, so I'll just quote this part (which is also confusing to read). Objects can't receive lindens. When you pay a tip jar, it goes straight to the owner's account. These days the owner of the tip jar is generally the owner of the club. In order for there to be a split, the script needs permission to transfer lindens from the owner of the object so that whatever cut can be sent back to the person who is currently using the tip jar. Contest boards are no different. The contest board cannot pay the reward unless it has permission to transfer lindens from the owner. It would otherwise have to be done manually. You can't initiate a purchase without right-clicking and selecting Pay (which can't be done on attachments), or having the script do that for you. It's just literally not possible. llRequestPermissions(someone sad, PERMISSION_DEBIT); while (permissions) { llGiveMoney(someone happy, 1); } Redelivery and "receiving a random prize from a HUD you bought on the Marketplace" are completely different from what you're suggesting. No money is involved because the payment was already made. These two things are simply implemented with a server (in-world or off-world) that is contacted about the redelivery/prize request, the server "does its thing" and you get the item. In the case of gacha or "one-use" items, the server keeps track of the objects it has already sent the prize to. Gift cards should never need debit permissions. They don't need to deal in lindens at all. A gift card should just be a scripted object that you either purchase (or get for free) that tracks the amount of imaginary "credit" it has. It works by communicating directly with the vendor you're about to buy from. That vendor can either be a "gift card recharger" which you pay yourself before it tells your gift card it has more credit, or that vendor can also just be a regular product vendor that is pre-programmed to understand and accept that gift card and its credits. The gift cards that complete the rest of the transaction from your funds when there aren't enough credits is a nice quality-of-life feature, but I would instead make a way for those imaginary credits be refundable back to real linden. This is a bad idea, because objects can be copied out of the object's inventory even if the object is no-modify.