Quistess Alpha

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.

If the balls are already talking, you can use llGetObjectDetails() to get the position of the thing that triggers a listen() event.

Sensors do give you the results ordered by distance, so it would stand to reason so, but I don't know if it's reliable.

A simple example would be something like: list gRotations = // rotations to show each face. [ < 0.5 ,-0.5 ,-0.5 , 0.5 >, // 0 < 0.0 , 0.0 ,-0.71, 0.71>, // 1 < 0.0 , 0.0 , 1.0 , 0.0 >, // 2 < 0.0 , 0.0 , 0.71, 0.71>, // 3 < 0.0 , 0.0 , 0.0 , 1.0 >, // 4 <-0.5 , 0.5 ,-0.5 , 0.5 > // 5 ]; default { touch_start(integer total_number) { integer link = llDetectedLinkNumber(0); string lName = llGetLinkName(link); // expect links named '0page', '1page', 2page ... 5page. if("page"==llDeleteSubString(lName,0,0)) { llSetRot(llList2Rot(gRotations,(integer)lName)); } } }

LSL's camera system wasn't designed generally enough to do anything it wasn't specifically intended to do in a visually appealing or 'correct' way. While it is technically possible to force it to do what you want, if this is for a personal project, you will have a much better experience if you use your viewer's camera controls to set up a custom camera position. 'precise controls' -> set the 'camera offset' Y value to something relatively large (like 5.0), and play with other values to taste, then save as a preset.

I wasn't in SL at the time, but I vaguely remember back when youtube was young, it was a lot easier to have them serve you a raw video file if you asked nicely, which would have made it a lot easier for a SL script to add a front-end which would make it appear a bit more synced than it actually was. Now, basically only places specializing in bad things that start with the letter 'p' (p*** and p*****) serve raw video files that aren't spliced into small segments for easy quality switching, and/or walled behind some layers of DRM.

It looks like you're trying to make a hud with different 'pages'. When those different pages each have linked buttons on them, it gets rather difficult to script cleanly unless you build your HUD in a specific way. The easiest way to make it work is to have each page of your hud on a different side of a cube, then turn the cube to display each face. Another common solution is to make your HUD like a windmill, but IMO that gets very obnoxious to manipulate (add/remove buttons) in-world.

tl;dr is you can't synchronize viewing of a youtube video unless you either rip the video to a raw video file, or use one of several mildly expensive TVs in SL that already exist, and probably forward the video to an external server for you.

most viewers come with a "quality and speed" slider that automatically adjusts many other settings that might be a bit fiddly to adjust individually. You probably want it on the faster&low side (left). draw distance between 32 and 96 is perfectly usable for most things. I keep mine at 64 even with higher graphics settingss. "max number of non-imposters" low can help, or just set "maximum complexity" to its lowest value, which will cause everyone to be clouds until you decide manually to render them (right click -> render fully).

Out of curiosity, does this involve making the textures for the particles, or just the scripting?

texture rotation is a client-side effect, and IIRC it only "jerks back" when the viewer tries to see the "real" rotation, by for example trying to edit the object. The two main ways to do "real" smooth movement are KFM and physical movement (gravity to zero, and set phantom/VolumeDetect). Both have pros/cons, and should be used sparingly, if at all.

compiles fine for me as long as the global variable poseMenuChannel is declared. Check that your global variable declaration exists, and is exactly the same spelling as in the function.

