Fenix Eldritch

It is definitely botched. Look at this line again from your previous post: See how you have "secondlife:///app/group/" twice? That's going to get jammed together into one big string which results in an incorrectly formed SLurl. Same with the "/about". You have it listed twice on the same line. It's like if I tried to type in a web page url of "http://http://secondlife.com.com"

Ok, what we have here is a miscommunication. I thought you were saying runtime error that resulted in a crash. That's on me for misreading it. What you appear to be talking about is the situation when the viewer's URI namespace is malformed. You're getting that "SLurl you click on is not supported" message not because you typed in a key as a string, but because you botched the formation of the SLurl in the first place. The above attempt is always going to fail because you've got the format wrong. You're including some duplicate parts of the viewer URI namespace. Try this and it works fine: llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "b91a5bf4-d0f9-f2bb-1cfd-8a0e3ffa0d34" + "/about"); It's the same UUID from your example, but without the extra "secondlife:///app/group/" and extra "/about" . That correctly resolves to the group "timelady of gallifrey" without issues. So the problem you saw was not caused by inputting the key as a string.

Please post the full example script where you get this to happen. I've tried to replicate what you claim, but each attempt successfully prints out the group link in chat. I'm not seeing a runtime error. Even supplying a bogus uuid (as a key or string) still does not produce a runtime error for me. default { state_entry() { list info = llGetObjectDetails(llGetKey(), [OBJECT_GROUP]); llOwnerSay(llList2String(info,0)); //I used Bay City Alliance group, uuid was "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e" } touch_start(integer total_number) { key agent = llGetOwner(); key groupKey = "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e"; string groupString = "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e"; llRegionSayTo(agent,0,"1. secondlife:///app/group/" + (string) groupKey + "/about"); //control llRegionSayTo(agent,0,"2. secondlife:///app/group/" + groupString + "/about"); //using string variable llRegionSayTo(agent,0,"3. secondlife:///app/group/" + "ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e" + "/about"); //flat text 1 llRegionSayTo(agent,0,"4. secondlife:///app/group/ddb90c8d-0bc5-9bf5-0ede-e063d1d7625e/about"); //flat text 2 } }

As Rolig suggested, perhaps start out with a general plan for your story first. Having a direction can greatly help you focus your scripting efforts. That said, if you're just starting out scripting, I would again strongly advise you start out tinkering with small projects to get practice with programming in general. The wiki has some starting points you can use. Two off the top of my head are: http://wiki.secondlife.com/wiki/Getting_started_with_LSL http://wiki.secondlife.com/wiki/A_Basic_LSL_Tutorial As you practice with scripting and flesh out your narrative, I imagine there will be a lot of back and forth revisions based on what you find you can (and cannot) accomplish within the confines of LSL. It will be an iterative process.

You mention that your concept is to have players collect clues and that these clues would then be used to activate story events. So at a basic level, you would want to structure your sim to be a series of choreographed scenes that can be activated by players when said players meet some arbitrary requirements. As an example, a door will only unlock if the player finds a key hidden elsewhere. You could make it such that the key is a static prop in-world and when clicked upon, it signals the player's hud that they've "collected" it. In actuality, the player's HUD script could set a variable to signify this player has collected the key, rather than actually taking it into inventory. Then, when the player goes to that locked door, the hud would communicate to the door that this player has the necessary key and the door will then respond accordingly. Using Experiences can indeed be helpful in this regard as their database of key-value-pairs can be leveraged as a virtual inventory for the huds and in-world game objects to check against. Again, using the same example from above, when the player joins the experience, they could be given an entry into the experience's database. This would in effect represent their "save file" as it were. When the player finds the key, their HUD could signal the KVP database to update their entry with information indicating they now have acquired this item. Then, when they go to interact with the door, that door can check the player's KVP entry in the experience database and see if they have the key and respond accordingly. The benefit is that with a central database, all of the sim objects can easily access player data and vice versa. That is a very simplified overview of one way you might want to approach this task. The real deal would require a lot of coordination between the scripts and fail-safes, and so forth. Though I should point out that if you aren't very experienced with scripting, you would want to start out smaller with bite-sized projects and build up to something more complex like this sim-wide adventure. It's certainly doable, but not easy for a beginner. If you are a premium member, you can claim one free experience for yourself and experiment with it to get practice. The wiki will have information on how to make use of the various lsl functions (Category: Experience Tools). And if you get stuck, you can post your progress and we'll offer advice.

Depending on the kind of weapon... you might try a llVolumeDetect projectile, which makes the object a sort of phantom, but will still register collision_start events. Oh! I forgot about llCastRay too. It works like a laser tripwire.. for a single pulse anyway. You could use that in a stationary location, or in a moving one. Edit: I forgot to add that having your target catch fire might be getting into potential griefing territory if not done extremely carefully. A safe way to do this could be requiring the participating avatars to wear a fire attachment that can be activated when it receives a signal from the spark emitter.

Sadly no, particles can not be interacted with in that way. But if the shower of spark particles being emitted by the object is in a static location, you could use an invisible prim to serve as a collision detector.

I was going to make a similar comment about the possible loopholes for just testing what face was clicked. If you wanted to be sure the avatar was truly in the cage, one approach could be to test if their position was within the bounding box of the cage. One way to find this is by using the function llGetBoundingBox. The wiki page has a few examples you might be able to incorporate. The user defined function isInPrim in particular my be helpful to you.

Yes, what you describe is quite possible within LSL. And as you will see, there are many ways to approach solving problems. Speaking to your example about multiple people clicking a single object together, let's take a look at the touch event. This event will continually trigger as long as the object containing the script is being clicked on - as in, the user hovers their mouse over the object and holds down the left mouse button. The event handler comes bundled with an integer variable, usually depicted as "num_detected". This represents the number of users who are currently clicking on the object at this exact point in time. Other functions exist to use these as indexes to reference the avatars touching it, but you can simply test if the number is equal to or greater than the desired value in order to trigger another effect. For example: default { touch(integer num_detected) { if (num_detected >= 2) { llSay(0,"Two or more people are currently clicking on me!"); } } } The wiki as a lot of good beginner tutorials you can peruse to get familiar with scripting in LSL. It's often best to start out with small projects before jumping into something large and complex. http://wiki.secondlife.com/wiki/Category:LSL_Tutorials

That surprised me, I had no idea looping sound was in fact a prim property. But I just tried it now and sure enough, Wulfie and Qie are correct! Is this documented somewhere? I wasn't able to find any references to this on the wiki.

Sadly, this is not possible. There are currently no "linked" functions that allow you to play/trigger a sound from a different child prim. At present, you must use a script and that script will only allow you to emit sounds from the prim in which said script resides. Regarding your specific example, I can only assume that the script controlling the sound was hidden in some other nearby child prim.

Interesting! I tried to do this with llSetObjectName and a string that would contain the character, but I'm not sure if I am doing it right... Does the sequence ALT + 127 produce the actual DEL character? All I get is a little house symbol ( ⌂ ) which in the resulting object name becomes ?? as outlined by the wiki caveats. But that's the same as with other characters - should I be expecting a different outcome specifically for the DEL character? Or did I misunderstand you?

Pretty much. The memory consumed by a script can be divided into two general categories. You have the area of memory that stores the compiled bytecode of the script - colloquially called the "heap". It is static and does not normally change unless you recompile the code. The other area is used for scratch work, storing variable contents, saving pointers when functions are called, etc - colloquially called the "stack". This area is dynamic and can grow and shrink during runtime. Both the stack and heap must co-exist in the chunk of memory allocated to the script, by staying in their respective corners. If the stack gets too big, the script crashes. This kind of error is called a "stack-heap collision" because the stack literally grew so big, it spilled over into the area that was supposed to be reserved for the heap. As an example, if you have a script that stores the name of nearby avatars into a list, that list can potentially keep growing. If left unchecked (and coded in such a way that you keep adding to the same list), it will eventually consume all the memory allocated to the script and crash. Lists aren't the only way this can happen too. Similar scenarios can befall strings, and even scripts that get stuck in infinite recursive function call loop and never bottom out.

My first thought would have been to look at the limits page - but it doesn't appear to have this information listed. Failing that, I looked up llSetObjectName to see if it had any restriction - and it does. Specifically: Now although this is in relation to object names, I'm making an assumption that scripts might share similar restrictions - since both objects and scripts can be referenced in similar ways via object inventory. I am not able to get inworld to verify right now, but if anyone could do that, I'd appreciate it.

In addition to what's already be said, if you are interested in making measurements of the speed and memory usage of variables vs lists, there are a few wiki pages that can aid you. http://wiki.secondlife.com/wiki/LSL_Script_Efficiency This page has a section that provides a sample script which you can use to measure how fast a snippet of code runs. Ideally, you should only attempt this in an otherwise empty sim with no other people nor scripted objects (rezzed or attached) in it. An isolated sim with no connected regions would be best - to minimize the possibility of objects/avatars waltzing in. Also ensure your avatar is seated, so as to avoid the simulator spending resources to process any movement. http://wiki.secondlife.com/wiki/LSL_Script_Memory This page lists the results of testing done by others in an attempt to measure how much memory is consumed by various actions, including variable usage. Though by the page's own admission, the accuracy of those measurements are not absolute, so take them with a grain of salt. For memory measuring, you would want to look into the function llGetUsedMemory before and after using the bit of code you wish to measure. Another option is llScriptProfiler, though that focuses on the overall script's memory usage during the profiling session.

Granted, but now the glitter is everywhere else. I wish the Linden street lamps outside my home shut off during the daytime.

It's hard to say without seeing the script's code... I'm making assumptions about how the open source texture HUD actually works. If you can post the code, or at least post a link to where you got it, we may be able to get a better idea of what's going on and advise accordingly. All I can say for certain is that the picture you posted of the dress shows that the ruffles and collar are using individual faces (aka material slots). That would mean it should be possible to set them to use different textures and/or colors independently of the rest of the dress. How to exactly do that is dependent on how the HUD communicates the update signal to the relay in the dress. If you have edit access to the HUD script, I believe it should be possible to customize it such that the single button click will send several updates to the dress, one for the base, one for the ruffles, and one for the collar for example. But again, we'd need to see more of the script you're using in order to help you modify it.

The code you've provided looks to just be a few variables and not the whole script... it would be helpful to see the rest of the script so we could suggest how to alter the behavior. If I were to guess, I imagine the hud script takes the variables listed above and combines them into a string (separating each value by a instance of the SR variable) and then speaks it on the listed channel. The receiving script in the dress listens for that message, splits the string up and uses the values in various set color/texture function calls. So I imagine the message spoken by the hud has a fixed order which must be maintained. However, if it's allowing you to specify texture, link number and face number in a single call, then you can probably send multiple messages, one for each face, and for each child prim in the dress. That would allow you greater control. The key is that you would alter the "face" value each time to target the corresponding face on the dress. "ALL_SIDES" is a special value that, as the name suggests, will make the modification apply to all sides of the prim. But again, it would be helpful to see more of the hud script.

Look at it this way: it could very well be a user error, but we don't yet have that information definitively. We don't know the exact conditions under which ItHadToComeToThis experienced their unexpected results. Again, it could have resulted from user error, but we don't know just yet. Rather than dismiss them out of hand and assume they tripped over the repeats/rotation caveat, I'd like to verify a little deeper. You may believe it's a waste of time, which is fine. I'm the one asking for the extra info, so it's my time to waste. Even if it ultimately turns out to be user error, it nothing else, it may help ItHadToComeToThis come away with a better understanding of the function and let them feel comfortable using it again. I'd say that's worth the time spent investigating.

Hence why I asked them to clarify. I wanted to see if it was a misunderstanding or an actual issue. There is no harm in performing a sanity check.

That does sound peculiar... I also wonuldn't expect screen resolution should have an effect on the results of llDetectedTouchUV. What issues did you see? Is this something you can still reproduce? If so, list the steps - I want to see if I can hit the problem too. If either of us can reliably reproduce the problem, it would be worth creating a jira bug report. The wiki page for llDetectedTouchUV does mention that the returned results will be different if the face's repeats and/or rotation settings are not at the default values, but I'm assuming you had already taken that into account, correct?

As a sidenote regarding the understanding of quaternions, there is a thread in the LSL Library forum which links to a video about them. I've been meaning to watch it, and I hear it's pretty good at explaining how they work.

I agree with Wulfie, if your intent is to use the texture animation functions to smoothly scroll an image across a prim face, you must use a texture which has been created/edited to not have a visible seam at its edges. This must be done outside of SL prior to uploading the image. Having said that, there are other approaches you could try to make a faux scrolling backdrop even if you don't have access to perfectly seamless textures. But they require some more work to hide the seams. As an example, instead of a single prim canvas, you could construct a diorama for your backdrop with props like telephone poles at regular intervals - especially at the edges of the canvas where the texture edges would fall. Using multiple copies of this diorama, you could script them to use key framed movement to non-physically slide themselves past the train car windows. Once one section has moved out of view, the KFM would put it back at the front, ready to slide past the windows again in a forever looping motion, similar to how the segments of an escalator move. The key here is that the edges of the backdrop texture would be obscured by linked props and thus help hide the obvious edge from casual observation.

Yep, a combo of custom gestures that speak commands on a hidden channel for another object to listen for and act on is one work around. Not as responsive as a true control event, but it's at least something. Regarding the actual controls, they use bitfields, meaning you could theoretically have up to 31 unique controls to capture. Currently 10 are implemented. So there is probably (at least as I understand it) room to expand.

Alas, it has been an often requested feature for a long time to have additional key inputs that LSL can detect. But as Rolig states, what you see in llTakeControls is all we have at the moment. However.... there is jira request to add in an "X action key", which apparently was implemented for the Oculus Viewer. I don't know much about how it worked, but I presume /hope if expanded it might extend to getting a proper LSL constant assigned to it for use in scripts.That jira appears to be in an accepted state, so it may actually happen... some day. And I've also made my own jira request for a few more control inputs as well. That jira has been in a "been triaged" state for a while. I don't know if that's good or bad, but I'm afraid to poke it, lest it get knocked into a rejected state.