Quistess Alpha

All the ones I've seen are of this variant, but they can be ~very clever about not making the position obvious. If you have such a device, write a simple particle script that sends a beam from an attachment to a known object in-world (a 'leash' should work, but make sure it's from a different device than the one that's doing the hiding). That may make the hidden position more obvious.

perhaps use ⌚ or ⌛ instead? Those seem to be in the character set given by @Frionil Fang's quote.

A few years ago I made a thing that needed a 'guided setup', there were like 5 different things the user needed to do (change permissions, set object description, input an email, etc.) that for the sake of clarity were asked of the user in-order. Implementing it with states for each step had a lot of duplicated code, but was rather easy to write and debug. a while later I had to re-write the system, and decided to use just 2 states (one for setup, and one for when it was running) to see the difference. and it turned out a lot messier, with a lot of checks on the 'state' global variable in each event, which just looked confusing. Moral of the story I guess, is that states aren't useful most of the time, but when they make sense, they're incredibly useful if only for code clarity. All the times I can think of using states have been some form of 'setup' state, where the script does things like requesting permissions and reading notecards, (IMO a separate setup state is best practice for anything requesting PERMISSION_DEBIT) and then a state for when it's operating normally. But any time something needs to have radically different reactions to events, states can offer a lot more clarity than global variable checks, even though almost everything a state change can do can be done without one*. *moving from a state with a touch event to one without can "disable" the mouse hover over effect for an object. CLICK_ACTION_DISABLED might now have the same effect, the wiki doesn't say so though.

even with global variables, I think what Love's saying is that you might have accidentally done something like: string name = "Bad Value"; default { state_entry() { string name = "Good value"; // by writing 'string' at the begining of the line, we cause the global copy of name to not be written to. } touch_start(integer n) { llSay(0,name); // will say 'bad value' because of error in state_entry() } } Which is allowed in LSL, but almost never intended.

llGetInventoryKey("animation name"); will give you the key of "animation name" if it's in the object's inventory, unless there are some permission issues I've forgotten about. You can in-fact start and stop an animation with its key rather than its name, but if you try and stop an animation with its key and it's neither a built-in animaiton nor in the prim's inventory, I think that makes a pop-up error.

It doesn't answer the wording of your problem, but perhaps a better way of going about it would be to use llGetAnimationList() to check which animations are running rather than a global variable. Or, you could just stop all the animations you may be running; AFAIK there is no penalty for stopping an animation that was never started.

AFAIK the "correct" behavior is that temp attachments only detach when done explicitly (logout/user detach/llDetachFromAvatar) or when entering a parcel/region that doesn't have the experience that requested the permission to attach. A quick test shows that non-experience temp-attachments survive region-changes non-borked.

Basically, yes. You could also think about it as the new region taking non-zero time to learn about your attachments from the old region.

The energy system is anything but intuitive and affects very few specific systems; Thanks for telling us how you figured it out!

https://search.secondlife.com/?search_type=standard&collection_chosen=places&places_category=&destinations_category=92&events_category=0&date=&dateformat=mm%2Fdd%2Fyy&starttime=0000&maturity=gma&query_term=sandbox

A fancy replacement for cycleList might be something like: list = llList2List(list,1-llGetListLength(list),0);

LSL is pass-by-value, and will never pass-by-reference. In other words, cycleList (content1); cannot change the value of content1. you have to return the value and do an assignment: list cycleList (list c_list) { if(llGetListLength(c_list) > 0) { string first_entry = llList2String(c_list, 0); c_list = llDeleteSubList(c_list, 0, 0); c_list += first_entry; llOwnerSay("Debugging. New list order is: " + llList2CSV(c_list)); //return c_list; // returning here but not outside the if() will result in an error: // functions that return a value must return a value in all cases. } return c_list; } // later in the script: some_list = cycleList(some_list); Consider also: default { state_entry() { integer x=7; llOwnerSay("X="+(string)x); // scope-creation does not need a reason, like an if/while/for { integer x = 9; // removing 'integer' from this line leads to more 'expected' behavior. llOwnerSay("X="+(string)x); } // when scope is exited, x has its previous value: (because was re-declared in new scope) llOwnerSay("X="+(string)x); } }

Very recently, llSetClickAction(CLICK_ACTION_IGNORE); was introduced, which fixes that exact problem: when CLICK_ACTION_IGNORE is set, clicking behaves as if the object which ran the command doesn't exist. (I haven't tried it though, not sure how it interacts with right-clicking)

should just be llOwnerSay("@shownames=y"); also, you can combine multiple commands into a single string: for example: llOwnerSay("@shownames=n,shownametags=n,setdebug_renderresolutiondivisor:10.0=force");

That's a RLV-specific thing that changes a debug setting, llOwnerSay("@setdebug_renderresolutiondivisor:8=force"); where 8 is the amount of pixelation. Some combination of environment lighting settings can make a 'trippy' atmosphere. play with your personal environment settings, then see llSetAgentEnvironment

I was prompted recently to post a rather old script I wrote that did such in the LSL library. It's actually rather subtle and tricky to do in a way that 100% won't crash in a room full of people with crazy (long&/funny symbols) names. (said example does crash)

you need the attach event from your first script to request the permission to play the animation before you play it (you can remove the permission to take controls).

I've never had occasion to rapid-fire messages from one script to another, but I'd assume script-to-script order is somewhat more reliable than script to viewer?

No matter what happens server-side (in LSL) I don't think there's any order verification in the client, (nor does the client send back received verification AFAIK) so, "pretty reliable" is the best you can hope for. I'm not sure what you mean by a "queueing event" but if you mean something like a timer() then it would be more reliable, if only because each event runs in a different 'frame' of computation, which adds an imperceptible delay.

Same with me, but there are too many variables to make general claims. It could even be weird internet connection flukes.

the order you receive messages in is not guaranteed to be the order in which they were sent. Adding a short sleep after each message can increase the probability of a correct order, but in most cases, it shouldn't matter, and you can often consolidate the messages into a single message: test() { integer i = 0; string send; for (; i <= 6; i++) { send+=(string)i+"\n"; } llOwnerSay(send); }

Perhaps I missed it in a quick skim, but the API seems to only be intended for the viewer to interact with, not a LSL script; It's unclear how the protocol validates that the requester is in-fact the merchant in control of the listing. Someone with intimate knowledge of the viewer could probably figure it out, but it doesn't seem like an intended use-case.

I'm not old enough to remember "grey goo", but it's certainly possible if you're clever enough. Check out llRemoteLoadScriptPin(). it's a bit of a pain, but it mostly solves the matryoshka doll problem.

llSetLinkTexture(link_number,"texture's UUID (in quotes)",face_number); // only one of the following 2 lines is really neccessary: llSetClickAction(CLICK_ACTION_DISABLED); // or: llSetScriptState(llGetScriptName(),FALSE); somewhere in the money event right after a line that has llGiveInvenyory...

In that case, sounds like a fairly standard custom vendor script. If you already have a the code for a vendor script that already does most of what you want, I think some nice people might offer to add simple additions for free. From scratch on the other hand. . . Talking about exact prices is sticky territory, but I can't imagine it would take more than an hour or two of someone competent's time.