Quistess Alpha

If you had a sound file hosted on the internet somewhere, sound files played via media-on-a-prim ignore distance limitations (but not everyone has media on auto all the time).

llLinkPlaySound was recently added to LSL, so you can do it with one script and no link_message. perhaps triggering the sound rather than playing it (or visa versa) might make a difference?

That looks awesome for vehicle control, but doesn't (as far as I can see) include a way to change the movement speed of an avatar not-on-a-vehicle. There are currently "hacks" for making an agent move at a given speed from an attachment, but they all have devastating caveats (If you directly set the avatar's velocity without pass-through, then walking up stairs becomes a problem; if apply a force in the reverse direction of the avatar's regular movement, you run into many scenarios where the avatar's movement isn't what the script might naively think it is.)

If that could (somehow, magically) include variable movement speed (depending on amount of stick tilt, and/or direct change of movement speed with LSL) I think that'd make movement feel a lot better and 'modern'. Adding some kind of support for variable strength blended moment animations on top would help too, but that's more of a pipe dream.

I had vaguely considered that interpretation as well, but if it's exactly 24 hours, someone who really wants a thing every day will be gradually pushed back slightly later each day (because realistically nobody can manage to do something at exactly the same time every day). In that mode, I'd err on being lenient and set it somewhere around 18~23 hours.

maybe I'm a bit prejudiced, but I don't trust long-interval timers. I'd run an hourly timer and check if the day has changed: integer gDay;// what day is today? // ETA: it's important to initialize this to ((llGetUnixTime()+gTimeOffset)/86400) in state_entry()! integer gTimeOffset = -28800; // convert to SL time. (I think?) timer() { if(gDay!=((llGetUnixTime()+gTimeOffset)/86400)) { ++gDay; clear_stored_keys(); } }

and hopefully get the same answer as the total_inventory_count - script_inventory_count. Printing out the name of each item and whether it was accepted or rejected with an llOwnerSay() could help in debugging though.

If possible, I would have the speedy thing emit the particles, a short PSYS_PART_MAX_AGE and a relatively low PSYS_SRC_BURST_RATE (lower is better visuals, worse performance hit on observers)

Assuming your word is short enough, and letters are small enough that the 10-meter rez radius doesn't come into effect, it shouldn't be all that difficult, but might be a bit of work as a first project to learn LSL. your script would need to set up a listener so that it can respond to what is said to it (by rezzing the letters) your script probably wants to give a llTextBox in the touch_start event. in the listen event, to actually rez the letters, you'll want to calculate the total width of the word, then for each letter, rez it at the position of the object plus some height, plus half the width of the word in the left direction of the rezzer's orientation less half the width of the letter, and the total width of all previous letters. you may want a way to remove the letters when it's time for some new letters. to do that you'd need a script in each of the letters that makes them die when they hear a specific message.

merchant-home (from the mp main page) -> transaction history. see also https://wiki.secondlife.com/wiki/Direct_Delivery_and_Automatic_Notification_System

Is it as easy to explain as it is to fix? I'm rather curious.

I've heard of that functionality, but I can't think of what products specifically have it off the top of my head. It's not an overly hard thing to script yourself, the main difficulty would be providing a UI for "owners" to set which regions are allowed, and to turn the function on and off.

The unseen context of why other people weren't helping more is because it seems pretty clear the OP is just using some sort of AI tool to generate code and hoping it magically works without understanding the underlying logic. IMHO It is not worth the effort to try and explain to this kind of person how things actually work. As helpful as such an example might be, I think it would be better off in its own thread in the LSL library section.

synchronizing multiple short sounds for a midi-like music synthesis in SL works ok when the stars align and lag is low, and granted the last time I played with the idea was before the big script efficiency update, but when it goes badly, it goes really badly. I don't think it would work well in a region with any sizeable number of people in it.

