Quistess Alpha

If you want to be really esoteric, since your lower bound is 0, you can do: x = (x>0)*x; to make x 0 if it is negative, and x = (x<=100)*x + 100*(x>100); to keep it less than or equal to 100. for the least legibility: //x = (x>l)*((x<u)*(x-u)+(u-l))+l; // if(x<l) x=l; if(x>u) x=u; x = (x>0)*((x<100)*(x-100)+(100));

That's probably the most sensible, but another option would be to use llCastRay() to search for obstructions, which could be preferable for looking over a longer distance (no need to calculate a cone angle).

To account for the (slim) possibility of a server side bug, also try putting your script(s) in a fresh clean cube. Weird server bugs generally persist in copies of objects.

Either A) there's a serious bug with SL, or B) one of your (well founded) assumptions is wrong. You mentioned taking it to the other simulator, but did you try a different parcel that you own? It's not impossible you have some accidentally activated script in something you didn't intend to script, or just an old version of something laying around.

Yes, but also no. a very generic LSL program looks something like this: integer gVariable1 = 0; // <variable type> <variable name> = value; // ... integer my_awesome_function(integer argument/*,<arg type>,<arg value>*/) { // commands; return 7; } my_awesome_function_with_no_return_value_or_arguments() { my_awesome_function(7); // commands; } // <return type or empty> <function name> (<var type>, <var name>, <var type>, <var name>...){ <command list>} default { state_entry() { // commands } touch_start(integer n) { // more commands } //event_name(<event arguments>) //{ // commands } // ... } state second_state { //event_name(event arguments){<event commands>} } state third_state { // event_name(event arguments){<event commands>} } (I'm going to name a lot of things because it makes discussion easier, I don't know if these names are 'standard') The script has a few different sections: The preamble: before the 'default' keyword, global variables and functions are declared, and variables may be assigned default values. These declarations can happen in any order. a special restriction of the preamble is that 'calculation' is not allowed in variable definitions, integer three = 1+1+1; // not allowed! (addiiton) key owner = llGetOwner(); // not allowed! (calling a function) integer four = 4; // valid. would not compile in the preamble, but ~would be allowed in a function or event command list, The event list: inside the {}'s after the default keyword, event handlers for the default state are defined. These handlers may be defined in any order (swapping state_entry() and all of the contents of its {} with touch_start won't change the script) Extra state sections: states can be used to define different event handlers for separate situations. statea other than default can be defined in any order (second state along with everything in its {}'s can be swapped with third_state and its {} and it will remain the same. Command lists: within the {}'s of a function definition or event handler, you have lists of commands separated by ';'s. when the handler or function is executed, each command will be run in order. This means that swapping 2 lines will probably change the program, but sometimes if two lines don't affect each other, then swapping them won't change the perceived effect, because lines are executed so fast they seem simultaneous. Argument lists: within the ()'s of an event handler, the order and types of the arguments are fixed, but you can change their names: touch_start(integer this_is_a_very_silly_name) { llOwnerSay((string)this_is_a_very_silly_name); } -- Another thing to note, is that unlike Python, LSL uses curly braces and other symbols to denote logical sections rather than indentation and spacing. integer three = 1 + 1+ 1; is perfectly valid (if a bit silly). -- Interestingly, LSL doesn't have any direct mechanism for making visuals. Everything has to be done by changing the parameters of "prims". The two most obvious ways of making a meter are by changing the length (or "slice") of a long cube, or by changing the offset of a texture, although there are other methods. (you could instead make a HUD using media functions, but that requires a lot of html+css understanding in addition to knowing lsl fluently)

No, it doesn't exist. In LSL, (generally speaking) you can give but you can't take; there are no functions to create something in object inventory, except for as you mentioned llGiveInventory. llGetObjectDetails() can be used to learn things about another object, so it might be possible to 'clone' a very simple prim object the script sees in-world, but that would be overly complicated and probably not very useful.

After the lab banned "off topic discussion" (see the pinned thread at the top of basically every section) the forums have gradually gotten less lively. Arguably that's a good thing; the forums aren't for finding belonging, that's what being ~in Secondlife is for. I dunno if I subscribe 100% to that argument, but things are what they are.

That's why the bug isn't fixed: it's only there when you're not testing for it

After mulling it over a bit in my sleep, I think in the specific case of rezzing something on the ground, in many/most situations, the most aesthetically pleasing 'roll' would take llGroundSlope/Contour into account to fix the y-axis. I haven't checked in-world but I think that would work something like: // define variables as in previous examples, thrn vector slope = llGroundSlope((pHit-llGetPos())/llGetRot()); llRezObject("marker", pHit+halfHeight*llVecNorm(pNormal), ZERO_VECTOR, llAxes2Rot(pNormal%slope, pNormal%slope%pNormal, pNormal), 0);

Since I've never used that function intensively, does the pin invalidate when the script calling that function is removed? if not. then as a theoretical impractical solution, maybe all the prims could set the pin with a temporary initialization script?

Yeah this has been an annoying bug for years. AFAIK only the person wearing the object sees it erroneously attached, and has no recourse to detach it other than re-logging. a script to delete an attachment when moving to another region is fairly trivial, and could be added in addition to other scripts: default { attach(key ID) { llRequestPermissions(ID,PERMISISON_ATTACH); } changed(integer c) { if(c&CHANGED_REGION) { llDetachFromAvatar(); } } } or so.

