Fenix Eldritch

You could move the script into a different child prim - anything other than the root should suffice in this scenario. I am a bit puzzled why you're using an unpacking mechanism if you don't want the contents of the root prim to be given to the user. Are there other contents in the HUD's root that you do want transferred during the unpack? If not... is unpacking even necessary? I don't have a complete picture of what's going on, so I can't really suggest more beyond moving the script to a child prim.

At first glance, it sounds like the script was placed into the package's inventory instead of the HUD's inventory.

Additional control inputs are sorely needed. Of the ten controls detected by LSL, I'd say about eight of them are needed for basic navigation. That doesn't leave us much room for additional actions and we usually have to resort to sacrificing existing controls for them instead. I made a feature suggestion a while back that proposed adding LSL hooks to detect the F, Q, Z, and X keys and right-click when in mouselook. The jira hasn't been rejected but has instead been in "Been Triaged" for a long time. I'm... optimistic that's a positive sign.

If I may suggest another approach: Give your target prims the same name but then differentiate them by giving each one a unique description i.e. "left" or "right". That way, you could set your sensor to look for all objects named "Corner Setter" and then inspect each detected prim's description with llGetObjectDetails to figure out if it was the left or right variant.

I just tried creating/saving a script on the PATH9 region in the Aditi grid and had no issue. Perhaps the problem is with the specific region(s) you are in when attempting to save the script... have you seen this on multiple different regions? Based on that error message, my guess is that the region is having some kind of network issues with the asset server. If this has been going on for some time, you might want to consider creating a bug report on the JIRA to let the developers know.

A poor choice on my part. You are of course, right. I'll try better next time.

No idea to be honest... it just irked me a bit

I suppose one message every 10 seconds isn't horrible, but yes I think it's preferable to not send the message at all when it isn't necessary - much like you already do in the sensor event. You only send the "click to show" message the first time you detect a nearby avatar. If SombodyNear equals 1, then you don't send the message. This avoids repeatedly sending the message when an avatar lingers within range of multiple sensor sweeps.

That code... is doing things in a very round-about way. Instead of calling a timer to repeatedly call a single sensor, consider using llSensorRepeat which will start a repeating sensor. As for the message spam, you're communicating on channel 0... You could switch to using a different channel number and it won't be seen in local chat. Alternatively, consider using llRegionSayTo which sends the message directly to the target and no one else. Edit: Another way to stop the spam entirely is to add an if condition to your no_sensor event. If somebodyNear equals 1, then say hide and set somebodyNear=0. Else do nothing. The idea is that if the poseballs are already hidden, it's redundant to re-send the hide command. Only bother doing it if they're currently visible.

llSetAnimationOverride is used to permanently (well almost permanently) alter the default animation which plays for a given avatar state - like walking, running, flying, etc. It was designed to be a more efficient replacement to the traditional AOs which were very resource heavy with their constant polling of the avatar's state. The changes made by llSetAnimationOverride will survive through everything - even removing the script that started it. The only thing that stops the override is calling llResetAnimationOverride or relogging. Using llSetAnimationOverride to overcome an existing AO can potentially be dangerous as Wulfie states. If the AO itself uses the override function, you are effectively replacing their default animations - as each animation state may only have one override defined at a time. Even if your project resets its override, that won't restore the AO's override. Best case scenario the AO will likely need to be reset to re-apply its own override. Regardless of which AO method an avatar uses, the priority of the animation is still in effect. In other words, if you are currently playing a high priority animation and want to start a lower one (which affects the same joints), you'll need to stop the higher priority before the other will be seen

Oh geeze... All this time I've been operating under a bunch of misconceptions. I thought that the heap only contained the complied (static) bytecode and the rest was handled by the stack. Clearly that's not the case - as explained by Rider. So regarding local variables... (correct me if I misspeak) once declared, they go on to the stack with whatever value they were initialized with. For data types like integer, float, key, etc, they can be updated in place on the stack without needing anything from the heap. I presume the system maintains an internal offset to reference them in the stack directly, yes? But for types like lists (and I suppose strings?), any update to them is handled by the heap... what happens if you initialize a local list with some values an then set it to equal an empty list? Does that mean the stack will get updated in place to be an empty list in addition to releasing whatever extra heap memory it previously used?

Maybe I'm missing something, but doesn't the original script already do what you ask? Rolig's else-if is much cleaner logic-wise, but assuming the message being sent is either "+" or "-", the either code samples will happily add or subtract from the total and if the resulting total would be 6, it moves to the win state. Are you expecting something different?

Yes, it sounds like something might have gone wrong during your upload. Maybe you forgot to select the physics model, or maybe there was some error. Hard to say, but regardless, if your mesh doesn't give you the option to set its physics type to "prim" in the build tool, then that suggests it doesn't have any physics shape of its own to begin with. As such, it must default to the auto generated convex hull. For completeness sake, regarding the three physics types: PRIM - makes the prims use their traditional physics shapes. For mesh, it makes them use the physics shape you uploaded it with (if present). CONVEX HULL - a simplified, auto-generated shape that fully encases the object based on visual appearance. Like very low resolution shrink-wrap. Useful for reducing physics land impact at the cost of covering up holes and the like. NONE - no physics shape. Can't be set on the roots of objects. And I suppose I should also mention that for mesh related questions, it's a good idea to start in the dedicated Mesh forum. To be fair, it is possible for a script to explicitly change an object's physics type, but I'd first rule out any potential problems with the mesh itself before looking at the script.

