Wulfie Reanimator

I think you're mixing up correlation and causation. The documentation says that llDialog will shout an error "if any button's length is longer than 24 bytes." It's not a problem if the button name is too long to be displayed visually.. it just can't reach 25 bytes. The first page might work perfectly fine if a person with a long name isn't on that page (even if they are on sim). When you move to the next page and a new list of buttons is generated (with the long name), the error is shouted.

The error message is referring to the content of the button text. Avatar names can be longer than 24 characters, so you can't use them directly. There's a few general ways to work around it, but they're all a bit complicated to implement. In short, either you always take the first 24 characters of the avatar name and use that, or you use indexes for the button labels. The first method can make things more complicated when processing the button choice, and the second method requires you to display a list that correlates each index to avatar names.

We need more information. Have you tried getting a new copy of the body, or does this happen out-of-the-box? Where did the bump-map come from? Did you apply it? Did you buy it or make it? If you made it, what are you trying to achieve and how did you make it?

For what it's worth, avatars wearing less attachments (especially with less parts) won't cause as big of a delay. My main avatar doesn't get any freezing when I right-click myself, but I use a Kemono with a couple one-piece-mesh attachments, so there's not many bounding boxes to check. My other mesh bodies (Maitreya, Belleza, etc.) cause a delay even when I'm basically naked. The "delay" in this case is the whole viewer freezing, not just input latency.

I tested this, and yeah, looks like the look_at parameter is always a position the avatar will be facing toward. So if your landmark is at <100,100,100> and you want to look North (positive Y), look_at should be <100,105,100>. If you used <0,1,0>, you would face the South-West corner. The same applies if no landmark is used and the teleport is only within the local sim. Wiki could use an update, I'll probably do it tomorrow night.

