Quistess Alpha

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/

If you don't need anything much different than a regular seat (I.E. the dance pad stays in one place) then why not try AVsitter?

for reference, here are my attempts at adjusting walking speed.

The last time I tested parcel media, I never got sound, just the video (though, I was able to get said video to spawn on a few hundred particles at once, but it didn't work as a projector light image.)

That general idea does work, but you will eventually run into floating point rounding problems after extended use of the HUD. I recommend using a list of all desired rotations like in the first script I posted, and using a global variable that stores the index of which rotation the HUD currently has.

for the purposes of LSD, and probably a lot of other things, the avatar is not the root prim of the attachment. the avatar itself does not store any LSD. I think a better way of thinking of it would be the avatar is kinda like its own region/sim.

I meant if you could write another script and put it in with the others in the object. Otherwise, probably not much you could do.

the http_response() event triggers in all scripts in an object when the server sends back its response, so if your object is mod, maybe you could get some info that way.

There were some projects to implement VR in SL, but I don't think any are still maintained. tl;dr, I'm not an expert, but from what I've heard in passing, adding VR to a game/experience is a lot more involved than just adding support for the hardware, if you want an experience that doesn't make most people dizzy. SL wasn't designed for VR, and good support for it will probably never happen.

touch_start(integer n) { key toucher = llDetectedKey(0); vector posToucher = llList2Vector(llGetObjectDetails(toucher,[OBJECT_POS]),0); integer distance = llRound( llVecMag(posToucher-llGetPos()) ); llRegionSayTo(toucher,0,(string)distance); }

menuChannel wasn't declared as a global variable. Easy enough to fix by adding the line integer menuChannel; near the top of the script. The fundamental issue though is that llGetOwnerSay(); isn't a real function. There are different ways to handle arbitrary text input, but my first choice would be to use llTextBox() on a different channel for each type of expected input. i.e. instead of: llOwnerSay("Please type the name you want to add:"); maybe llListenControl(someHandlerForTheChannel,TRUE); llTextBox(llGetOwner(),"Please type the name you want to add",menuChannel+1); Your changed event is non-sensical, that logic should be part of the listen event.

That HUD is open source by the way. I don't think it's written in the most clear or best way, but this is the relevant section for what it does when you press those buttons: touch_start(integer total_number) { integer link = llDetectedLinkNumber(0); integer face = llDetectedTouchFace(0); if(link == 1) { if(face == 1||face == 3||face == 5||face == 7) { rotation localRot = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0); llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,PI/2>)*localRot]); } else { rotation localRot = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0); llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,-PI/2>)*localRot]); } } // script continues. . . note that it only works as scripted because the next/previous page buttons are on the root prim. More generally, you'd want to turn the root prim (link number 1) regardless of the link number of the touched button.

The script in the OP compiles, llSetPrimitiveParams() without 'link' or 'fast' is a valid function, albeit an outdated one that probably ought not be used. The main problem I see is in the lines that look like: if (llGetLinkName(llDetectedLinkNumber(5)) == "gold") In the context of a HUD, 0 is the only sensible argument to llDetectedLinkNumber, because you can't have more than one person simultaneously touch a HUD. It'd also be better to store the value of the function rather than calling it for each conditional, or even better to restructure in a way that doesn't use repeated conditionals: (removed identical events to reduce spam) // HUD integer chan = 15113234731; list colors = [ "gold", "rose gold", "silver", "gunmetal" // no final ',' ]; default { touch_start(integer total_number) { string name = llGetLinkName(llDetectedLinkNumber(0)); if(-1!=llListFindList(colors,[name])) { //the button touched was a color name, send to attachment: // if the object is an attachment that is attached, can be more efficient: llRegionSayTo(llGetOwner(),chan,name); //llRegionSay(chan,name); } } } you can also do similar in the listener using either linkset data or a strided list to associate the name of the color with its color and specular values.

Yes, but I think you should be able to figure out how to do that much on your own.

It's got 30 votes on the AUR but It doesn't seem to be in any major distribution's main package lists, so, on a 1 to 10 "totally obscure use at your own risk" to "NSA secret agents use it" somewhere between 3 and 5. Hmm, Debian has a handy page listing all their editor related packages, picking out relevant ones and excluding terminal-only or heavily based on a terminal version (not that terminal programs are bad), the following might be interesting to look into: kate, lpe, medit, tea

Either your object (but not the scripts inside) needs to have next-owner mod-perms, or you're limited to updates which don't change the scripts themselves. Ergo, global variable/linkset data changes or doing most of the 'heavy lifting' of your application on some external web-server. Or, perhaps your updater could just rez an updated copy where the old version was and tell the old version to delete itself.