Fenix Eldritch

Hello, Vanessa. Could you elaborate a little more on what you're trying to achieve? Your request is unclear to me... If I were to hazard a guess, it sounds like you're asking if there's a way to put on and take off worn mesh objects via script/hud? If that's what you're asking for, then it is possible, though with some limitations. A brief example on how to approach this would be using a hud that stores the mesh attachments in the hud's own inventory. When triggered, the hud would rez thje objects in-world. In turn, those objects would have their own script which would request permission to attach and then issue the llAttachToAvatarTemp command, targeting your avatar. This effectively wears the object. To undress, or take the object off via scripted control, the object's script would also have code to set up a listener and listen for some signal (probably from the hud). When it hears the signal, the script could then issue the llDetatchFromAvatar command to detatch the object. By using the temp attach function, you avoid creating duplicate items in your avatar's inventory - since temp attached objects don't produce one and are completely deleted upon detach. There may be other ways to do this too, this was just off the top of my head. And if I've misunderstood your intent, please let me know. And as ItHadToComeToThis points out, if you're more interested in contracting a scripter to create the thing for you, the wanted forums would be a better place to ask. This forum is more focused on helping people write their own scripts. Good luck!

You know as well as I do that there are multiple ways to achieve that goal. KT offered an alternative method that prevents adding the problematic string in the first place. It is equally as valid as removing the list entry after the fact. Neither approaches are "wrong" as you claimed. Furthermore, your assessment that KT's code would "just add a lower case converted entry" to the list is flat out false and suggested to me you didn't understand what it was intending to do. But I already can see where this conversation is headed, so I'll bow out now since the OP has their answer.

KT's suggested code is fine, I think you've misunderstood what it's doing. The actual variable contents_name is not being updated or assigned anything new. The to lower conversion only exists within the scope of the conditional test. The whole point is to see if substringindex is able to locate "freya". Since the match needs to be case insensitive, we can make the test easier by converting a copy of the string to lower and checking for that. If substringindex fails to locate the substringstring, then the function returns -1. So if -1 == -1, then we know that the variable contents_name did not contain an instance of "freya" (or "Freya" or "FREYA" etc etc) and is therefore safe to add to the list.

Show us what you tried with the touch event. Post the code and we'll have a look.

Aww dang, sorry I misunderstood you again. I'm 0 for 3 on this one I believe you can inject a script into a target object using something like llRemoteLoadScriptPin... but if your ultimate goal is to just update the particle parameters for specific prims in several worn attachments, I honestly believe something like a more basic communication protocol might be a better (or at least less complex) approach. Consider this: Suppose you have an object like a HUD that will act as the controller. This HUD will have a script that contains the particle parameters list in memory. You can make whatever edits you want to the list there and then save. The HUD script would also have code to broadcast the list to your other attachments when prompted (such as when you type a chat command, or even automatically when the script starts after being compiled). Meanwhile, your separate leg attachments will each have a script which listens for the broadcast message from the HUD. When they hear the message, they convert the incoming string to a list and then use that list for the particle command. That way, you don't need to juggle scripts and only need to make the update in one place.

You could define a global string variable and replace llSay(0,""+message); line with an assignment to the global variable. Then, in your new touch_start event, simply write the llSay command using the global variable.

I had the opportunity to meet up with MajorCooke in-world and after some discussion and demos, I think we eventually realized the source of our confusion. It seems MajorCooke was under the impression that changes made to objects in-world would retroactively be applied to the objects in her avatar's inventory that the in-world instances were rezzed from. She didn't realize that they were all separate instances that could not influence each other. This did lead to a discussion about using a another master object (like a HUD) to communicate with and update any already rezzed/worn instances. I believe that path is where she'd like to explore. To that end, the wiki would be a good place to start: http://wiki.secondlife.com/wiki/Category:LSL_Communications http://wiki.secondlife.com/wiki/Dialog_Menus https://community.secondlife.com/knowledgebase/english/heads-up-displays-huds-r34/

