Wulfie Reanimator

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.

You can select the bigger skybox and the smaller skybox will block the selection tool. And if you are in the skybox, anybody can just double-click your name in the People window and have their camera zoom its way into your skybox...

I haven't done it myself so I can't give you the exact details, but if you're using Blender, look up "Transfer UVs" and/or the Data Transfer modifier. Essentially, you'll want to select your target first, then the source, press Ctrl L, and Transfer UV Maps. I don't know what that function considers during the transfer.

Comments don't affect script performance in any way. They're never included in the compiled code. Unused code doesn't affect script performance either, besides adding to the total memory use of the script.

Just nuke the Earth.

Totally off-topic but.. I lost the chat logs of my 6 first years on SL when I swapped computers and didn't think about it at the time and just formatted everything. I'd pay the original price of that old computer just to recover the hard drive. Chat logs / screenshots are super important memorabilia to me, kinda like physical photographs were to older people.

The short and simple answer is "you can't." That said, there are a couple ways to do it. You either increase the value of RC_MAX_HITS and check each hit separately, or you keep it at 1 and create new rays for every hit that isn't eligible, either from where the previous ray ended or with some additional offset.

They almost did this already with the "Custom Avatar Brand" field. Weird that they wouldn't go all the way and let us link to products directly.

Faces are always single-sided in SL. You will need to duplicate the walls and "flip normals" so they face the other way. You can enable "backface culling" in Blender to see the same effect.

Which isn't allowed.

The LSL Preprocessor doesn't exactly "make your code better," definitely not faster. In fact it arguably does some damage for those who aren't using that feature. What it does optimize is unused code, which it removes. What it also does but shouldn't, is remove comments. (Meaning anyone not using the preprocessor won't see them.) The Preprocessor is a text-replacer, essentially. Its main features are #include to import code from your computer, and #define to create "immutable constants" rather than variables. It does also provide some quality of life things like lazy lists, but I recall it having its own set of edge-cases. For example, this is what the post-processed code looks like: //start_unprocessed_text /*string unused = "Goodbye, World!"; default { state_entry() { /|/ This is a comment! llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); } } */ //end_unprocessed_text //nfo_preprocessor_version 0 //program_version Firestorm-Releasex64 6.3.2.58052 - Wulfie Reanimator //last_compiled 05/02/2020 05:34:16 //mono default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); } } And if you are using the Preprocessor, the unprocessed code is in a separate tab from the post-processed one.

The size of the notecard window depends on the size it was when last closed, same with most other windows. Trying to create your own format inside the notecard (indentation, ASCII art, borders) is an exercise in futility since different viewers/users can use different fonts and font sizes, causing massive discrepancies in what they see.

Hi! Not really possible, we don't have volumetric cast functions like box-cast or sphere-cast. The ray from llCastRay is infinitely thin, it has literally no thickness. It's just a mathematical line/intersection. However, you can remedy that by using multiple parallel raycasts. It's not perfect, but it's usually good enough, depending on your expected target. You should not offset the rays more than the minimum width of whatever you want to hit, which isn't always an easy answer.