another 'solution' would be to pull the ending point inside the region without taking the start point into account (untested): vector pull_to_region(vector point) { vector diff = point-<128,128,128>; float scale = 1.0; float f; // temp variable if((f=llFabs(diff.x))>127.99) { scale = 127.99/f; } if((f=llFabs(diff.y))>127.99) { f = 127.99/f; if(f<scale) scale=f; } if((f=llFabs(diff.z))>127.99) { f = 127.99/f; if(f<scale) scale=f; } return (scale*diff)+<128,128,128>; } but that seems almost as complicated. another bad solution, would be to guess and check distances from the start point: decrement dist starting from 360 (distance from one corner to another) until start+dir*dist is inside the region. // roughly: vector GetSimEdge(vector start, vector dir) // WARNING: may infinite loop if start is outside region! { float dist = 360.0; vector edge; do { edge = start+dir*dist; dist -= 10.0; }while(edge.x<0 && edge.x>=256.0 && edge.y<0 && edge.y >=256.0 && edge.z<0 && edge.z>256.0 ) return edge; }

In the second function, I'd check the minimum after each calculation, rather than as a large check at the end, and guard with a condition rather than a small offset: float scaleGuess; float scaleFactor = 9999999.0; // ideally, set this such that start+dir*scaleFactor is on a region edge. if(dir.x) // guard against zero divide. { scaleGuess = ((dir.x >0) *255.99-start.x)/dir.x; //if(scaleGuess<scaleFactor) scaleFactor = scaleGuess; scaleFactor = scaleGuess; // ideally, set this such that start+dir*scaleFactor is on a region edge. } if(dir.y) { scaleGuess = ((dir.y >0) *255.99-start.y)/dir.y; if(scaleGuess<scaleFactor) scaleFactor = scaleGuess; } if(dir.z) { scaleGuess = ((dir.z >0) *255.99-start.z)/dir.z; if(scaleGuess<scaleFactor) scaleFactor = scaleGuess; } return start+dir*scaleFactor; but I don't think there's much else you can do unless you settle for approximating the region-boundary-cube with a 'nicer' function.

probably not, and certainly not for timescales longer than a few seconds, but for a cut-off point between roughly 0.2~0.7 seconds, might depends more on your connection latency than the specific method used. Whether to use one or the other would be up to a bit of testing, and whether the timing of multiple inputs is important (hold down c, wait a moment then press another control being different than pressing both c and the other control at the same time) I forgot you can just record the start time of an input without resetting the script's clock. I probably would use time rather than # of events for legibility if nothing else. llResetTime() on attach and changed_teleport if float precision becomes an issue.

integer state = 2*!(level&CONTROL_FWD) + !(edge&CONTROL_FWD); if(3==state) untouched(); else if(2==state) released(); else if(1==state) held(); else if(0==state) pressed(); Needless optimization.

Actually, you could probably track the number of control events. for simplicity assuming just Control_FWD is being tracked, (and just an off the cuff untested example:) integer gCount_FWD = 0; control(key ID, integer level, integer edge) { if( (level&CONTROL_FWD) && (edge&CONTROL_FWD) ) // equivalently, level&edge&control_fwd? { gCount_FWD = 0; // button was just pressed, }else if( (level&CONTROL_FWD) && (~edge&CONTROL_FWD) ) { ++gCount_FWD; // button is held, increment count. }else if( (~level&CONTROL_FWD) && (edge&CONTROL_FWD) ) { // button was released. if(gCount_FWD > 45) // IIRC there are about 45 events per second? { do_long_hold_action(); }else { do_short_hold_action(); } } }

Assuming the most favorable case where that's an experience the OP owns, they would need to have a group, assign the experience to the group (or the group to the experience, I forget exactly where the UI for that is) then invite the scripter to the group and assign them a role which has the ability to compile scripts to the experience.

MdlM 'proud girls'? https://marketplace.secondlife.com/p/MdlM-Proud-Girls/13105977 Not a lot of clothing support for them though.

How do people normally figure out how much damage they've taken? IMO a function to directly read an avatar's LL health value would probably be rather useful.

Just had a chance to test and my hypothesis about logical operations possibly implicitly casting floats was wrong, and you can't scalar multiply rotations, so I don't have any compilable cases to add.

Yeah, that's what I get for typing things and not looking it up on the wiki. I forgot llGetListEntryType() was its own function.

actually for a better conceptual understanding, I'd recommend going through the trig with llAtan2() and constructing an orientation with a product of llAxisAngle2Rot(). llRotBetween often doesn't do what you think it does when used outside of simplified contexts.