To answer the main point of OP's request, here you go. I added a global variable called active near the top, and its value is toggled between true/false in the touch_start event. I also added a check for the UUID's value so the camera doesn't move to <0,0,0> if it's active before a target is set. key uuid = ""; float timer_rate = 0.022; integer active = TRUE; integer listen_handle; default { on_rez(integer param) { llResetScript();//By resetting the script on rez forces the listen to re-register. } state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_CONTROL_CAMERA); listen_handle = llListen(166, "", "", ""); llRegionSay(166, "UUIDRequest"); } run_time_permissions(integer perm) { if (active && uuid != "") { llSetTimerEvent(timer_rate); } } timer() { // Get the remote object's position and rotation. list data = llGetObjectDetails(uuid, [OBJECT_POS, OBJECT_ROT]); vector pos = llList2Vector(data, 0); rotation rot = llList2Rot(data, 1); rotation rot90Z = llEuler2Rot(<0, 90, -270>*DEG_TO_RAD); rot = rot * rot90Z; llSetCameraParams([ // Begin controlling the camera and prevent it from being moved. // (Alt-cam will still override this.) CAMERA_ACTIVE, TRUE, CAMERA_FOCUS_LOCKED, TRUE, CAMERA_POSITION_LOCKED, TRUE, CAMERA_FOCUS, pos, // The position the camera will LOOK at. CAMERA_POSITION, pos + (< -1.0, 0.1, -0.1> * rot) // The position the camera will BE at. ]); } touch_start(integer n) { active = !active; if (active && uuid != "") { llSetTimerEvent(timer_rate); } else { llClearCameraParams(); llSetTimerEvent(0); } } listen(integer channel, string name, key id, string msg) // Listens to and services all menu buttons. { if (channel == 166 && msg == "UUIDRequest-Back") { uuid = (key)id; llOwnerSay("Receiving UUID = " + (string)msg); } } } I'm not sure why it would only work "in an object rezzed nearby" when the camera control function is restricted to only work in attachments or seats. It worked as a HUD even before I made any changes to the script. P.S. I missed the second problem about the camera's position. The reason why the camera isn't acting as the drone's POV is because CAMERA_POSITION has an offset from the drone, and CAMERA_FOCUS has the drone's position. It should at least be the other way around, and the offset needs to be changed to a different direction.

About time, too! Unfortunately it's just a case of the Reborn body having a butt that sticks way out and is incompatible with regular (very long) rigged hair.

It's a known issue (it started with the performance updates) and it happens whenever an avatar is near your cursor, and it gets worse with multiple avatars. (More specifically it's related to attachment bounding boxes, especially rigged mesh. The viewer is trying to detect which attachment you're clicking on.. if any.) You can inspect avatar bounding boxes from Developer > Render Metadata > Bounding Boxes.

Sounds like your shoes are rigged, based on the message from Avastar. You can only have up to 4 bones (the SL skeleton you've rigged the shoes to) affecting any one vertex (the individual points where edges connect to). When it comes to the Complexity score, don't worry about it too much. It's an outdated statistic and a bad indicator for lag. You should probably reduce the number of faces (and textures if you can), as well as making sure that the textures don't have transparency information unless they need it. (Edit the object and check the "alpha mode." Set it to "None" or "Masking" instead of "Blending." If the option is greyed out, the texture has no transparency data at all.) Since you've been modeling with the Subdiv modifier, your model would be a lot more efficient if you took the time to clean up any unnecessary edges from the model. (Like if you have a long straight surface with lots of loops on it (like a heel), dissolve all of the ones in the middle.)

One of these sims on Aditi (not main grid, that was a typo) should work, I've only been in Mauve myself: https://community.secondlife.com/forums/topic/492419-linksetdata-fuction-testing/#comment-2523298 Yes, linkset data is a completely regular prim property so it has the same behavior we're all used to. When something is an inventory item (either your avatar's inventory, or an object's contents), it's just a reference to a unique asset. Once you rez an object, that instance is a new copy, separate from the inventory item (or the real asset it refers to). Any modifications you make to the rezzed copy will not affect the inventory item or other rezzed copies of it. Making a copy of the inventory item (not rezzing it, just creating duplicates of the same item within your inventory) won't create new assets or cause linkset data to be duplicated, all of those inventory items are referring to the same asset. (And that's not an issue since, as soon as you rez one, that rezzed copy begins its own life.) Assets are basically* immutable if that's an easier concept to think about.

Yes, inventory items are safe in all situations. 🙂

Keep it, you'd have to be lucky to find a better card for less than $700-$1000 in the current market.

Yes, LSD would be gone. TP failures cause attachments to not save. (When it happens, you're no longer connected to any sim which could handle your attachments.) It's extremely annoying.

I just had to go and test it, I was too curious. Using this script: default { state_entry() { llLinksetDataWrite("key", "value"); } touch_start(integer total_number) { llOwnerSay((string)[llLinksetDataRead("key")]); } } I can create LSD in Mauve (beta grid) and wear it, then move to Dore (a non-LSD sim) and make a copy of the object I'm still wearing (after verifying that the data is gone), and come back to Mauve. When I detach the "broken" object and wear the copy I created in Dore, the data is as it should be. This isn't any big revelation (or even relevant after LSD is fully deployed to main grid), just a neat confirmation.

Changes made to attachments are not committed until they are detached, so when you crash hard enough (not just logging out or getting disconnected), the normal "save on unrez" process doesn't take place. You can, for example, change the texture on an attachment and then make copy the inventory item you're currently wearing. The copy you've just created won't have the changed texture, it's a copy of the attachment before you put it on (including script state). It should follow that LSD will behave exactly the same.

It hasn't been asked, but I'd assume LSD gets rolled back too.

I don't think this is true. I mainly set my profile picture through Firestorm but I also use other viewers (including LL), and haven't noticed them being out of sync. (Been using Firestorm since day-one, long before web profiles existed.) It also doesn't really make sense that Firestorm would host its own profile pictures when LL already has that system built for them and other TPVs are able to do it too. There'd be a lot of topics about that over the years but this is the first time I'm hearing about it. Sounds like a normal caching issue.

Looks more than good, the card is chilling at 60 degrees and it won't even start slowing itself down until it hits 88 degrees. 🙂 You can find this out either by going to Nvidia's (the GPU maker) official page and scrolling through the technical specifications, or just by googling "rtx 2060 max temperature".

A lot of the functionality was molded by feedback during this month-long thread: https://community.secondlife.com/forums/topic/492023-linkset-data-is-coming

While there is an undo/redo button (Ctrl-Z, Ctrl-Y), it only works on position/rotation as far as I recall. If you have the edit window open and you've selected a wrong color/texture by accident, you can press the "Cancel" button to undo that. But if you close the color/texture picker, or you've dragged a texture directly on the object or texture slot, you can't undo that. The same applies to pretty much every other edit, like lights, physics, etc.

It was based on the first two seconds or so, looked like she was about to take off more than just shoes. 😅

A warning about NSFW content would be nice.

The web profile does not sync. It's been several days since I changed the pic (which you can see on the previous page). But that's expected since those are going away.

GPUs are intended to work at 100%, so it's nothing to worry about unless your computer is always very hot or shutting itself down due to overheating. And like Ragu mentioned, the recently released performance improvements might've enabled your GPU to work better than before.

Local textures can only be seen during one login session and only by the account that selected the texture. They're never seen by other people. Since you're on Firestorm and/or don't have the new legacy profiles, you have to actually upload a texture into SL so it becomes an inventory item, then use that as your profile pic. The new profile pic won't update immediately for others, but it only takes a couple minutes. It won't update on the website. 10 lindens is an infinite amount of money for people who can't or don't want to put their payment info into SL, especially before we had options to set profile pics for free. (Before the website, before Premium Plus, never mind the fact that you have to spend a minimum of US$2.50.)