Forgive me if I've misunderstood, but if this is all just to keep the particles constantly running when someone wears the attachment, then none of this is necessary. Because particles are a permanent prim property. That basically means once you start the particles on a prim, they will stay running forever** until you explicitly stop them by re-issuing the particle function with an empty list - which is exactly what your particle-remover script does). You can take the object into inventory, rez it, wear it, even delete the script that started the particles, and they will continue to be emitted until you overwrite them with a new particle parameter list (or an empty one). **unless the PYS_SRC_MAX_AGE parameter is something other than zero, but that's not the case in your example. I'm also confused why you mean by auto-updating. Are you intending to allow the user to turn the particles on an off? Or change the particles to another set? If so, then that is a different matter. That's certainly possible to do, but we need to fully understand your intent before we can offer advice. Enclosed is a little test script for you to experiment with. It uses the same particle list you provided earlier, but shows how you can toggle them on and off from a single script. Create an object that comprises of at least three prims. Link them together and then drop this script into it and click the object to see what happens. //create an object of 3 linked prims. Place this script in the root and click any prim to toggle the particles on and off. integer toggle = FALSE; //used to keep track of the on/off switch list particleList; //used to hold the particle parameters default { state_entry() //this state is run whenever you restart (or recompile) the script) { // define the particle parameters list at the start. We'll reuse it later. particleList = [ PSYS_PART_FLAGS, PSYS_PART_EMISSIVE_MASK|PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK, PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE, PSYS_SRC_BURST_RADIUS, 0.200000, PSYS_SRC_ANGLE_BEGIN, -2.5, PSYS_SRC_ANGLE_END, 2.5, PSYS_PART_START_COLOR, <1.00000, 0.70000, 0.00000>, PSYS_PART_END_COLOR, <1.00000, 0.50000, 0.00000>, PSYS_PART_START_ALPHA, 1.000000, PSYS_PART_END_ALPHA,0.000000, PSYS_PART_START_SCALE, <0.20000, 0.20000, 0.00000>, PSYS_PART_END_SCALE, <0.01000, 0.01000, 0.00000>, PSYS_SRC_MAX_AGE, 0.000000, PSYS_PART_MAX_AGE, 1.000000, PSYS_SRC_TEXTURE, "e6c7b1f4-5428-04fd-4c4f-42a789f08625", PSYS_SRC_BURST_RATE, 0.000000, PSYS_SRC_BURST_PART_COUNT, 999, PSYS_SRC_ACCEL, <0.00000, 0.00000, 0.75000>, PSYS_SRC_BURST_SPEED_MIN, 0.500000, PSYS_SRC_BURST_SPEED_MAX, 0.500000 ]; llLinkParticleSystem(LINK_SET, []); //scrub particles from all prims in entire link set. } touch_start(integer total_number) //this state is run whenever you click on any of the prims in the linkset { if(toggle == TRUE) { llOwnerSay("turning off particles"); llLinkParticleSystem( 2, []); //target child prim #2 llLinkParticleSystem( 3, []); //target child prim #3 toggle = FALSE; } else { llOwnerSay("turning on particles"); llLinkParticleSystem( 2, particleList); //target child prim #2 llLinkParticleSystem( 3, particleList); //target child prim #3 toggle = TRUE; } } }

