Fenix Eldritch

Now that I think more about it, you're probably going to want to have each key produce a unique sound, so it would become important to actually distinguish one key from another - whether by linknumber or name as you started to do earlier. (Apologies for leading you in circles) Building on your latest script, you could give each piano key a unique name and then make the associated sound file have a matching name. That way when you play it, you would supply the name of the currently clicked prim as the sound's name.

Ah ha... whoops. Yes that would be rather important, wouldn't it? My mistake. There are a number of ways to approach this. You could use a compound IF statement that checks if KEY was equal to any of the desired linknumbers: if (KEY == 2 || KEY == 3 || etc...) Another way would be the give the piano keys a distinct name and check if the name of the currently pressed key was equal to that. See llGetLinkName. if (llGetLinkName(KEY) == "pianoKey")

Firstly, you don't need to have all those IF statements. You already know what the currently touched key is, so use that KEY variable like this: llSay(0, "Key "+(string)KEY+" pressed"); llSetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL]), 0) + <0.0, 0.0, 1.0>]); llSleep(1); llSetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL]), 0) + <0.0, 0.0, -1.0>]); This will make the code flexible enough to apply the position movement to whatever key was currently pressed without needing to check through every possible key. Secondly, you could use llSetLinkPrimitiveParamsFast which is a variant of the function that doesn't have a built in delay on top of the explicit sleeps you have.

Better than what? What have you tried first? Using llSetLinkPrimitiveParamsFast with the PRIM_POS_LOCAL constant and its associated parameters and targeting the clicked prim via llDetectedLinkNumber would be the typical approach.

As far as I'm aware, there is only one function that can remove inventory items: llRemoveInventory() - but its scope is confined to the prim in which the host script resides. This means the function can't target other prims in the linkset. That is a considerable limitation, but if you reeaaallly want to force it, there may be a workaround. It's not pretty though. Hypothetically speaking, I suppose you could accomplish this by writing your script in such a way that it would initiate a "delete everything plus myself last" loop when it receives a specific message command. Then use llRemoteLoadScriptPin to inject copy of that script into each linkset of the object. Then send the aforementioned signal (like llMessageLinked or something similar). When all scripts hear the signal, they begin the deletion loop and should in theory, clean themselves up last. But that's a lot of effort compared to the viewer's menu command. Is there a particular reason why you're aiming for a scripted solution? Edit: Whoops, I completely misread how llRemoteLoadScriptPin works. See Wulfie's post below.

llDetectedKey (and related functions) only work within a small subset of events - as per the wiki page specifications: So trying to use it in the run_time_permissions event won't work. If you want to reference the user's key that you detected in the touch_start event, you must store it in a global variable.

The problem is in your run_time_permissions event. You are trying to start the nextDance animation, but that variable has not yet been populated. run_time_permissions(integer perm) { if (perm & PERMISSION_TRIGGER_ANIMATION) { if (lastDance != "") llStopAnimation(lastDance); llStartAnimation(nextDance); lastDance = nextDance; } } When you reset your script, your code immediately requests animation permission, which queues up the above event and the first IF statement passes. At this point in time, no variables have been updated, so lastDance and nextDance are still empty. So the second IF test fails. However, that only prevents "llStopAnimation(lastDance)" from being executed. The other two lines after that are not part of the IF statement, so they will still run and that's why your script complains - it's trying to start an animation called "" but that doesn't exist. Did you mean to group those two lines within the second IF statement?