To rotate the child prim 20 degrees on it's own z-axis: rotation Z20 = llAxisAngle2Rot(<0,0,1>,20*DEG_TO_RAD); // for example integer link = 2; rotation rChild = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROTATION]),0); llSetLinkPrimitiveParamsFast(link, [ PRIM_ROT_LOCAL, (Z20*rChild)/llGetRootRotation() ]); for root's axes, swap the order of the change and orientation rotations: [ PRIM_ROT_LOCAL, (rChild*Z20)/llGetRootRotation()

For SL at least "standard orientation" for objects is for them to be "facing" the +x direction, with +z being up and +y being left. When faced with a situation where the object you're working with isn't "right side up" and "facing" due east when its orientation is set to ZERO_ROTATION, I usually suggest just making it so: link your object to an invisible root prim, and rotate it so that the child prim is in standard orientation. It saves a lot of headaches. That said, if you ~absolutely must work with an object in non-standard orientation, you will probably need to determine its "intrinsic rotation" which I'll call rINTRINSIC. Rotate your object so that it's in standard orientation, and confirm that when the object is selected in edit mode, with the 'move' radio button on and "snap: World" checked, the red arrow and the object point in the same direction and the blue arrow points "up". Then, you can use the three rotation numbers in the object tab of the build window to set rINTRINSIC, and use that to find the axes of the object that point forward, up and left: rotation rINTRINSIC; vector UP; vector FWD; vector LEFT; default { state_entry() { rINTRINSIC = llEuler2Rot(DEG_TO_RAD*<0,270,0>); // X,Y,Z numbers from the build menu. UP = <0,0,1>/rINTRINSIC; FWD = <1,0,0>/rINTRINSIC; LEFT = <0,1,0>/rINTRINSIC; } } Preferably though, you should set rINTRINSIC based on the axes of the object. When the object is in standard orientation as above and if your object has a 'sane' intrinsic orientation, changing between snap:world and snap:local will only change the colors of the arrows, the local axes are still aligned with the world axes. rotation rINTRINSIC; // which local arrow points up? vector UP = <1,0,0>; // for example, the red arrow (representing <1,0,0> or +x) in snap:local points in the same direction as the blue arrow in snap:world, up. // which local arrow points forward? for an animal, which arrow points with its eyes, for a vehicle, where would it move? vector FWD = <0,0,-1>; // for example, the blue arrow (+z) in snap:local is aligned with the red arrow in snap:world, but points opposite direction (so add a minus sign). // which local arrow points left? vector LEFT = <0,1,0>; // for example, the green arrow (+y) is exactly the same between snap:world and snap:local. default { state_entry() { rINTRINSIC = llAxes2Rot(FWD,LEFT,UP); } } With those values in-hand, here are a few functions that might be helpful. (I'm writing them as functions for clarity, but you can of course in-line the simpler ones) vector dirFacing() // in global coordinates, what direction is this object 'facing'? { return FWD*llGetRot(); } integer WhichSideIsUp() // 0 for 'right-side-up, 1 for upside-down, based on the value of global variable UP { return ( (UP*llGetRot())*<0,0,1> ) < 0; // more reasonable than testing the object's roll. } integer AmLookingDown() // 1 for looking below horizon, 0 for looking up { return ( (FWD*llGetRot())*<0,0,1> ) < 0; } uSetRotYPR(vector v) // 'Yaw', 'Pitch' and 'Roll', with respect to rINTRINSIC { rotation ypr = llAxisAngle2Rot(<1,0,0>,v.z) * llAxisAngle2Rot(<0,1,0>,v.y) * llAxisAngle2Rot(<0,0,1>,v.x); llSetLinkPrimitiveParamsFast(0, [ PRIM_ROTATION, (ZERO_ROTATION/rINTRINSIC)*ypr ]); } vector uGetRotYPR() { rotation q = rINTRINSIC*llGetRot(); // https://community.secondlife.com/forums/topic/471561-urot2euler/?do=findComment&comment=2293046 vector v; // x-axis float s = 2 * (q.s * q.x + q.y * q.z); float c = 1 - 2 * (q.x * q.x + q.y * q.y); v.z = llAtan2(s, c); // y-axis s = 2 * (q.s * q.y - q.z * q.x); if (llFabs(s) >= 1) v.y = (-1 | (s < 0)) * PI_BY_TWO; else v.y = llAsin(s); // z-axis s = 2 * (q.s * q.z + q.x * q.y); c = 1 - 2 * (q.y * q.y + q.z * q.z); v.x = llAtan2(s, c); return v; } 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(0, [ PRIM_ROTATION, (ZERO_ROTATION/rINTRINSIC)*look ]); }

Yeah exactly, That and not really relevant for my specific use-case, but if it was a one-use item like a firework or something, that goes off when rezzed, it would be neat if the owner/maker could easily switch it from safe for-sale mode, to detonation mode by buying the object. Solution is of course to have a separate vendor and sale object, but being able to detect if an object was just bought could simplify things.

In the bought copy. I briefly tested the money event, but that seems to only work for paying the object, not buying it via the simple self-vendor system. That's exactly what I did, (and even had the original and bought copies do different things) but just as a mostly academic exercise, it would be kind of nice if the system worked when the owner buys their own object. Using the money event and selling a copy of the object from the vendor's inventory like a normal vendor would do that, but that would require more tedious setup from the seller.

Ciao Katie, e bienvenudos a SL! In order to sit someone on something, you need to use one of two systems, either RLV or an experience. RLV isn't enabled on all viewers, and it's probably a whole topic on its own, but, to ask someone who's wearing a RLV relay to sit on an object, you might use something like: sit_on_prim(key avatar, key object) { llRegionSayTo(avatar,-1812221819, "sit,"+(string)avatar+",@sit:"+(string)object+"=force"); } An experience is a bit different. In order to have an experience you can add scripts to, you need to make one as a premium member, or be a part of a group which gives you access to one. assuming you can compile a script to an experience, you also need to have the script ask permission from the people it wants to sit, and the script can only sit people on the object the script is in. the wiki has a decent example for one person: https://wiki.secondlife.com/wiki/LlSitOnLink either way, to sit more than one person, you just need to iterate through the list of all people and sit them.

do you have any more examples of what special characters map to what encoding? it's interesting both those specific examples have %3*

If I'm reading it right, it just expects an object named smf.gallows anchor to say something on Key2Chan(llGetKey()) on a timer. particles and some other things seem to be handled by another script in your set that you didn't post, but my best guess from this info alone is just: // anchor script? integer Key2Chan(key ID) { return 0x80000000 | (integer)("0x"+(string)ID); } float spam_rate = 0.2; integer isOn = TRUE; integer chan; default { state_entry() { chan = Key2Chan(llGetKey()); llSetTimerEvent(spam_rate); } touch_start(integer n) { llSetTimerEvent( (isOn=!isOn)*spam_rate ); if(isOn) llSay(0,"On"); else llSay(0,"Off"); } timer() { llSay(chan,"something, doesn't seem to matter what?"); } } Honestly, since your noose already has a sensor_repeat in it, it would be better to rescript it to handle the timing on its own, rather than relying on messages from the anchor to clock its pull. you could have it read the description of the anchor to tell if it's supposed to be on or not.