CaithLynnSayes

This one is weirdly relevant in 2021

That furries exist. I'm not even joking. Before joining SL i had no clue this kind of joint thing was widely "practiced" lol

Unlikely that LL would do that i'm afraid. But if you want to generate Mesh trees and upload them, then i can recommend a tiny piece of software called Tree It. You can download it at > https://cgtricks.com/treeit-free-3d-tree-generator/ Or google it.

So, just learned about this. That's absolutely awesome news. Really happy this annoying drivel got stopped.

Can i just point out that:

And anyone reading this after June 5th will have no clue what this was supposed to be. Don't edit your posts and delete what the question (and even answer) was. You could have helped others.

I could have a stab at that. I'm an amateur animation maker.

That indeed looks nice, thanks for cleaning up my mess

Assuming you have the same name inworld as here, item send...

Does it have to be the same object? Can it be a (clever) linkset? key owner = NULL_KEY; integer debug = TRUE; default { state_entry() { owner = llGetOwner(); } touch_start(integer num) { if (llDetectedKey(0) == owner) { integer linkNr = llDetectedLinkNumber(0); string objectClicked = llGetLinkName(linkNr); integer faceClicked = llDetectedTouchFace(0); if (objectClicked == "Object_1") // Here you can set the name of an object in the linkset that has to be detected as touched. { if (debug) { llOwnerSay("Key "+ objectClicked +" was pressed on face" + (string) faceClicked + ""); } llSetLinkTextureAnim(objectClicked, ANIM_ON | SMOOTH | LOOP , faceClicked,0,2,0.0, 1,0.14); } else if (objectClicked == "Object_2") // Here you can set the name of an object in the linkset that has to be detected as touched. { if (debug) { llOwnerSay("Key "+ objectClicked +" was pressed on face" + (string) faceClicked + ""); } llSetLinkTextureAnim(objectClicked, ANIM_ON | SMOOTH | LOOP , faceClicked,0,2,0.0, 1,0.14); } } } } I wrote this in like 5 minutes, may need adjusting. This is a concept out of my head.

Here's something i threw together a couple of years ago. Its an example prim with 5 sliders that uses this single script. let me know if you want me to send you a working version inworld. integer memoryLimit = 30000; vector screenPos; vector screenScale; rotation screenRot; vector hudPos; vector crossPos; // make it global. list params; // make it global. //LINKS integer LINK_screen;//the currently active screen integer LINK_sliderbase1; integer LINK_sliderarrow1; integer LINK_sliderbase2; integer LINK_sliderarrow2; integer LINK_sliderbase3; integer LINK_sliderarrow3; integer LINK_sliderbase4; integer LINK_sliderarrow4; integer LINK_sliderbase5; integer LINK_sliderarrow5; integer LINK_slider1text; integer LINK_slider2text; integer LINK_slider3text; integer LINK_slider4text; integer LINK_slider5text; string name; memoryLimitTest() { llSetMemoryLimit(memoryLimit); llScriptProfiler(PROFILE_SCRIPT_MEMORY); llScriptProfiler(PROFILE_NONE); // /* llSetText("Limited Memory " + (string)llGetMemoryLimit() + "\nUsed Memory " + (string)llGetUsedMemory() + "\nFree Memory " + (string)llGetFreeMemory(),<1,1,1>,1); // */ integer freeMemoryLeft = llGetFreeMemory(); float lowMemoryTrigger = 500; if (freeMemoryLeft < lowMemoryTrigger) { //llSay(0,"Running out of memory!"); llOwnerSay("Possible lag detected. Freeing up memory. Please wait one second..."); llResetScript(); } } getLinks() { integer total = llGetNumberOfPrims() + 1; string name; while ((total--) -1) { name = llGetLinkName(total); if (name == "SliderBase1") { LINK_sliderbase1 = total; } else if (name == "SliderArrow1") { LINK_sliderarrow1 = total; } else if (name == "SliderBase2") { LINK_sliderbase2 = total; } else if (name == "SliderArrow2") { LINK_sliderarrow2 = total; } else if (name == "SliderBase3") { LINK_sliderbase3 = total; } else if (name == "SliderArrow3") { LINK_sliderarrow3 = total; } else if (name == "SliderBase4") { LINK_sliderbase4 = total; } else if (name == "SliderArrow4") { LINK_sliderarrow4 = total; } else if (name == "SliderBase5") { LINK_sliderbase5 = total; } else if (name == "SliderArrow5") { LINK_sliderarrow5 = total; } else if (name == "Slider1Text") { LINK_slider1text = total; } else if (name == "Slider2Text") { LINK_slider2text = total; } else if (name == "Slider3Text") { LINK_slider3text = total; } else if (name == "Slider4Text") { LINK_slider4text = total; } else if (name == "Slider5Text") { LINK_slider5text = total; } } name = ""; } //this function is because i often ask for a local position vector llGetLinkLocalOffset(integer link) { return llList2Vector(llGetLinkPrimitiveParams(link, [PRIM_POS_LOCAL]), 0); } //we generate a params list with this function list moveSlider(integer link, vector pos, vector rr) { //This vector puts the slider in the middle if the mouse cursor went off the slider prim while sliding to avoid the -100 value from being send. //(May need to find a better solution, but works for now :/) // A better solution would be to remember the last postition and return to that if the mouse went off sliding and button released, like any program does. I may get around it. Possibly. vector midCrossPos = screenPos + (<0, 0.500 * screenScale.y, 0.50 * screenScale.z> - screenScale * 0.5 ) * (<0, 0, 1, 0> * screenRot); vector crossPos = screenPos + (<0, 0.500 * screenScale.y, rr.y * screenScale.z> - screenScale * 0.5 ) * (<0, 0, 1, 0> * screenRot); if (link == LINK_sliderbase1) { if (rr != TOUCH_INVALID_TEXCOORD) { params += [ PRIM_LINK_TARGET, LINK_sliderarrow1, PRIM_POS_LOCAL, crossPos ]; } else { params += [ PRIM_LINK_TARGET, LINK_sliderarrow1, PRIM_POS_LOCAL, midCrossPos ]; } } else if (link == LINK_sliderbase2) { if (rr != TOUCH_INVALID_TEXCOORD) { params += [ PRIM_LINK_TARGET, LINK_sliderarrow2, PRIM_POS_LOCAL, crossPos ]; } else { params += [ PRIM_LINK_TARGET, LINK_sliderarrow2, PRIM_POS_LOCAL, midCrossPos ]; } } else if (link == LINK_sliderbase3) { if (rr != TOUCH_INVALID_TEXCOORD) { params += [ PRIM_LINK_TARGET, LINK_sliderarrow3, PRIM_POS_LOCAL, crossPos ]; } else { params += [ PRIM_LINK_TARGET, LINK_sliderarrow3, PRIM_POS_LOCAL, midCrossPos ]; } } else if (link == LINK_sliderbase4) { if (rr != TOUCH_INVALID_TEXCOORD) { params += [ PRIM_LINK_TARGET, LINK_sliderarrow4, PRIM_POS_LOCAL, crossPos ]; } else { params += [ PRIM_LINK_TARGET, LINK_sliderarrow4, PRIM_POS_LOCAL, midCrossPos ]; } } else if (link == LINK_sliderbase5) { if (rr != TOUCH_INVALID_TEXCOORD) { params += [ PRIM_LINK_TARGET, LINK_sliderarrow5, PRIM_POS_LOCAL, crossPos ]; } else { params += [ PRIM_LINK_TARGET, LINK_sliderarrow5, PRIM_POS_LOCAL, midCrossPos ]; } } return params; } default { on_rez(integer param) { llResetScript(); } state_entry() { getLinks(); memoryLimitTest(); } touch_start(integer total_number) { LINK_screen = llDetectedLinkNumber(0); hudPos = llGetLocalPos(); //scroll screen screenPos = llGetLinkLocalOffset(LINK_screen); screenScale = llList2Vector(llGetLinkPrimitiveParams(LINK_screen, [PRIM_SIZE]), 0); screenRot = llList2Rot(llGetLinkPrimitiveParams(LINK_screen, [PRIM_ROT_LOCAL]), 0); //memoryLimitTest(); } touch(integer num) { vector rrGlobalOffset = llDetectedTouchUV(0); float outcome = rrGlobalOffset.y * 100; if (LINK_screen == LINK_sliderbase1) { if (outcome == -100) { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider1text, PRIM_TEXT, "Slider 1\n 50", <1.0, 1.0, 1.0>, TRUE ]); } else { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider1text, PRIM_TEXT, "Slider 1\n" + (string)llRound(outcome), <1.0, 1.0, 1.0>, TRUE ]); } } else if (LINK_screen == LINK_sliderbase2) { if (outcome == -100) { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider2text, PRIM_TEXT, "Slider 2\n 50", <1.0, 1.0, 1.0>, TRUE ]); } else { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider2text, PRIM_TEXT, "Slider 2\n" + (string)llRound(outcome), <1.0, 1.0, 1.0>, TRUE ]); } } else if (LINK_screen == LINK_sliderbase3) { if (outcome == -100) { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider3text, PRIM_TEXT, "Slider 3\n 50", <1.0, 1.0, 1.0>, TRUE ]); } else { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider3text, PRIM_TEXT, "Slider 3\n" + (string)llRound(outcome), <1.0, 1.0, 1.0>, TRUE ]); } } else if (LINK_screen == LINK_sliderbase4) { if (outcome == -100) { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider4text, PRIM_TEXT, "Slider 4\n 50", <1.0, 1.0, 1.0>, TRUE ]); } else { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider4text, PRIM_TEXT, "Slider 4\n" + (string)llRound(outcome), <1.0, 1.0, 1.0>, TRUE ]); } } else if (LINK_screen == LINK_sliderbase5) { if (outcome == -100) { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider5text, PRIM_TEXT, "Slider 5\n 50", <1.0, 1.0, 1.0>, TRUE ]); } else { llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_slider5text, PRIM_TEXT, "Slider 5\n" + (string)llRound(outcome), <1.0, 1.0, 1.0>, TRUE ]); } } //Global Position Vector llSetLinkPrimitiveParamsFast(0, [ PRIM_LINK_TARGET, LINK_screen, PRIM_TEXT, (string)rrGlobalOffset, <1.0, 1.0, 1.0>, 0.0 ] + moveSlider(LINK_screen, llDetectedTouchPos(0), rrGlobalOffset)); memoryLimitTest(); } touch_end(integer num) { //Value from 0.0 to 1.0 vector rrGlobalOffset = llDetectedTouchUV(0); float outcome = rrGlobalOffset.y * 100; if (LINK_screen == LINK_sliderbase1) { if (outcome == -100) { llSay(0,"Slider 1 said: 50"); return; } llSay(0,"Slider 1 said: " + (string)llRound(outcome)); } else if (LINK_screen == LINK_sliderbase2) { if (outcome == -100) { llSay(0,"Slider 2 said: 50"); return; } llSay(0,"Slider 2 said: " + (string)llRound(outcome)); } else if (LINK_screen == LINK_sliderbase2) { if (outcome == -100) { llSay(0,"Slider 2 said: 50"); return; } llSay(0,"Slider 2 said: " + (string)llRound(outcome)); } else if (LINK_screen == LINK_sliderbase3) { if (outcome == -100) { llSay(0,"Slider 3 said: 50"); return; } llSay(0,"Slider 3 said: " + (string)llRound(outcome)); } else if (LINK_screen == LINK_sliderbase4) { if (outcome == -100) { llSay(0,"Slider 4 said: 50"); return; } llSay(0,"Slider 4 said: " + (string)llRound(outcome)); } else if (LINK_screen == LINK_sliderbase5) { if (outcome == -100) { llSay(0,"Slider 5 said: 50"); return; } llSay(0,"Slider 5 said: " + (string)llRound(outcome)); } LINK_screen = LINK_THIS; } }

Exactly my point...

The only one being arrogant here sweetie, is you. As i said, you have no clue how SL works, you think that throwing a big giant super duper mega fast computer is going to make SL run faster. Please, dissect SL, viewer code and server code and everything around it. Learn all about it, then come back to me. Mkay pumpkin? I'm also not sure as to why that would make you mad. You demonstrate here that you have no idea of how SL works, how complicated it is and what is needed to make it all work smoothly (a little bit more than your "fast" computer). Interestingly that seems to be enough to totally throw you off the rails. Interesting, and hilarious, i'll be honest.

oh, ok

And this is a car, not a person:

I'm mostly wondering why you're using a RAM Drive as a cache location. Am i to understand that you allocated a section of your computer's RAM and use this as your cache location? If so, that really defeats the point of having cache at all. A RAM Drive gets wiped when the computer reboots or shuts down so your texture cache and inventory cache has to be fetched over and over again. Pointless bandwidth loss for both you and LL, right?

I've spend some time reading other posts about the viewer's UI and, well. I'll let Morty tell you what i want to tell you right now:

You obviously have ZERO understanding of how SL works under the hood.

Hi there. Caith with a rant. Strap in kids... (Kind of an open letter to LL...?) So, as the vast majority of your users, i am also a Firestorm user. Because it's just better. today they released 6.4.21.64531. I had the pleasure to test drive this version a couple of days before release. I have no issues with it. Typically these people are great at what they do and i support them. I understand that they take base code from you and add their own changes and improvements to it as they release new versions of the Firestorm viewer. I've heard that you (LL) are making changes to the general look and feel of the viewer's UI and some of these changes do get copied into the Firestorm viewer. On the surface this is absolutely fine if it wasn't for one tiny little massive annoyance you guys seem to be taking a liking to lately. A year ago when EEP was released, i shared my thoughts on it on @Willow Wilder's post in these forums announcing its release in Firestorm. In my reply to that i also addressed the way the save button works. It worked unexpectedly and still does to my knowledge. For some reason you guys seem to divert from the normal use of a "split button" like is used in the appearances window. (And in general programming and UI building.) The end user clicks the edge to get more options, in this case it's a save button that has a secondary function to "save as". Everybody knows to click that edge of this button to have the save as function. Shown here: With the release of EEP you decided to use a split button here. Appropriate in my opinion. However, you decide to make it function differently. Here you decide this split function should also change the main function. So click the edge, pick what you think is save as, but instead it just changes the main function to "Save As" and then the end user has to click the button.... again. Because reasons? Shown here: So now you had 2 identical Split buttons within your application/program/viewer. One in the Appearances window and one in the EEP settings, yet they function differently. The logic behind that is something i'm still searching for to this day. This is confusing to your end users. I've never heard of or seen a program with a type of button presented in different windows/dialog boxes that looks identical, yet functions differently depending on what window it's presented in. I'm a programmer RL, I believe i've said this before. In my office we have one rule, and i think other programmers reading this will know this too: People/end users are stupid. The majority of them are stupid. so, KISS (i hope you know what that means) So, why are you making it needlessly complicated and difficult for your end users? It honestly baffles me, AND worries me. It looks like you heard my rant on that a year ago and decided to change the Split button in the Appearances window some time ago. (I can't exactly pin down when since i don't use your viewer. Changes made by you will only be visible to me once Firestorm updates.) You decided to do away with the Split button in the Appearances window and put 2 seperate "Save" and "Save As" buttons next to each other. Not sure why, but i want you to look at the next 2 pictures for at least a solid minute. A: B: Can you tell me if you see anything potentially dangerous here? Keep in mind that this viewer is nearly 20 years old and a good chunk of that time this viewer had this Split button in the Appearances window... You have long term users for nearly that same length of time... You don't see it? Allow me to help you. Picture A is a screenshot of the Appearances window while editing Avatar Physics and has the button "Save As" on the far left. Picture B is a screenshot of your recently refreshed Appearances window where you did away with the Split button and has "Save" as the first button on the far left... Also, keep in mind that the latter used to be a Split button... Do you still not see an issue with this? I've nearly overwritten an outfit i was editing because i was so used throughout the years that there is a Split button but you replaced that with a full "Save" button. To keep the confusion real, you left the "Save As" button for editing Physics on that same location. Simply amazing... Dear Lindenlab. I am fully aware of the fact that i can sound very demeaning and degrading, but i want you to know this is not my intend. However, I ask you. How well do you think things through before you implement changes? This is a sincere question and i'd like you to answer me this. I guarantee you that users will overwrite existing Outfits because of muscle memory and they will hit the edge of your newly placed full Save button knowing from the past that it was a split button. I understand you want to simplify your UI, i'm all for that and more power to you for it. But i ask you, please think things through before you make changes. Think for example of how long a function/button is there for, does it cause issues? Is it misplaced and have a lot of people asked for it to change. In this case i see none of that. Its a real sad shame that people grid wide talk about these things when LL changed something again when nobody asked for it. And in this example you've set yourself up for user frustration. I promise you, you will have people overwriting outfits and they will complain. Eventually i will do it as well and i'll be cursing in my native language and feel lucky you won't be able to hear it or understand it. It's F*ing nasty. Recap: You added a button last year with the same look of a previous one, yet the new one acts differently. you removed the first (years old) button and put its 2 functions in separate buttons where the save button is now overlapping a space in your program where muske memory lies, where users are used to click to get the save as button (edge of the Split button) opening up the potential for outfits to be overwritten without warning. You made sure the confusion stays by keeping a Save As button in the same place when editing Physics using the same window. If i do such things in my RL job, i will get away with it once, and my company will have to release a patch to fix my f*ck-up. Next time i do this, i will be looking through the job applications... Caith Out.