Quistess Alpha

"chat links" (IDK if there's a standard name, but that's what I've always called SLURLs of that form) can be a very powerful tool, but current SL limitations make them very clunky in most practical applications. As I think you pointed out in the comments of your script, llDialog's 512 char limit limits the number you can stuff into a dialog box. I have seen/used at least one product that llRegionSay's the links to the user as an alternative to a llDialog style menu, which works fairly well (as long as you constantly remind that most viewers seem afraid of chat links for some imagined security reason, and require the user to right-click then 'run this command' in order to activate a chat link) except when you want/need to hold a conversation in local chat while using the product. IMO a notecard filled with chat links would be a very useful menuing alternative, but alas chat links do not display as clickable in notecards. IIRC you can get chat links to work from within media displayed by the in-world web-browser, but at that point, there are better solutions that also work with an external web-browser. Not to mention some people's fear of releasing their IP address via media. Chat links can work in your profile to hand to a notecard to people within chat range of your avatar (or some other object you've scripted to listen to the command). I have one in one of my picks.

most viewers only display 12 characters on a button, but the button names are allowed to go up to 24 characters before script errors happen. Simply change the line if(llStringLength(name)<=12)

Even worse, for objects, one ought to have the possibility of "slam bit" in mind. Even assuming an object with empty contents, it is possible for the "inventory asset" of an object, to have permissions that differ from the in-world-rezzed version of that object*. IIRC, you need to do some uncommon things to get that to happen intentionally, but it's still best practice to only change the permissions of objects that are rezzed in-world. *The most common case is a full-perm object that when rezzed in-world and then taken back into inventory has more restrictive permissions. Interestingly, such objects can be attached without affecting the permission.

The copy-paste into a new tab test brought up a scary warning about Linden Lab's SSL cert being untrusted. Not an issue you can fix.

The way I would (and have in the past) script this sort of thing with more places than just first place, is to use a global strided list of the form [score, player-UUID, player-name]. To add a new score, search the list for the new UUID, then if the found index is not -1, compare the scores and overwrite if new is greater than old. else, add a new stride to the end of the list, use llListSort* to sort the list, then use llList2List() to clip the list to a fixed length. * tangent: until rather recently it was unfeasible to sort a strided list by any stride other than the first, which is why I'd put score first in the stride. llListSortStrided fixes the issue.

There's a viewer feature to mass change permissions in an object's inventory, Kokua has it and I wouldn't be surprised if it was standard across all tpv's if not the linden viewer. "permissions" button in the content tab, then select only the script icon, and change the permissions to what you want, then press the apply button. After reading the OP more carefully, I tested using the feature with multiple objects at once, and (maybe surprisingly) it does work on multiple objects if you have them all selected at once, even though the content tab will appear empty when selecting more than one object. shift+click on an object while in edit mode to add or remove it from the list of currently selected objects, then use the permissions adjustment feature the same way as if you had only one object selected.

Works surprisingly well, as long as you understand that it points as if it were in the center of your HUD, which may or may not be the effect wanted. Not what was asked for, but with that demo, it feels better to me if it points based on the avatar's position&rotation,

Objects on your HUD are in isometric perspective, which means it's impossible to make a 3d HUD that perfectly points at an object and doesn't look a little off, but exaggerating the closeness of the target when it's in front of you seems to work decently: key inworld_object = "a10a343b-ec44-cd27-1898-3c15d8f4622b"; float distance_factor_forwards = 0.1; float distance_factor_backwards = 1.0; rotation rINTRINSIC; // see https://community.secondlife.com/forums/topic/472730-rotations/?do=findComment&comment=2713790 for how to set this value propperly. uLookAt(vector direction, float roll) // to look at a specific position in-world, set direction to (position-llGetPos()) { rotation look = // inline YPR2Rot() llAxisAngle2Rot(<1,0,0>, roll) * llAxisAngle2Rot(<0,1,0>, -llAtan2(direction.z,llVecMag(<direction.x,direction.y,0>)) )* llAxisAngle2Rot(<0,0,1>, llAtan2(direction.y,direction.x) ) ; llSetLinkPrimitiveParamsFast((llGetNumberOfPrims()>1), // root prim being 0 or 1 is dumb. [ PRIM_ROT_LOCAL, (ZERO_ROTATION/rINTRINSIC)*look ]); } default { state_entry() { rINTRINSIC = llEuler2Rot(DEG_TO_RAD*<0,270,0>); llSetTimerEvent(1.0); } timer() { if(llGetPermissions()&PERMISSION_TRACK_CAMERA) { vector pObj = llList2Vector(llGetObjectDetails(inworld_object,[OBJECT_POS]),0); vector point_to = llWorldPosToHUD(pObj); vector pCam = llGetCameraPos(); point_to.x *= llVecMag(pObj-pCam); // position results for objects behind the camera are funny. if(point_to.x<0) { point_to.z = -point_to.z; point_to.y = -point_to.y; point_to.x *= distance_factor_backwards; }else { point_to.x *= distance_factor_forwards; } uLookAt(point_to-llGetLocalPos(), 0.0 ); }else { llRequestPermissions(llGetOwner(),PERMISSION_TRACK_CAMERA); } } }

New LSL functionality to make exactly this kind of thing more feasible to script was added fairly recently. Check out the example at: https://wiki.secondlife.com/wiki/LlWorldPosToHUD

Texture animation counts as rotation, right? // public domain texture-animation 'tick' script. // This script only works correctly when the rotated face has 0 offset and 0 rotation degrees and 1 Horizontal scale and 1 Vertical scale in the build window! (texture animation is buggy.) integer face = 0; // which face to rotate, or ALL_SIDES float degrees = 30.0; // how much to rotate each tick. float time = 0.75; // how long to rotate each tick float time_tick = 1.0; // how long is each tick in total (time+pause) integer tick_max=12; // if non-zero, only do this many ticks. integer tick=-1; default { state_entry() { //llSetTexture("571d44bb-8e5f-a579-eaec-cdb0bd109b29",face); degrees = DEG_TO_RAD*degrees; llSetTimerEvent(time_tick); if(tick_max) llSay(0,"Time starts now!"); } timer() { ++tick; // end condition check: if(tick_max && (tick>=tick_max)) { llSetTextureAnim( ROTATE, face, 0,0,0,0,0); // SMOOTH bit on causes less smoothness than without it! // but having no bits set returns the face back to 0. llSetTimerEvent(0.0); llSay(0,"Time is up!"); return; } // do the texture animation: // must stop previous anim before starting the next one, or else animation will be instant: llSetTextureAnim( ROTATE, face, 0,0,0,0,0); // smooth bit on causes less smoothness than without it! llSleep(0.05); // 0.05 should always work, 0.0233 works 75% of ticks or so. llSetTextureAnim(ANIM_ON|SMOOTH|ROTATE, face, 0, 0, (tick*degrees) , 1+(degrees) , degrees/time); } }

I can confirm I get the same behavior. and for anyone who wants to test, a good texture to use is 571d44bb-8e5f-a579-eaec-cdb0bd109b29 . Also non-intuitive, is that non-looping textures obey many of the same spontaneous activation details as non-looping particles. As long as the animation hasn't been stopped, it will activate for anyone who sees it enter their draw distance. So, if you teleport into a region right next to something with a non-looping texture animation, you should see it activate. it will also activate when rezzed from inventory, but not when shift-coppied (because, as mentioned in the wiki, shift-copy removes texture animations from the copy) Also it seems you can't do two smooth rotations in a row, you have to stop the previous non-looped animation by calling llSetTextureAnim without the anim_on flag before any subsequent rotation anims will play smoothly rather than just snapping to their final result. from a bit of testing, the best way to play a new rotation texture animation after you have already played one, is: llSetTextureAnim( ROTATE, face, 0,0,0,0,0); // smooth bit on causes less smoothness than without it! llSleep(0.05); // 0.05 should always work, 0.0233 works 75% of ticks or so. llSetTextureAnimation(ANIM_ON|SMOOTH|ROTATE, /*new animaiton parameters*/);

I'm skimming a bit and didn't see it in your OP. Besides the market place, where is the up-to-date specification for the lockguard V3 protocol?

blood moon

The further the people making decisions are from 'the ground' the less perspective they have. It only takes one powerful idiot to ruin everything, if they somehow think that a "small" profit hit now is worth the possibility of greater 'mainstreamness'

different article from the main news. https://www.forbes.com/sites/davidprosser/2021/11/12/how-thunes-is-building-a-new-payments-system-for-the-world/