Fenix Eldritch

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).

There was a similar problem reported on the bug tracker a few days ago. Though that user had problems removing interests which contained quotation marks. Even so, your problem could be related. https://jira.secondlife.com/browse/BUG-228079

Unless you specify a larger delay value via llMinEventDelay. I've done that on a few vehicles to deliberately slow the responsiveness of the control event.

Huh... this is interesting. I slapped together a quick demo and tried a combination of chat commands and touches. default { touch_start(integer total_number) { llSay(-10, "test"); } } default { state_entry() { llListen(-10,"", "", ""); } listen(integer channel, string name, key id, string msg) { if (msg == "sleep") { llOwnerSay("sleep started"); llSleep(10.0); llOwnerSay("sleep stopped"); } if (msg == "test") { llOwnerSay("listen received ping"); } llOwnerSay("end of listen event"); } touch_start(integer total_number) { llOwnerSay("Touched."); } } From my own avatar, I issued "/-10 sleep" which triggered the sleep routine on the listener. While that was sleeping, I did the following in this order: clicked the listener prim 1 time clicked the chat sender prim 3 times clicked the listener prim 1 time clicked the chat sender prim 3 times The result was that after the sleep expired, the listener appeared to process all 6 queued up listen events, and then only one touch event. This was the output: [16:10] Object: sleep started [16:10] Object: sleep stopped [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: listen received ping [16:10] Object: end of listen event [16:10] Object: Touched. Trying again with multiple additional touches on the listener prim but only one touch event ever seemed to queue up. So it seems that touch events are dropped after the first, but any chat that matches the listen handler filter will queue up even while the script sleeps. Curious that the listen events seemed to take priority over the touch event when draining the queue...

I know touches aren't... but come to think of it, I imagine listen events would probably quietly be dropped. Oops! I was thinking of something different. You may be correct.

Yes it's possible - but without seeing the actual code you've written, we can only guess at what the problem might be and how to correct it. If you are able, please post a sample of the code. If I were to hazard a guess, it sounds like every time the trigger is sent to the lamp's listener, it basically resets the countdown and thus appears to extend the duration of the lamp's glow time. Depending on the application, using llSleep may or may not be ideal. llSleep forcibly suspends the script entirely for the duration, which can lead to queuing up events that occur while it's sleeping. This could be another reason why the light duration is extended: it gets the first signal and sleeps, but if more get queued up, they immediately get processed as soon as the initial sleep expires. Generally speaking, I would suggest you use a timer event instead of llSleep. Additionally, make use of a global variable to track the state of the light. When triggered, first check if the light is already on and of so, do nothing. If on the other hand the light is currently off, then set it on, update the global variable and start a timer. When the timer pops, turn the light off, update the global variable, and stop the timer in the timer event. Edit: ah, Profaitchikenz beat me to it.

Granted, please report for jury duty. I wish my stubbed toe would heal faster.

Granted, but you can only watch the musical so many times before getting bored with it. I wish my wish was incorruptible...