High level stuff you already know: To rez an object tangent to another object, you need 3 pieces of (rotational) information: The normal of the surface being rezzed on The normal/axis of the object to be rezzed (semi-optional) the 'roll' the object will have when rezzed (I.E. if your thing is a piece of paper, where do the corners go?) for sake of illustration, or if you ~really don't care about the roll (Ex. because your object is a cone/radially symetric) llRotBetween((2),(1)); should give you a semi-reasonable orientation: vector a; vector b; // application dependant. list ray = llCastRay(a,b,[RC_DATA_FLAGS,3]); key k = llList2Key(ray,0); vector pos = llList2Vector(ray,1); vector normal = llList2Vector(ray,2); // do some sanity checking on those, I've not tested in-world. // if sanity passes: vector up = <0,0,1>; // which vector points 'up' for the object? float half_height = 1.0; // distance from ground to object center llRezAtRoot("rez-me",pos+half_height*normal, <0,0,0>, llRotBetween(up,normal), 0); ETA: I was going to explain the cross-product trick as an improvement, but Fenix already wrote out an example of it.

if your routine is something that can be don in terms of llSetLinkPrimitiveParams(fast), or a "link" function, then you just have to loop through all prims in the linkset: //integer index_prim = llGetObjectPrimCount(llGetKey()); // does not count sitting avatars. integer index_prim = llGetNumberOfPrims(); // may count avatars sitting on the object. // loop backwards: do { llSetLinkPrimitiveParamsFast(index_prim, [...]); }while(--index_prim); There are very few things left in LSL that must be done by a script in the specific prim which needs to be modified. Sounds were the most glaring example, but link sound functions were added fairly recently.

Making the avatar walk at a specific speed is non-trivial if you want other nice things like being able to walk up stairs/tiny ledges, and not fly backwards when trying to go forwards while falling. I have a few different implementations in my "fine for personal use, but probably not good enough for a general-use product" bin of 95% finished products. see:

for pretty much anything I do, a single script is sufficient, but I imagine for a system with enough complexity, you could probably implement some sort of 'no-write' flag while the complex read function is working. that might not be ~perfectly immune form certain race conditions, but it would probably be good enough for most applications.

If I were implementing this, I think I'd have both listening modes available at the same time, and use llListenControl to switch them: (untested example code:) // HUD integer CHAN_SELF = 1234; // could use pseudo-random generation, but I don't see a benefit. integer CHAN_SYNC = 4321; integer gSync = FALSE; default { touch_end(integer n) { if(...) { // sync ON gSync = TRUE; // assuming the listener is an attachment, it will hear messages directed at the owner: llRegionSayTo(llGetOwner(),CHAN_SELF,"SYNC_ON"); }else if(...) { //sync OFF gSYNC = FALSE; llRegionSayTo(llGetOwner(),CHAN_SELF,"SYNC_OFF"); }else if(...) { // send message: if(gSync) { llRegionSay(CHAN_SYNC,"msg"); }else { llRegionSayTo(llGetOwner(),CHAN_SELF,"msg"); } } } } // listener integer CHAN_SELF = 1234; integer CHAN_SYNC = 4321; integer gHandleSync; default { state_entry() { llListen(CHAN_SELF,"",llGetOwner(),""); gHandleSync = llListen(CHAN_SYNC,"","",""); llListenControl(gHandleSync,FALSE); } listen(...) { if("SYNC_ON"==msg) { llListenControl(gHandleSync,TRUE); }else if("SYNC_OFF"==msg) { llListenControl(gHandleSync,FALSE); }else if(...) { } } }

My firestorm's broken at the moment, but I tested it in Kokua and that doesn't seem to be the case? (I think in some cases it may look like you're sending the offer, but the other party doesn't receive it; try testing with 2 accounts logged in at once, or use a friend.) "@permissive=n,showloc=n,sendim=n,share=n,pay=n" should be sufficient to give enough of an illusion of helplessness. There's nothing you can really do to stop say, messaging a friend on discord, or using an alt.

Making an avatar go somewhere via LSL is . . . clunky. The viewer actually as support for old runescape style 'click to move' though. My 'ease of use' solution would just be to auto target: is someone with a sword (and compatibility HUD or whatever) within 10 meters of a skeleton? Move the skeleton directly in front and facing the avatar (because moving avatars via script is hard) and have the skeleton and avatar play sword swinging animations and stuff. . . too bad we can't make damage number particles look nice, unless the system uses single-digits.

Yeah, and in RLV proper ( RLVa has a payment restriction ) you can always give someone 1L$ with a message asking them to come over.

@showloc or anything that restricts knowing the current location I believe (because I just tested and confirmed that it) also prevents sending teleport offers.

I think this link still is valid for searching the MP for freebies: https://marketplace.secondlife.com/products/search?utf8=✓&search[layout]=gallery&search[category_id]=&search[sort]=sales_rank_asc&search[per_page]=96&search[keywords]=NOT+demo&search[price_low]=0&search[price_high]=0&search[land_impact_low]=&search[land_impact_high]=&search[copy_permission]=0&search[modify_permission]=0&search[transfer_permission]=0&search[limited_quantities]=0&search[is_demo]=0&search[is_demo]=1

you need the entry # in the list; llListFindList() can help you find the entry number if you know exactly the thing in the list you're trying to delete.

Have you actually tried that? I may be mis-remembering, but I thought BOM without correct alpha mode led to dreaded red-skin.

Apparently, 'kitten' is the magic search word.

Yeah, I get 0/86 elements, with both accounts I tested with, all folders, no contents.