This is kinda a kludge, but if you have Copy/Trans permissions on the animation asset, could you send a copy to the NPC via llGiveInventory (along with a chat of the asset's name) ? When the NPC receives the inventory item and name, it can then operate on its own local copy and discard when finished.

I thought face numbers were defined by the order of the material slots on the source model? I haven't come across a situation where that order is not the same in the resulting uploaded mesh. And I have several character displaying 8-face meshes where the order would be readily apparent if they weren't what I expected... Have I just been lucky? Or is this specifically relating to uploading meshes with more that 8 material slots and letting the uploaded cut them up in 8-face parts however it pleases?

Most frequently on my home parcel/workshop. I like to have some of my in-progress projects setup for visitors to mess around with.

Does this imply that you do not have edit permissions on the copy you bought? If you can't edit the script, there there is no way to alter its behavior. On the other hand, if you can edit the script, but aren't allowed to publicly post it, then see below. A single script can only rez objects from its inventory one at a time. But you can call the function multiple times in succession to rez as many instances as you need (land impact allowing). Rezzing an object via the LSL functions llRezAtRoot or llRezObject causes the script to sleep for 0.1 seconds, so there will be a very slight delay between rezzing. Regarding the other point, there are two ways you can delete an object via script, either calling llDie, or setting the prim property PRIM_TEMP_ON_REZ to true. Temporary prims will delete themselves after about a minute. This property can also be set via the build tool by clicking the checkbox marked as such. If the objects being rezzed by your script keep self deleting, then it's possible they already have this temporary property set. In which case, you must edit that object and replace it in the rezzer's inventory with a non-temp version. And generally speaking, be careful not to cause prim litter by rezzing many objects that don't auto-delete. If you're doing this on land that is not your own, you could be abuse reported for griefing. Make sure you understand what you're aiming to do.

I suppose it would queue up another dataserver event which would then execute after the current one finishes (assuming the key was valid).

Not through LSL. However, your viewer/client has the ability to customize text color for various different chat sources. Should be in one of the Preferences tabs. Note that the color change would only be seen by you, since it's a local viewer setting.

Yep - because your HUD script, as currently written, only sends one message (the vanish signal) to the receiver. If you want to toggle it off/on, you need to add additional logic to the HUD script so that each time you click, it will alternate between sending the vanish signal, and a reappear signal. And in that regard, I would second Rolig's suggestion to consider using llSetLinkAlpha in the receiver instead of setting the texture to a full alpha image. By toggling the alpha parameter, you can make the target object/face invisible or visible without needing to keep track of the original texture.

It was an attempt to think of a possible workaround in the event that you didn't have edit access to the menu script. llDialog works by sending out the button text from the user and the script listens for that to act on. If that listen filter was broad enough, there is a slim chance that you could inject your own message from another script. But that depends on the menu script having a less restrictive (read: less secure) filter setup. Anyway it is moot since you do have edit access to the menu script after all. You will be making much more work for yourself in trying to slam two different scripts together. Since you already have edit access to the main menu script, I would advise you work towards adding your code to the menu script instead of using a secondary script. But before you can do that, you NEED to have an understanding on how the menu script is working in the first place. Study its touch_end event to see how it reacts to a user click. Step through each line of the code to follow where it goes. Understand how the menu script keeps track of the light's state and how it modifies it. When you understand all that, I believe it should become clearer how you can incorporate you additional code to the script. I'm guessing Sunbleached wants to have two different outcomes depending on what part of the vehicle is clicked. I suspect the current menu works when any part of the vehicle is clicked on - and they want to suppress that menu only when the specific prim/face to toggle the light is clicked. A simple branch (or short circuit return out of the touch_end event) would likely do the job. Providing they understand what the script is doing in the first place and map out what they want to do as you rightfully suggested.

I was operating under the assumption that you had access to the menu script and were trying to augment it with the manual light switch code. If you do have access to the script, study how the menu controls the light status (it will most likely be a global variable) and use the same hooks in your manual trigger code - and of course, add the code to the menu script. If on the other hand you do not have access to the menu script and are adding this functionality with a completely separate script, that changes things considerably. There will be an obvious disconnect between the two systems. Without knowing how the menu works, it may not be possible to make them coexist nicely. It might be possible, but you need to provide more information on how the existing script works. For example, is the menu using llDialog?

Yes it will still work. Clicking on a scripted object is divided into three stages: the touch_start event triggers once, right as the user initially presses the mouse button the touch event triggers continually as long as the user is holding down the mouse button (in other words it will loop) the touch_end event triggers once, right after the user lets go of the mouse button All this means is that your existing menu code apparently triggers at the end of a click, and your new code as currently written will trigger right at the start of a click. There's nothing necessarily "wrong" with that, though from a user experience, it may or may not feel intuitive - but that's subjective. You could just as easily put the new code in the touch_end event along with the other stuff. Or not - It's entirely up to you. In order to work with llDetectedLinkNumber, you need to know what the desired number is, similar to what you have done with the face index when using llDetectedTouchFace. The way I usually do is is to give the target child-prim a unique name and then run a loop to scan each item in the linkset for that name. Once found, store the index in a global variable and test against that where needed. The drawback to this is that you must re-run that loop if a new prim is linked or unlinked from the set - because it's then possible the target link index might change. However, Rolig's example above bypasses that completely. Instead of saving the link number in a global variable, she just checks if the child-prim that was just clicked has a name equal to whatever unique one you setup earlier. If so, continue on with the other stuff. If not, do nothing since it wasn't the desired child-prim. I never considered doing it that way before, so thanks for that, Rolig!

Oh yes, there are many examples of these kinds of vehicles throughout SL. There's even a wiki page on it. A few that come to mind are Yavapods Transit system in Bay City (boats in the canals, a trolley along the main road, and a few buses/taxis) Trams in the Paleo Quest Various mainland railroad groups Most of them have the same thing in common: a list of waypoints that they would navigate to through some means. In recent history, the concept of LSL Key Frammed movement has been implemented and is of particular use for these kinds of vehicles as it is a less laggy solution. Really well suited for following set paths that don't change much.

On its own, a change like this would likely be trivial as far as resources are concerned. I imagine a single if-statement in your touch_start event would suffice. You'd check if llDetectedLinkNumber and llDetectedTouchFace return the desired link and face index respectively and if so, toggle the light as demonstrated by Rolig's example.

Sounds like you'd want to look at the blending parameters. The wiki page has a section on it. And I believe the Particle Laboratory inworld might also have some demos or visual explanations you could study.

After you save/compile the script in the object, make sure that the "Running" checkbox is in fact checked. I have seen instances where it was turned off without my realizing it. Also, how far away from the object is your camera? Because sometimes sounds in SL tend to have a steep falloff as your viewport gets further away from the source. As a test, zoom your camera right up to the object and listen if you can hear the sound. Combine that with the other diagnostic instrumentation suggested by the others.

Accidental duplicate thread. See this thread which has several replies (including one from the original poster)

I don't think you'd need to split this into two scripts, you could use a function to work on the parsing and call it as needed. A great example of this can be seen in Rolig's dialog code in the script library: Once your scanner has populated the list of names, call Rolig's function to build the dialog.

The timescale parameters govern how long it takes in seconds for whatever associated attribute to take hold. So yes, smaller values generally make them more responsive. I find this quote from the Linden Vehicle tutorial helpful: As for the difference between the friction and motor decay parameters... Friction timescale is how long it takes friction to bring the vehicle to a stop - whether that's movement along the XYZ axes (linear) or rotating about its reference frame (angular). So a small value for your angular friction timescale would mean its rotations would quickly succumb to friction and therefore stop turning. See this section. Motor decay on the other hand is how long it takes the effectiveness of the motor to degrade to zero without any other intervention. Both of these parameters can be used together in different ways to achieve similar behaviors. Again, the Linden tutorial gives some examples:

Shoot, you're absolutely right. I got carried away in my extrapolations. I now recall other instances that clearly disprove my claim: a valid key by itself in a conditional will also evaluate as true so an implicit "==true"wouldn't make sense in that case. Thanks for the correction! Edited to add: The wiki page for IF statement has a neat table that I hadn't noticed before. It shows under what conditions the different variable types will evaluate as true. (I should have checked there in the first place ) Type Condition integer True if it is not zero. float True if it is not zero.[1] string True if its length is not zero. key True only if it is a valid key and not NULL_KEY. vector True if the vector is not ZERO_VECTOR. rotation True if the rotation is not ZERO_ROTATION. list True if the length is not zero.