Maybe I should back up and get a little more context... Are you saying you have multiple different particle scripts, and you want to periodically switch them out on your attachment? Or is something breaking and you find you need to restart the particles for some reason? I'm a little unclear. Regarding the other things mentioned, if you're still having trouble selecting a child prim in a link set, I think you can use the following keyboard shortcuts to iterate over each child prim: Select the "next" link with Ctrl+. Select the "previous" link with Ctrl+, There's also a shortcut to highlight transparent objects with Ctrl+Alt+T As for the syntax, the only difference in between llParticleSystem and the linked version is that the linked version takes an extra parameter before the list: llLinkParticleSystem( x, [rules-list]); Where x is the link number of the target child prim. Check out the wiki pages linked earlier for all the details. As for discovering the link ID (aka link number), that is based on the order in which you linked all the prims together, with the last one being the root (and thus having a link number of 1). You can use the example code shown on the wiki page for llDetectedLinkNumber to report the link number of the child prim when clicked. But be aware that if you unlink everything and then re-link, the link numbers will very likely change - unless you meticulously link everything in exactly the same order. There are other ways to discover the desired link number of a child prim, but I want to get a clearer picture of this scenario before we go down that path..

You can change the particles of a prim by issuing one of the LSL commands (llParticleSystem or llLinkParticleSystem) with either an empty list - which will turn the particles off, or a new list - which will override any existing setting. But, you shouldn't even need to unlink anything in the first place. If you need to target a child prim (for example, to access its inventory to get at a script), you can select the "Edit Linked" checkbox in the build tool to only select individual prims of a linkset instead of the root. That said, if you have edit access to the primary scripts, you can make use of the various "linked" LSL functions that allow your script to target other prims in the linkset, no matter which prim the script is actually in. This makes things a lot easier to manage, as you don't need to use multiple scripts (and having less scripts is usually preferable for performance). So for example, you may want to consider re-writing your main particle script to make use of llLinkParticleSystem, which take the standard list of parameters and a link number which will make it target that child prim.

If you do use the control event, take care that you structure your tests/checks to only respond to the initial key press and final key release. Otherwise you may get into a situation where your script is constantly restarting the animate ball code - because the control event will continuously be called as long as any captured key is depressed.

I sort of have this very light RP going on with my community where my current in-world persona is a clockwork robot created to look after my avatar's workshop while they are out on an extended expedition. I wanted to present the character as a primitive construct, using very distinctive speech patterns (I'd end most of my feed posts with "End of Line") but I kinda feel out of practice with it. I do want to pick it back up though. One of the things I did consider, but never followed up on was speaking through an object like @Reyetta Claven mentioned. Is such a thing cumbersome to use? Did you make it yourself, of pick it up from a shop?

I like Rolig's approach with direct seating via the experience scripted sit commands. Out of curiosity, is there distance limit to how far away llSitOnLink can pull target avatars from? If there isn't, then we might be able to further simplify the example and omit the need to have the avatar sit on the departure prim, move it, and have the destination prim scan for the freshly moved avatar. Instead, you might be able to just relay the avatar's key to the destination script, and have it directly seat them in one swoop. I imagine it could be something like this (rough sequence) : user interacts with the departure prim, confirms they want to "teleport" departure prim sends user key to destination script destination script does some internal checks to verify it has an unoccupied target link to receive the user if so, destination script can just call llSitOnLink targeting the user and desired link else report back no seating available

Cool, thanks for those links! Ah those profile floaters take me back... I remember when we had the ratings built into them. From what I read on Inara's blog, it seems what will become of the feeds is up in the air. I hope LL manages to keep them going. Edit: ah maybe that's the "web" tab I just noticed?

That's indeed very odd. Out of curiosity, how were you determining that you had progressively less memory? Perhaps there were bugs with the functions used to report the available memory at the time? I found at least one old issue on the JIRA where llGetFreeMemory would report negative values. I suppose it's not impossible that you could have stumbled upon something like that and had it fixed? I dunno, it's complete conjecture on my part.

I presume they're referring to the size of the bytecode of the compiled script. The bytecode doesn't change unless you recompile the script. Less bytecode means you have more space available for the stack (working memory of the script during execution).

Oh, that's interesting! Do you have a link to where that was revealed? I'm curious to see any details about that switch. I always liked the look of the old profiles more than the web ones.

How disappointing. After going to such great lengths to avoid demonstrating the problem you claim to have, I am left wondering if you were just making it up, or trying to save face after some other user error. Oh well. You do you, I guess.

