Quistess Alpha

It's possible but very hacky to convert floats to hexadecimal losslessly, and then convert that to an integer which can be used in the standard way: https://lslwiki.digiworldz.com/lslwiki/wakka.php?wakka=LibraryFloat2Hex (not my work)

Real address, not email.

The post being parallel to the z axis means it's a single equation in one (easy to extract) variable, if the post were at an arbitrary angle. . . the vector math might get a bit annoying. roughly, solve for scalar (float) 'S': vNormSelf*((S*vAxisPole)+vPosPole) == 0; // after expanding definitions, will be a single equation in a single unknown. where vNormSelf is the normal to the hoop, vAxisPole is the long dimension of the post, vPosPole is (the position of the pole - the position of the hoop). then ((S*vAxisPole)+vPosPole) would be the vector who's length gets checked against the radius. ETA: actually, dot product is distributive and associates with scalar multiplication, so it's not too bad: vNormSelf*((S*vAxisPole)+vPosPole) == 0; S*vNormSelf*vAxisPole + vNormSellf*vPosPole == 0; S = -((vNormSelf*vPosPole)/(vNormSelf*vAxisPole)); (I don't think vector division is a thing, so can't factor out vNormSelf)

More, better math! TL;DR; find the line from the center of the hoop, that passes through its edge (lies along the plane of the circle) and also touches the (hypothetical, infinitely tall) post. if that line is longer than the radius of the hoop, the hoop is not 'on' the post. float RADIUS = 0.222; default { state_entry() { RADIUS = RADIUS*RADIUS; // computation enhancement. } touch_end(integer num_detected) { llSensor("My Post","",PASSIVE,5.0,PI); } sensor(integer n) { vector posPost = llDetectedPos(0); vector posSelf = llGetPos(); vector vDiff = posPost-posSelf; vector vNorm = llRot2Fwd(llGetRot()); // assuming a torus prim. vDiff.z = (-(vNorm.x*vDiff.x)-(vNorm.y*vDiff.y) )/vNorm.z; // solve vNorm*vDiff == 0 (perpendicularity condition) for vDiff.z llSay(45,(string)vDiff); // optionally send a message to a 'vector visualizer' for sanity check. if(vDiff*vDiff < RADIUS) { llOwnerSay("On"); }else { llOwnerSay("Off"); } } } ETA: Depending on your use-case, you could also check the difference between vDiff.z before the re-calculation and after. if the hoop is otherwise "on" the post, but vDiff.z increases by more than the distance from the center of the pole to the top (half its height) then the hoop is probably 'too high up'. A normal distance check would probably work just as well in practice though.

Adding some vector visualizations helped me figure out an interesting 3-d error I had been making. for my own edification I might try figuring out a more 'correct' solution, but an easy hack is posPost.z = posSelf.z+RADIUS; on line 14. ETA: that can give you some false negatives though. A pretty rough-and-ready vector visualizer to put in a 1-1 taper, 0.5,1.0 slice cylinder: default { state_entry() { llListen(46,"","",""); } listen(integer Channel, string Name, key ID, string Text) { llSetPos(llList2Vector(llGetObjectDetails(ID,[OBJECT_POS]),0)); vector v = (vector)Text; llSetRot(llRotBetween(<0,0,1>,(vector)Text)); llSetScale(<0.05,0.05,2*llVecMag(v)>); } }

But but, what about ego, and being so persuasive the higher ups will have to take action!?!

Who knows what kind of black-void an actual letter sent to Linden Lab would fall into.

Contact info can be found at the bottom of most sites (including this one) https://www.lindenlab.com/contact Unless you're a (representative of) a big company, Email is not the correct medium for your message. As Love mentioned, Jira for feature requests.

Actually, no simplifying assumption: if the projection of llVecNorm(vTarget)*RADIUS onto the x,y plane is longer than the projection of the vector to the pole, then the ring is over the pole. // same up to this line: vector vTarget = vLeft%vNorm; // vector pointing at the post, lying on the plane normal to the ring's z-axis. vTarget=llVecNorm(vTarget)*RADIUS; // set the length of the vector to the radius of the ring. vTarget.z=0; vDiff.z=0; if(vTarget*vTarget > vDiff*vDiff) // vector*itself == its magnitude squared. { llOwnerSay("on"); }else { llOwnerSay("off"); } /me goes back in-world to check. . . then adds a missing llVecNorm().

There might be better ways of going about it, but I think this works as an example: key post = "881a86be-f4a9-3faa-9b5d-bd828fc3ea08"; float RADIUS = 0.8; default { state_entry() { llSensorRepeat("",post,PASSIVE,5.0,PI,5.0); } sensor(integer n) { vector posPost = llDetectedPos(0); vector posSelf = llGetPos(); vector vDiff = posPost-posSelf; // if the post is more than radius away, it is definitely too far. if(llVecMag(vDiff)>RADIUS) { llOwnerSay("Off (too far)"); return; } rotation rotSelf = llGetRot(); vector vNorm = llRot2Up(rotSelf); // z-axis. // a prim-torus would use the x-axis: llRot2Fwd(rotSelf); vector vLeft = vNorm%vDiff; vector vTarget = vLeft%vNorm; // vector pointing at the post, lying on the plane normal to the ring's z-axis. vDiff.z = 0; // ignore height difference: assume the post is infinitely tall. float theta = llRot2Angle(llRotBetween(vTarget,vDiff)); float distFlat = llVecMag(vDiff); float distHyp = distFlat/llCos(theta); if(distHyp<RADIUS) { llOwnerSay("On"); }else { llOwnerSay("Off"); } } } I had a partial solution when @Rolig Loon posted and I realized I had made a minor mistake, and used her idea about the angle to fix it. There might be a way to do it with a bit less trig.

@animats mentioned this problem in another topic and I had a spark of an idea for a very simple fix: force the camera to be wherever it was when you sat down. Ideally this would be integrated into the animation engine (AVsitter) directly, but it's trivial to add as a plugin: integer neededPerms = 0xC00; // PERMISSION_CONTROL_CAMERA|PERMISSION_TRACK_CAMERA default { changed(integer c) { if(c&CHANGED_LINK) { // not exact, re-requests when someone stands up. key sitter = llGetLinkKey(llGetNumberOfPrims()); if(llGetAgentSize(sitter)) llRequestPermissions(sitter,neededPerms); } } run_time_permissions(integer perms) { if(perms==neededPerms) { vector pos = llGetCameraPos(); if(pos) // don't change the camera if there was some very improbable bug. { llSetCameraParams( [ CAMERA_ACTIVE, TRUE, CAMERA_POSITION_LOCKED, TRUE, CAMERA_POSITION, pos ]); } } } } (There may be some minor bugs with multiple sitters when someone stands, haven't tested thoroughly)

the OP asked about LSD specifically and that's been pretty well covered already. There's no "one method works best" you have to consider the use-case: bi-directional: If the 'packed' key needs to be turned back into a 'normal' key, you have to conserve all 128 bits of information. see all the specific examples in the script library. one-direction: If you only need to go 'one way' say for the script to remember 'have I seen this person before?' you have to consider how many keys you're storing at once, and how often your full list of keys might 'turn over'. rule of thumb I think is to take the number stored and square it, rounding up: so, If I need to remember say, 200 keys, 200*200 = 40,000 < 2^16 bits of information. 32 bits are easy to handle so might as well for safety. Try (integer)("0x"+(string)(<key>)); and convert to base 64 (llDeleteSubString(llIntegerToBase64(int),-2,-1);) if necessary. ETA: for the above '200 keys' scenario, the 'just square it' heuristic says you need to keep at least 4 of the hex characters (4 bits per hex digit, *4 =16) but that might be a bit 'close to the line' if the list fills and empties frequently (Say, if you're remembering 200 (different) avatars every day, you'd expect one collision almost every 2 days! but assuming that the group of people your tracking is always different is also unrealistic. . . you can go very far down the rabbit hole.)

That's also changeable, I just didn't mention that it's changeable because that's the main reason people change names. if I wanted to be trendy I could change my name to "Tessa (Susan Sausage)" , assuming that's not taken yet. ('Samantha Sausage' is taken *shrugs*)

a few things. Display names are free to change, and in fact you can change them weekly. They should ~never be used in identification as they are not unique. usually when you see someone's name in that format, "newname" is the display name, often used by people who want funky characters in their name to be "cool". If you see me in-world you might see my name as "Tessa (Quistess Alpha)" When you pick a new name (by paying the 40$ fee) you may opt to change only your first name, and not your last name. "alpha" is no longer on the list, but if I really wanted to, I could change my name to "Tessa Alpha" (but I wouldn't because I don't like the double a)

I'm sure you could cook something up with llChar(32+(integer)llFrand(95))+llChar(...)+llChar(...)+...; or so. my back of the envelope math says 5 or 6 base 95 characters should probably avoid a collision for most LSL use-cases.

I disagree, for most use-cases, you should store the majority of keys in LSD and only 'pull' it into script memory when appropriate; as a single key in mono script memory is trivial, the only efficiency questions worth asking are 'how small is it in utf8?' and 'how fast/efficient is the conversion?'. smallest size in utf8 is the 19 byte one I linked above. smallest size in utf16 is first one molly posted a bit ago. fastest compression with small size in utf8 might be a 20-byte compression with no carry. I don't think anyone's doe lots of in-depth comparisons.

I'm pretty sure I saw one on the map once (out in the boonies where all the single private regions are) . I obviously can't be certain if it was exactly that though.

I believe the technical name for it is 'the inverted hull method'. Minor pet peeve of mine is that it's colloquially called cell shading for products that use it in SL, even though cell shading is a completely different thing entirely. Something like cell shading can be emulated with extreme environmental parameters (Low gamma, no light-sources except sun, high sky ambience), but that applies to everything, not just a single object, and is a bit "trippy" unless a region is designed around it, and it might not even work anymore when PBR rolls out.

You only have one "landlord" who is either LL or another resident; you will never have to pay both at once (for the same plot of land). If you buy a plot on mainland, you will have to pay the original owner (once) for the land, or if you're savvy, you can look for a piece of 'abandoned' land, which LL will sell you at a very reasonable price (1L$/meter) if you send in a support ticket. There are also land auctions. Funny enough, there's a plot on auction close by to the one you were looking at. it's about half the size though. https://places.secondlife.com/parcels/268333/jiminy-68-76-general-1024m

I don't do much web stuff, but wouldn't that work only once? and if so, seems like a lot of work when you could just 'save page as...' .

Actually, no, you're getting recognition/association with the object in a distributed database. most/many 'art' NFTs are hyperlinks to images not hosted on the blockchain (because images are large and encoding is expensive). your "ownership" is not enforceable in any real sense (anyone can access the hyperlink, 'terms and conditions' may or may not allow you to sue someone for using the image) and the off-chain hosting site can 'poof it at any time' if image hosting gets too expensive.

Ooh I missed that one in my few casual glances. A year or two I got around that function not existing by having a script in an invisible linked prim that moved to where the sound needed to be played. The wiki isn't 100% clear on whether the sound needs to be in the prim the script is in (most likely) or whether it needs to be in the prim which plays the sound (would be annoying). I'll need to test that later.

Among other examples in the library section. For technical reasons (no direct access to binary memory, strings automatically handle character-encoding in a way that can be binary-inconvenient), achieving an exact 16 byte conversion in LSL is not possible

I recently changed that setting on an alt, and I don't think I got a 'notification email', but it still worked. Try having a friend IM you while you're offline to test if it's working.