Quistess Alpha

An alternate way of approaching this is to llSensorRepeat() for avatars in-range, and then set the glow for the panel under their feet. If you turn off the sensor when nobody's in range, and only turn it on when an avatar collides with the system, it's reasonably efficient. . . . funnily enough it seems the last time I touched the version I made was a year and a day ago. I'd post the script, but it's specific to custom mesh and (retrospect being 20/20) the style is a bit cryptic.

I haven't gone exploring recently, but a few years ago there were a good handful of libraries with (mostly notecard-based) books of varying quality.

given that she wants it to look 'just like' her example, she probably wants something with subtle baked lighting on the glass, and a distinct separation between the inner liquid and outer container.

The 'correct' method goes something like this (when to open/close listeners left out for simplicity): the chair rezzes the HUD and sets a global variable to the key of the avatar. The HUD sends a message back to the chair asking for the key of the avatar it's supposed to attach to. The chair sends the HUD a message containing the Key of the avatar to attach to. the HUD llRequestPermissions PERMISSION_ATTACH from the avatar, or if experience-enabled, uses llRequestExperiencePermissions instead. If/When the HUD gets the permission, it calls llAttachToAvatarTemp() There are various 'hacks' to simplify steps 1-3, which are to greater or lesser degree 'bad practice' : The Chair can set the rez parameter to an integer which partially represents the key of the avatar, then the HUD can llSensor for nearby avatars who's key matches. The Chair can set its description field to the key of the avatar the hud wants to attach to. (the HUD can get the key of the Chair that rezzed it with llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY])) The Chair can rez the HUD at the exact location of the avatar it is to attach to, then the HUD can llSensor for avatars that are very close by. (this can be combined with the first hack) In any case, it's also important to make sure the HUD is TEMP_ON_REZ or otherwise deletes itself if it does not get permission or cannot find the avatar to attach to, and also invisible and non-physical so as not to be an eyesore.

