Phate Shepherd

When speed isn't particularly an issue, I like to take that same method and turn it into a function... it also avoids having to have a change event handler to detect when the linkset is changed. integer NameToLink(string name) { integer count = llGetNumberOfPrims(); integer i; while (i < count) { ++i; if (llGetLinkName(i) == name) return i; } return 255; } // Now you can reference prims by name instead of number anywhere in your code... llSetLinkPrimitiveParamsFast(NameToLink("Knob"), [ PRIM_COLOR, ALL_SIDES, <1, 0, 1> , 1 ]);

I can barely code in C, never-mind C++ or any objective languages and managed to compile the MacOS SL viewer a couple years back to add in the mirror diff. Compiled the PC version as well (in-world mirrors refused to work on the Mac, but the viewer ran fine.) Took about an afternoon of setting up the dev environment according to the wiki. I doubt that just adding a command line switch to build an M1 version or a fat binary with both X86 and M1 code will be that easy due to numerous tools needing fiddling with to make them behave under Big Sur. Its going to take a Mac die-hard at LL to convince them to pony up at least $700 for a Mac Mini to try it out.... or one of us!

If you are trying to send more than 1024 bytes, I'd be looking at something simpler... splitting the string into smaller chunks like 512 bytes, and putting a header on the front with a x of y parts and timestamp info on the front. Then reassembling on the other end if all parts have arrived, and the timestamps match. (Messages aren't guaranteed to arrive in order)

I verified that script to script allows 1024 bytes for both positive and negative channels. Public channel 0 chat was cropped at 1023 bytes. Tested both LSL and Mono. Edited the Wiki.

Anyone else have issues with L$ balance not showing since the latest restart? Also, map won't load. You are at 109.7, 179.1, 1002.6 in Kilauea located at ec2-54-244-176-238.us-west-2.compute.amazonaws.com (54.244.176.238:13025) SLURL: http://maps.secondlife.com/secondlife/Kilauea/110/179/1003 (global coordinates 230510.0, 246963.0, 1002.6) Second Life Server 2020-11-09.551942

If there is any chance the item to be attached will also be rezzed by itself, take the time to check if the item is attached before requesting permissions... otherwise it will throw errors. That isn't necessary if the request permissions is in the attach event itself, but if it is anywhere else (like in a state_entry) then it is wise... state_entry() { // whatever other startup code there might be..... if (llGetAttached()) llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION); } attach(key id) { if (id) llResetScript()); } (BTW, I agree with KT about the method... I also prefer to do the permission request in state_entry since that will let you recompile the code while wearing the item and have it behave as intended while testing.)

Although very unlikely, your channel calculation could pick channel 0... which you might want to avoid.

I would fall over backwards if they just allowed for grid-scope KVP! Grid-scope KVP would solve sooo many problems with region to region communication. For example, no external DNS service would be required for http comms. Objects could have global settings without needing an outside DB. Since they went with a single experience, with 128MB max storage, raising the count or size could be a premium feature. One problems I see is that there is no ability to revoke keys. So, if you sold an object that is out there gobbling up KVP storage, you can't revoke a key to force end users to update to a later version of your object that doesn't gobble up space.... and there are no DB tools short of iterating through the keys one by one to manage/delete them.

Home region is uplifted. I am curious... if you are on an uplifted region, will you stay on AWS even after a restart, or could you be migrated back? Many of my scripts are running at double the speed as before. I saw the speed increase on the beta grid, but was wary that it would translate to the production grid.

Unfortunately, that video is blocked for me. Not sure if it was a QI clip or not, but love the show. I was a little unsure of how the transition from Stephen Fry to Sandi Toksvig would go, but I like her every bit as much. I only recently heard about Gomboc from an action lab video.

Which rot to put first? Divide or multiply? Local or global? Ahh, whatever. Try all the permutations until it works!

What if you rigged the cape primarily to the extended bento avatar wing bones (Secondarily to the chest/abdomen). For a default animation, you could have a high priority wing bone animation hold the cape behind the shoulders, allowing regular animations to move the arms freely, but when playing animations that you create, the wing bones could follow the arm bones and possibly create an over the shoulder draped look. Weighting that would be nightmarish though.

So i have this function2 that pre-processes a string as part of a much more complex function1. What I have noticed is that calling the function2 is faster than inlining the function2's code in function1. Is this my imagination, or are there possibly optimizations in the Mono compiler that favor short functions over doing similar in-line in a much larger function? I know that some traditional language compilers will go so far as to assign frequently used variables in a function to processor registers, favoring short functions. Also smaller functions fit in smaller processor caches... but I can't imagine Mono taking advantage of either?

You could use a prim animator, and it might accomplish what you are looking to do. There may be another way to do it that might be more realistic, but I'm not sure how wise it would be to go down this path. Basically it involves rezzing a copy of the item to explode, and having it set temp rez and physical. Then a script inside it would make sure it is physical, and temp rez, and unlink it. The act of unlinking a physical object can make for a nice explosion, especially if the prims overlap slightly. It does require that the owner grant permission to the object before it can unlink itself. Lots of testing would be needed to make sure you aren't making a litter bomb. I haven't tested the scripted form of this, only the manual version of doing this: Selecting an old style house made of prims, setting it temp-rez and physical, and then clicking unlink..... BOOM!

As Profaitchikenz Haiku mentioned, if black will be a valid option that someone might want to use, then a more complete test could be done... // Break up the vector to verify it has the proper number of components list v = llParseString2List(llStringTrim(msg, STRING_TRIM), [" "], ["<", ",", ">"]); if ( llGetListLength(v) == 7) { llSetTimerEvent(0); RGB = (vector)llDumpList2String(v, ""); partSystem(); }

Pathetic humor attempt, terrible execution. SORRY

She's assaulting someone. "Stop yelling!" THWAK!

Poster was discussing gathering client diagnostic information, client IP, etc. If they happen to go down the path of obtaining that information, to avoid presenting that information to others. Nothing more than that was intended by the post.

-snip- Both on by default. No user interaction required. This message will self destruct in 24 hours.

I assume there is another script that is listening for something from the HUD to get its key? It sends a link message with CMD_FILTER of 101, and the destination HUD key is the MSG string? What is LK2 used for?

Grr... goofed and missed hitting reply. Post above is the response.

Yes, there are no LSL commands that expose that information directly. However, there are a few viewer features that are enabled by default that will expose that information in concert with an external server. I only mention it as one of the thread participants was discussing collecting various diagnostic information, and I wanted them to be aware that displaying any identifying information, even without any bad intentions, could run afoul of the TOS. Do you recall the RedZone fiasco some years back? It took advantage of these loopholes to collect visitor IP addresses. It also had a web page you could visit, put in an avatar name and it would list out all other avatars that shared that IP address... and obviously, IP addresses typically resolve down to a city, if not an even smaller geographic area.

Torn underwear makes me yank GROIN.

Yes, why?

Be careful... anything that gathers client IP information is frowned on, and may violate the Resident's Privacy Rights policy, specifically the Disclosing Personal Information section. http://wiki.secondlife.com/wiki/Linden_Lab_Official:Residents'_privacy_rights