Wulfie Reanimator

I assume it means that W should be always positive or always negative. If the values you're plugging in can be of either sign, the results may be undefined.

The biggest problem with the actual implementation is that you're seemingly doing fixed steps per timer event, instead of calculating what the scale should be whenever the timer is triggered. This causes the problem of having the effect change pace as the rate of events fluctuates. Since you're going for a smooth in-out motion, you could give llGetTime (multiplied by BPM) to llSin or llCos, since sine/cosine are wave-functions. This would allow you to use much fewer updates while preserving that consistent rate.

Sounds like you're already living the teen experience. Just wear what you want, don't let the "adults" tell you how you should look.

Sad to see you go, but I'm happy for you.

Scripts can easily access the display name of an avatar. (GetDisplayName/RequestDisplayName) The reason why most scripts don't do that is probably because a lot of scripts were made before display names were a thing, or because it just hasn't become as much of a norm yet, or because getting the display name can sometimes fail (a username is always reliable), or the scripter prefers usernames. The fancy characters used in display names are not an issue for scripts.

Yep, I understood that from the first picture. HUDs are still made up of prims/objects, which is what hovertext is attached to.

Yeah, the character count is the biggest limitation. Having it show more info (or more names in general) would require something a bit more complicated with multiple prims set up in a specific way, which is harder to share here on the forum. I might make a more complete version (it's not difficult, just tedious), but I can't promise anything right now.

There's no significantly practical reason to publicly announce which accounts have payment info on file. It just paints a target on those accounts, especially when we still can't have two-factor authentication. The existing features relating to avatar entry don't rely on that information being public to anyone.

That's fair. Sorry it took a while, I got distracted with other stuff and fell asleep: The script below will show as many closest avatars as will fit in the hovertext (254 characters) and they'll be in the format "Wulfie Reanimator (12m)". default { state_entry() { llSetTimerEvent(5); } timer() { list avatars = llGetAgentList(AGENT_LIST_REGION, []); integer list_length = llGetListLength(avatars); list sorted_avatars; key avatar_key; vector avatar_position; integer avatar_distance; vector my_position = llGetPos(); key my_key = llGetOwner(); // Calculate the distance for each avatar in the sim. // Add them into a list in the format [distance, name] integer i; for (i = 0; i < list_length; ++i) { avatar_key = llList2Key(avatars, i); if (avatar_key != my_key) { avatar_position = llList2Vector(llGetObjectDetails(avatar_key, (list)OBJECT_POS), 0); avatar_distance = llCeil(llVecDist(my_position, avatar_position)); sorted_avatars += [avatar_distance, llKey2Name(avatar_key)]; } } // Actually sort the avatars. sorted_avatars = llListSort(sorted_avatars, 2, TRUE); list_length = llGetListLength(sorted_avatars); string display; string new_line; string avatar_name; // Create a string for each avatar. // If the string doesn't exceed the max length of llSetText, // add the avatar to the final display-string. for (i = 0; i < list_length; i += 2) { avatar_distance = llList2Integer(sorted_avatars, i); avatar_name = llList2String(sorted_avatars, i + 1); new_line = avatar_name + " (" + (string)avatar_distance + "m)"; if (llStringLength(display) + llStringLength(new_line) <= 254) { display += new_line + "\n"; } else { jump loop_end; } } @loop_end; // Show the final list of avatars. llSetText(display, <1,1,1>, 1); } }

Why do you need a scripted radar? Most if not all viewers have one built-in. I can post a script that does exactly what you showed in a little bit, I'm just curious about why.

Are we going to ignore "banal", "not healthy", "haunted", "survive someone else's success", "count the money in your own pocket", "nervously bite your lip"?

I'm trying really hard not to spend on impulse...

While the caveat is true, your script is so simple that having that check is unnecessary. There are no adverse effects if, for example, the detach event doesn't start until the object is reattached again. In that situation, the first attach event would show the toenails, and the second attach event would immediately hide them again. As to what the problem is, Lucia had it right. The message is sent during detach. The sending object disappears. The receiving object gets a listen event. The receiving object checks: llGetOwnerkey(id) == llGetOwner() http://wiki.secondlife.com/wiki/LlGetOwnerKey#Caveats id doesn't exist (because that object was detached), so llGetOwnerKey returns id instead of the owner's key. The check fails and the toenails don't react. I don't think this is something you can fix without access to the body's scripts.

I understand the point you're making but I don't think you're wording it in a way that is easy for others to understand, without them having to unnecessarily challenge your perspective because they lack context.

Scripts cannot play gestures, unfortunately.

At the bottom of the script, remove the "hide_me();" line.

This is just plain not true. You're gonna have to be a lot more specific about what you mean by "all software" or "all menu entries." Show some examples. We can talk about anything from games to editors to websites to the computer operating system you're currently using. All of them try to show you only what's relevant, some with more success than others.

That's going to be a fundamental disagreement then. Everything I know about design (non-professionally) leads me to conclude that if a common feature is hidden behind several layers of menus, or placed somewhere that isn't immediately obvious, it's bad design. That said, it's a balancing act. There isn't a perfect interface. You have to make decisions between screen real-estate, organization, and complexity. It's also pretty difficult for me to evaluate an interface I've used for a decade. Most things feel like they're "just fine" because they've become basically muscle memory, combined with prior knowledge. Even the awful interface of BDO isn't "that bad" because I know where to find things, but because I haven't spent nearly as much time getting familiar with every part of it as I have with SL, it's a lot easier to put a finger on all of its issues. But I still feel like the SL interface could be improved in a lot of ways and some of the lesser-used functions should be placed somewhere else. For example, going back to the Wear/Replace idea, here's a little mock-up of how I might change the UI: (And just to clarify, I don't think this is the most egregious offender. It's just an easy example in the wider context.) "Add" is renamed to "Wear" - adding an attachment to your avatar is now the default behavior. There is an alternative option to "Replace" other attachments in the current slot, based on context. The right-click menu would become something like this: Only the Wear option is shown, but when you hover over that option and the wearable is not a system layer, a sub-menu pops out with the Replace option. This de-clutters the main context menu while preserving both options in a meaningful way. Speaking of context menu clutter, it bafflingly shows you options that cannot be used. It's a context menu, it should only show you choices relevant to what can be done based on whatever you clicked on. You already get different options based on the asset, why not remove things like "Copy Asset UUID" or "Edit" or those "Marketplace Listing" choices when clearly the viewer knows they're not usable?

There are a lot of weird characters in a lot of stories. Having a weird voice is an asset.

I agree with this in principle; gamifying anything is provably more engaging for the user. But there is a concern of whether this could set them up with false expectations. Maybe that's still better than the current situation, I couldn't say. I don't think BDO is a good example of "clean menus" or "not overloading the user with information." I've played BDO a few times since its release (and actively playing it today), but I dislike almost everything about the UI. I think it's messy (lots of stuff on your screen at once), confusing to navigate (menus all over the screen, duplicate buttons/information), and shows you information you don't need while hiding information you want. I unironically think SL has a cleaner interface than BDO, even if it's still bad. Simplified, modernized, or dumbed down is good. If it doesn't need to be as complicated as it is, it shouldn't be. As a small example, we have two buttons for wearing -- Wear and Add -- but the former has very little use these days. There's rarely a want to replace other things in the same attachment point, especially when you're wearing rigged mesh. There aren't enough attachment points to logically put everything you're wearing on its own unique slot without overlap, never mind that many creators just use the default "right hand" attachment. (And don't get me started on the hot garbage that is the "select attachment point" menu.) The distinction between these features is almost entirely unnecessary and could be removed/combined into one action. There are a lot of people who don't even understand the distinction, or choose not to think about it and just always use Add. Regarding the outfit folders images, they should be able to be tied to local files on the computer, not in-world assets. No one else is ever going to see your outfit folder images, because there simply isn't a way to do so.

Truer words have never been spoken.

This is not the experience for the vast majority of people. The forums would talk about nothing else if that was true.

Animations can't be modified after upload, regardless of permissions. Those posers you're talking about are playing separate animations with higher priority. But yeah, the problem OP is having is tough to guess if "nothing has changed." It could be any attachment, any recent furniture or dance ball, a stopped animation, etc.

When you want to compare two things to see if they're equal, you need to use == as you did in the if-condition. When you want to set (assign) a value, you need to use =. You changed too much, you don't want those two last lines to be comparisons.

Random thought; would it be possible viable to use a separate object (the same size as the character collider) and for example llMoveToTarget to test for collisions in a more "volumetric" way? And then if there is a collision, optionally do a raycast towards the collision point to check if it's just a small incline on the floor.