llAttachToAvatarTemp() (if the script is in an experience enabled on the land, accepted byu the avatar, then there's not even a permission request dialog) from the HUD's script after it's rezzed. It's a minor pain getting the HUD to know who it's supposed to attach to though. You can also do something similar with RLV, but it's even more of a pain.

file a support ticket Nobody on these forums can help you.

Indeed, it's an annoying 'feature'. The best you can do at the moment is use llRegionSayTo() to additionally notify the avatar that you would really like them to accept the permission request. There's a similar problem for group invites. Unless someone actively tells me they invited me to a group, I always miss the notification.

Interesting. One thing I'd note is that compared to the specification of the .net implementation you mentioned in the bug report, this doesn't have an integer parameter for additional options. At the very least, I think it would be nice to have an option for 'multi-line mode'. (although, thinking through use-cases in my head a bit more, it wouldn't be that much trouble to iterate the function on each line of the haystack)

When you link prims, for the first time, pretty much all viewers have a bug where they misunderstand which links have which number. The standard fix for this bug is to take the object back into your inventory, and then rez it again. (If anyone feels like expiramenting, does re-logging or teleporting to a different region for a few minutes and then teleporting back fix the displayed numbers?) IIRC, If you have an object with links named 1,2,3,4 and link it to an object with links named a,b,c,d the links will be ordered a,1,2,3,4,b,c,d, but your viewer will wrongly tell you they're in the order a,b,c,d,1,2,3,4 unless you do the take and re-rez trick.

I would use the 'report abuse' button in-world, or submit a ticket.

as a caution to others who might try and play around to figure out this might work, Do not attempt to rapidly enter and exit mouselook on a fast timer: constant re-centering of the mouse pointer makes the viewer unusable. (also FWIW, you always enter mouselook looking perfectly horizontal). ETA: The only RLV product I know of that offers something similar to this functionality doesn't actually let you go into mouselook as far as I can tell, so I'm out of leads. using the @setrot command can change the facing direction while in mouselook, and will force the up/down angle of your vision to perfectly level.. roughly: vector delta = target_pos-my_pos; float angle = llAtan2(delta.x,delta.y); // apparently RLV uses clock angles rather than math angles. llOwnerSay("@setrot:"+(string)angle+"=force"); (untested)

not really? default { state_entry() { llSensorRepeat("","",AGENT_BY_USERNAME,20.0,PI,5.0); } sensor(integer n) { string text; while(~--n) { key ID = llDetectedKey(n); integer typing = llGetAgentInfo(ID)&AGENT_TYPING; text = llDetectedName(n)+"\n"+text; // preppend because we're reading in reverse order of distance, want closest first. if(typing) { text= "TYPING: "+text; } } llSetText(text,<0,1,0>,1.0); } no_sensor() { llSetText("",<0,1,0>,0.0); } } Sensor only works for up to 16 (or is it 32?) people, and usually sorts by distance order. for more people or alphabetical order, would need to use llGetAgentList.

I'm not a fan of objects that change their name to the first word in the message. llSay(0, owner+" has chosen "+message); is fine. Setting the object name to the display-name of the owner of an attachment makes it look to rlv(a) enabled viewers like the actual owner of the object is speaking, which is not something you generally want unless you're scripting a gag. If you really were wanting it to appear from the owner's mouth, my grammar preference would be more along the lines of "I choose X." or "/me chooses X." If you want to obscure the message source, just set the object name to "". I personally prefer using SLURLs to display avatar's names: owner = "secondlife:///app/agent/"+(string)llGetOwner()+"/inspect";

unfortunately, scripted camera control doesn't work while in mouselook. The best you could do is to move the camera to a bit above the position of your avatar, and then set the look at point to the position of the target. If you do this very fast it should more-or less give you the effect you want, but it's rather inefficient, and will look a bit off to anyone with a framerate faster than the update speed (which can only go up to ~45fps) Might be of some use :

default { state_entry() { integer iAnim = llGetInventoryNumber(INVENTORY_ANIMATION); while(~--iAnim) { string sAnim = llGetInventoryName(INVENTORY_ANIMATION, iAnim); llStopObjectAnimation(sAnim); } } } would probably work, object animations are doubly annoying because you need to stop them by name. Adapting this from the wiki would also work: stop_all_animations() { list curr_anims = llGetObjectAnimationNames(); llSay(0,"stopping all, curr_anims are " + llList2CSV(curr_anims) ); integer length = llGetListLength(curr_anims); integer index = 0; while (index < length) { string anim = llList2String(curr_anims, index); llSay(0, "Stopping " + anim); llStopObjectAnimation(anim); ++index; } } default { state_entry() { stop_all_animations(); } } presumably they just forgot to make it modifiable.

default { state_entry() { llSetTextureAnim(ANIM_ON | SMOOTH, ALL_SIDES,0,1,1.0,1.0,0.2); // no LOOP llSetTimerEvent(20.0+llFrand(5.0)); } timer() { llSetTextureAnim(ANIM_ON | SMOOTH, ALL_SIDES,0,1,1.0,1.0,0.2); llSetTimerEvent(20.0+llFrand(5.0)); // repeated for a different llFrand result. } } possibly?

search/ replace "llSetAlpha(" -> "llSetLinkAlpha(LINK_THIS, " "llSetPrimitiveParams( " -> "llSetLinkPrimitiveParamsFast(LINK_THIS, " some 'older functions' have a built in delay. Without the delay it should look like things that happen very rapidly in succession happen at the same time. ETA: llSetAlpha doesn't actually have a delay, so that search/replace is unnecessary.

Besides the offerings on the marketplace, what clothes are currently available for laraX? I'm not too picky, but a plain t-shirt would be nice.

scripts in clothing shouldn't cause much of a problem for the wearer, their impact is almost entirely on LL's servers. 'script scrubbers' don't work like that, they're only needed to clean up certain 'permanent effects' like continual spinning, and hover-text that some scripts can apply to an object. The only/best way to remove scripts is to manually delete them from the object's contents (be sure to check each link) which only works if the object has mod permissions, or use the 'remove/deactivate scripts' button on the HUD for the object if there is such a button.

'leashes' have 2 nominally separate systems working together: the 'pull' physics part, and the particle generation/receiving part. lockmeister/lockguard protocols only deal with particles. Their reference implementations are on the wiki, but could definitely use a major overhaul, as they're quite script heavy for things with more than one place a 'chain' can be attached to. IIRC only one of them is in common use, but the names are so similar I can never remember which is which. https://wiki.secondlife.com/wiki/LSL_Protocol/LockMeister_System https://wiki.secondlife.com/wiki/LSL_Protocol/LockGuard Real Restraint (RR) Kyrah Design Concept (KDC) and Open Collar (OC) each have distinct leash (particle+physics) protocols. OC is open-source so you can look at the code (there are two competing factions, be sure to make sure they're mutually compatible) yourself. RR and KDC, may not have openly available protocols.

integer blink = TRUE; // whether the light is currently on or off. default { state_entry() { llSetTImerEvent(1.5); // in seconds, how often to blink. } timer() { blink = !blink; llSetLinkPrimitiveParamsFast(LINK_THIS, // first link number. [ PRIM_FULLBRIGHT, 3, blink, // 3 is the nuimber of the face. PRIM_LINK_TARGET, 3, // lets say we want to change another face on link#3 PRIM_FULLBRIGHT, 2, blink // face #2 on link #3, do not put a comma at the end ]); } } or so.

integer OFF = TRUE; // this variable is never read, remove it: //integer toggleState = 0; // 0: Normal state, 1: Active state integer faceToToggle = ALL_SIDES; // Replace with the face number you want to control default { state_entry() { llSetTextureAnim (ANIM_ON | LOOP, ALL_SIDES, 5, 2, 0, 0,14.0); llSetAlpha(1.0, ALL_SIDES); } on_rez(integer start_param) { llResetScript(); } touch_start(integer num) { if(llDetectedKey(0) != llGetOwner()) return; // some would say this is bad form, but IMO it's more neat than enclosing the rest of the event in a section. OFF = !OFF; // because each condition set it to the opposite value, it makes more sense to reverse it before the if clause. // ^ roughly the same as OFF = 1-OFF; if(OFF) { llSetAlpha(1.0, ALL_SIDES); // Toggle between states on touch // Turn off glow, set full bright to false, set transparency to 100 llSetPrimitiveParams( [ PRIM_GLOW, faceToToggle, 0.0, PRIM_FULLBRIGHT, faceToToggle, FALSE ]); llSetLinkAlpha(LINK_THIS, 0.0, faceToToggle); } else { llSetAlpha(0.01, ALL_SIDES); // Turn on glow, set full bright to true, set transparency to 0 llSetPrimitiveParams( [ PRIM_GLOW, faceToToggle, 0.3, PRIM_FULLBRIGHT, faceToToggle, TRUE ]); llSetLinkAlpha(LINK_THIS, 1.0, faceToToggle); } } } is how it might look with better indentation and a few fixes. I haven't tested it.

At a glance, it looks like not all of your '{'s have matching '}'s. Some of your '{'s look like maybe you intended them to be '}'s. Usually, we as scripters use indentation to make it more clear where the brackets are and are supposed to be.

You might be interested in: https://marketplace.secondlife.com/p/Book-with-turnable-pages/23762086

Right, at the moment, it would probably have to be set up so that they choose their spawn point before they die, at the beginning of a match or something. ETA: or, when they die, they could be teleported to a non-combat 'lobby' area with a system for teleportation to the main combat area spawn points.