Skell's warning to be wary of random urls is solid advice. If you're curious about a link, it would be a good idea to copy the url and inspect it in a safe environment, like a notepad to make sure it doesn't lead to some malicious place. Having said that, the specific example you are speaking of can be accomplished though the Viewer URI Name Space (link is to the wiki page on it). Suffice to say, you can formulate a Second Life URL (SLurl) that when clicked in the viewer, will bring up the pay prompt window. Here is the syntax to replicate what you saw: [secondlife:///app/agent/paste-your-avatar-key-here/pay TIPJAR] Putting your avatar key in place of the "paste-your-avatar-key-here" segment will complete the SLurl. You can further format the SLur by placing a space after it with the text you want to appear as the link, and then enclosing the whole thing within brackets. The above example, when completed, will look like "TIPJAR" that you can click to bring up the pay-you prompt. Note that when I tested this, I wasn't able to get it to work with the web profiles screens. Though it did seem to work fine with the older profile pop-ups. I'm not sure if something different is needed for the web-profile floaters.

I'm assuming "your" way is the method of breaking up the SLurl into thee parts: "secondlife:///app/group/" key variable holding the group, cast to string "/about" And that the "other" way is by pasting in the raw key as string text instead of being contained in a variable, correct? Both ways work. But that's not the issue here. You claimed that if you replace the middle variable with the key value pasted in, you'd get an error with the SLurl. But the examples posted previously clearly show that doing the "other" way does work. What of those four keys you said you tested but did not work? Share them. I'm very curious to see how this supposed failure happens. Are you absolutely sure those keys are for group keys?

That doesn't even make sense. You're arguing that: Which over the course of this thread, we've proved that statement is not true. Then you claim that it only happens some times and provide flawed examples that turn out to be user error. The key you provide is a valid one for your own group. The implication being that this valid key would be able to cause the error - otherwise why use it? Then you claim that the corrected example still exhibits the problem. But refuse to show that code or what key you used Then you claim that you But again, you don't show the code, nor the keys used. You expect us to just take your word for it. Then you claim that another nameless scripter also has the same problem - again with absolutely no proof or references to corroborate what you say, just your word alone. If you want us to take you seriously, you have to provide something tangential we can work with. Otherwise, it's just baseless claims. Again if you have keys that you know to cause the error, share them with use so we can see the problem manifest in real time.

And why did it take you this long to reveal that little nugget? Seems like that would have been pretty pertinent to know from the start of this conversation. Please cite your source on that information. For LL to implement such a change that would break compatibility (which is something they normally try to minimize), I would expect to see some kind of announcement or at least comment about it. And if that truly was the case, why didn't you provide us with a known old-style key that should by your own logic produce the error every time?

Anecdotes and proof surrogates are not evidence. Why are you evading this? And if your capture method has had no issues, why are you getting inconsistent failures then? Doesn't that contradict what you just said minutes earlier?

Which is precisely why I want to see the actual code in question. I want to understand what's happening that could possibly be responsible for the results you're seeing. It might be a another innocent user error. It might be some previously unknown flaw in LSL (though I honestly am less inclined to think so). But the only way we can get a better understanding of whatever issue is going on is to all be on the same page. I mean no disrespect, but I simply can't take your word for it - not when I've seen and tested other examples that seem to contradict what you're saying. So again, please show us the code that is producing your error. I want to learn.

Uh uh. Look, the examples above have clearly established that if you post the group key as a string, the viewer has no problem resolving it into a functioning SLurl - providing there isn't some user error like in your previous example. I posted clear examples of it that anyone can replicate using the Bay City Alliance group, or even your own group. It does work. So if you still insist that supplying a valid group key in the form of a string into a valid SLurl somehow produces an error, then you must give us a working code example. Not an anecdote, but an actual working example that consistently fails in the way you claim. Please provide a complete code example so that no misunderstanding can occur.