Assuming you uploaded your mesh correctly, it sounds like the physics type property of the prim/mesh is still set to convex hull. Select the individual part in the build tool and check that its physics type is set to "PRIM". It should be in the Features tab of the build tool. LSL reference: http://wiki.secondlife.com/wiki/PRIM_PHYSICS_SHAPE_TYPE Edit: see this page for some additional information: http://wiki.secondlife.com/wiki/Physics_Optimization

Hypothetically speaking, you could set up a system where you have a timer loop that automatically does the following: close the previous listen handler increment the target channel value open a listen to that channel (to listen for any potential response) speak the test message on the current channel repeat The idea is that you prime the test script by starting a 0, opening a listen, and then dropping into a loop governed by a timer event. That way, if you do manage to find that needle in the haystack, the target object will respond and your own test script's listen event will hear that response. Upon doing so, the test script will stop the timer and report to you the value of the channel it used. And then for the negative values, just change the channel increment to a channel decrement as Rolig demonstrated above.

Do you have edit access to the other object's script? I'm guessing that either you don't, or if you do, that the script is not using a hard-coded value for the channel - but instead generating it randomly. Also, do you know how this object will react when it hears something on the channel it listens to? Does it speak? I ask because if it emits its own text chat, you can potentially automate the process and use that as a shutoff signal - stopping when you get the right channel.

Granted, you don't have to cater to those people at work. Now it's during your off time. I wish I had some ice cream right now.

I notice that your function uses a loop, but Haravikk's function does not. That might give their code an edge over yours, since you have to spend additional resources looping through the string to break it up. Haravikk's code on the other hand lets llDumpList2String do the dirty work. But to truly know which is better, you should do additional tests, with different sample inputs and look at the averages. You can find a speed tester on the wiki here: http://wiki.secondlife.com/wiki/LSL_Script_Efficiency#How_Fast_Does_That_Code_Run

I'm being a bit slow today, having trouble fully comprehending the flow of the code. But there are a few thoughts that come to mind. Your code has three instances of calling llDie and another three instances that call llDetatchFromAvatar. Either of these will potentially remove the temp attachment. So I would suggest you add some instrumentation code to see if any of those are being called when you teleport. Basically, stick a llOwnerSay("debug message") line immediately before each llDie and llDetatchFromAvatar function call. Give each one a unique message. This will help indicate which (if any) of these lines are being called when you teleport and narrow down where the problem is occurring. Now if it turns out that none of the above are being called when you teleport, then the issue may be with the other two scripts you say are being added to the prop. You may need to examine them to make sure they're not calling their own llDie or llDetachFromAvatar.

I'm not sure I quite understand what the [AV]object script is supposed to do... don't temp attached objects remain attached normally through teleports? I thought only a logoff would remove them? However, I glanced over the code and the first thing that jumps out at me is your use of llDetectedKey(0). That function only returns meaningful results when used in a few very specific events. From the wiki page: So your error is probably occurring when you try to feed it into the llRequestPermissions function inside your listen and timer events. Perhaps you could replace that with llDetectedKey in those events with llGetOwner, since an object has to be owned by the avatar wearing it. And in the case of temp attach, ownership is transferred to the new target for the duration of the temp attachment's worn existence.

This sounds like it would be similar to a gun script - in that the avatar would create a projectile (bowling ball in this case) and "shoot" it forward relative to the direction they are currently facing in mouselook. The extra catch here is that you'd like to alter the strength of the throw based on how long the user holds the button before firing. Does this sound accurate? Assuming this is what you're trying to do, then you would need to study the control event, as this that would be what is responding to the user's button presses. The control event triggers whenever a button is pressed, whenever a button is released, and also continuously while a button as being held down. This can be used to suit your needs quite easily. Generally speaking, you would configure your control event to increment a "power" variable while the user holds down the desired button and then, when the user releases the button, you would "fire" the projectile using the current value of the power variable. You'd also want to reset the power variable to zero when the projectile is fired, to get ready for the next shot. Visually speaking, I imagine the avatar would wear a bowling ball as an attachment in their hand. This would effectively be the "gun". When the player "throws" the ball, the worn attachment turns itself invisible and rezzes the projectile bowling ball simultaneously to simulate the effect of them throwing it out of their hands.

Blue... No, yeeeaaaagh!

The LSL Scripting forum is more geared towards discussions about scripting and between people trying to write scripts themselves. If you wish to hire someone to write a script, you'll get better responses by asking in Inworld Employment forum.

OP's question has been answered, but I'd like to add one last bit of info for completeness sake. As we can see in the wiki page Qie referenced above, there are a number of internal animations in SL that have additional effects associated with them. In this case, playing the "away" animation will also trigger the "Away" status to be displayed in an avatar's nametag. These additional effects are hardcoded into the viewer (and server?) and not contained within the animation file itself. As such, if you download the animation files and try uploading new copies, they will not trigger those additional effects as listed in the wiki page. Only the internal animations already built into SL will trigger the additional effects. But you can reference them by name without needing to have the assets in your object's inventory (as Qie demonstrated above).