Fenix Eldritch

Granted, but now you are stuck in a Groundhog's Day time loop (and it's forever Black Friday - ouch!) I wish the cold didn't affect me.

Granted, your to-do list has been shortened to one item: "Everything". I wish my vacation would start now.

Granted,NullPointerExceltion I wish I could type without making typos. Edit: i swear to god that wasn't on purpose.

Ha... whoops. Impressive that I read the pages multiple times and managed to overlook that. Thanks!

Your animation is only 4 frames long (8 if you include the reverse added by PING_PONG) and the speed is set for 10 frames per second. That means the entire sequence should take less than 1 second to play. Just as a sanity check, perhaps try altering the rate to something slower - just to be sure it's not going by too quickly to notice. I know it seems unlikely, but it doesn't hurt to double check. There is also a known caveat that selecting the object can restart the animation. I'm unsure how this affects non-looping animations, but maybe it's causing some unexpected interference. On a completely unrelated note, something about the start/end values is bugging me. If you only have 4 frames, the valid start/end values should be either 0-3 if they are 0-inxedex or 1-4 if not. Having a range of 0-4 is actually 5 frames: 0, 1, 2, 3, 4... that doesn't seem right to me... and yet I see a similarly constructed example on the wiki pages for these functions. Can anyone confirm if the start/end ranges are 0-indexed?

There are a number of issues with the script which I think can be summarized into two general categories. Your timer event has no logic inside it to facilitate deciding which helper function to call. Instead it just blindly calls close_menu, newSlide, and newSlide2 all at once every time. These functions directly conflict with each other. There are a lot of hard-coded values in the code which not only makes the script inflexible, but actively works against the intended function. Especially since you have an index variable, but are not using it at all. You're using your timer event for two different things: closing out the listener and also advancing the frame. However, the close_menu function calls llSetTimerEvent(0) which halts any active timers. This is problematic since it will stop your slideshow from advancing beyond the first frame. Additionally, since you are calling newSlide AND newSlide2, your script is incapable of sticking to one set of frames. When the user selects one of the options, it will display the correct first frame. But after that, when the timer pops, your script as currently written will always: call close_menu, which kills any active timer. call newSlide which sets the texture of face 1 to be the first texture from the General set call newSlide2 which sets the texture of face 1 to be the second texture from the Haloween set. So to start, I would get rid of the newSlide2 function entirely. Instead, just use the original newSlide function and update it to be flexible enough to operate on whatever the current set is. One way to do this is to create a new global list variable called "currentList". In your listen event, when you discover which option the user selected, update this variable with a copy of the approriate list. For example, if the message was "Halloween", set currentList=hween; Or if the message was "General" set currentList=general; Then, in your newSlide function, reference the currentList instead of the general or hween lists. The point is to use a variable instead of a hard-coded value. Similarly, you never actually use the index variable when picking list elements to set the current texture to. Use that instead of the hard-coded 0. This is also the case for the out of bounds checking you do to reset index to 0 if it's greater than or equal to the list length. As for the Timer event, remove the call to close_menu - or at least remove the llSetTimerEvent(0) from that function. There are better ways to handle this, but for now try the above.

Some time ago I acquired a recreation of the Flaptter vehicle from the Laputa Castle in the Sky anime. It had a set of dragonfly-like sculpted wings which would rapidly toggle their alpha on/off to simulate the frantic beating of the wings. This naturally produced a truckload of object updates when in use, which I wasn't keen on. Luckily, it was modify enabled so I found that I could make a much more efficient effect by using a simple texture animation that was essentially two frames: the visible wing, and full alpha (I also reduced the texture size considerably since high detail wasn't needed). Instead of hammering the server with turning alpha on/off, I could just start the animation on the wing sculpts. Similarly, I have also been able to replace a pulsating color transition that originally used many llSetColor calls with a smooth low-resolution texture of a color gradient. Granted, it's not always possible to make these kind of substitutions, but when the object and texture designs allow, it can be done.

Granted, but the wish was for their wish to no be granted. I wish my driveway would clear the snow off it by itself.

As per the specification on the wiki page for llCastRay: and So the list returned from a call to llCastRay will never be empty - at minimum it will always contain a status_code integer at the end. Since the status code will always be the last entry in the list, you can use -1 as an index into that list element and check its value. And since it's always going to be an integer, you can use llList2Integer to see if it's 0 (no hits) greater than 0 (hits) or less than 0 (error). if (llList2Integer(myValue, -1) == 0) //status_code is 0, so the ray didn't hit anything

It occurs to me that there may be another approach... though it's a bit cumbersome - and I'm not entirely sure if it will work in the first place. What if you set your linkset to have the temporary status, unlink everything and then remove the temporary status on the remaining prim B? If (and that's a big if) the freshly orphaned child prims retain that temporary status, they will delete themselves automatically after a few seconds (in theory) Edit: Jumped inworld and tried a proof of concept. And it works! //Demo script to delete all child prims, but leave the root intact. //Script will set temp_on_rez status, break all links, then remove the temp status on the root //The result will be the orphaned child prims keep the temp status and self delete after a short time. default { state_entry() { llRequestPermissions( llGetOwner(), PERMISSION_CHANGE_LINKS ); } run_time_permissions( integer perms ) { if (PERMISSION_CHANGE_LINKS & perms) { llOwnerSay("permission granted"); } } touch_start(integer total_number) { llSetPrimitiveParams([PRIM_TEMP_ON_REZ,TRUE]); llBreakAllLinks(); llSetPrimitiveParams([PRIM_TEMP_ON_REZ,FALSE]); llOwnerSay("all child prims set to temporary and unlinked."); } }

When a script rezzes an object from its own inventory, it queues up an object_rez event. In that event (assuming you include it in your script) you can access the UUID for the object that was just rezzed. I'm a little fuzzy on what conditions might cause a rezzed object's script to get reset (region restarts?) but generally speaking, yes, if left out and alone, prim B should retain its permissions. As for removing the child prims when no longer needed, that is a little more involved. The only function to actually delete objects is llDie but that targets the object containing the script. So you would need to unlink the child prims with llBreakAllLinks and then return them by way of something like Rolig suggested. Just be aware that your lost and found folder it going to get a lot of traffic from this.

As you have surmised, each separate object would need its own listen in order to react to chat commands. You could indeed cut down on the number of listens (and even scripts) by linking more parts together and having the linkset use one central script. (This is in fact highly encouraged as fewer scripts in general puts less load on the servers) llCreateLink can be used to programmatically link one object to another, and specify which one will be the root in the resulting linkset. In your example, prim B would have in its script the routine for issuing the llCreateLink function, with the target UUIDs of prims C, D, etc being supplied to it by prim A (A would automatically know their UUIDs since it's rezzing them in the first place). All prims to be linked would need to have the same owner, reside on the same region, be within link distance, and be modifiable (trivial if you are the creator). Additionally the script in Prim B would need to request PERMISSION_CHANGE_LINKS before it could do anything. This last part may be problematic... I'm unsure if the script of prim B instances would be reset when rezzed from A's inventory - if so, they would lose any saved permissions and need to re-request, which would make the whole thing not work unless you are around to satisfy that request. Another approach you may want to consider is to build your game pieces already linked, with a surplus of linked parts to accommodate future players/capacity. Keep them dormant/invisible and only reveal them as needed. This would avoid needing to rez/link parts at the cost of permanent LI consumption.

Back on topic, This would depend upon how you process the results of the rays. If you fire a burst of rays for a single "shot" then you would have to examine the results from each ray. When comparing the resulting lists, you can make a note of any duplicate keys and elect to ignore them. Off the top of my head, I would basically have a routine that combines the results from all the seperate ray casts and only adds victims if their uuid isn't already in the combined list.

From what I've seen, the standing avatar is not really a oblong sphere but instead more like a low poly coffin shape. There is a picture on the wiki in which someone created an in-world ray tracer visualizer for what the physics shapes look like. Pictured below are the standing avatar (left) and ground sitting avatar (right): http://wiki.secondlife.com/wiki/File:Avmeshforms.png And there is in fact a third shape for avatars when they are sitting on prims. I captured this with my own ray tracer I built in-world (inspired by the above picture). https://my.secondlife.com/fenix.eldritch/snapshots/5c955bc8d774f802cf000001 And lastly, pathfinding characters actually genuinely have a capsule shape as advertised. https://my.secondlife.com/fenix.eldritch/snapshots/5ca9f4d373ed1711d1000001 My ray tracer is still setup in my workshop (SLURL in the above feed links) if anyone wants to mess around with it. Note it takes about 5 minutes to complete the render.

Granted, now it quickly gunks-up from finger oil. I wish I could moonwalk.

Granted, but you didn't say by how much or in comparison to what. I wish I could solve this Rubix Cube.

If you're new to scripting in general, it may be beneficial to go through some of the introductory tutorials on the wiki. But as for your latest code, do as Love Zhaoying suggest and remove that lone (integer) statement. It's not doing anything good there. I believe that should get the script to compile. Edit: oops, I missed the mismatched braces that KT Kingsley points out below. That'll definitely cause issues. Now consider what the goal of your script is. You had some code that originally was triggered when the owner clicked the object. Said code was contained inside a touch_start event. You wanted to make the trigger instead happen when the script "hears" a specific command spoken by the owner. You've already got the llListen and listen event setup, so all that remains is to move the code into the listen event. For reference, the state_entry is only triggered once, automatically when the script enters a given state. Your script only has one state (the default state) so that means its state_entry event will automatically trigger when the script starts up. That's why it's good to do your setup there, like setting the llListen handler. But after that, you want to just deal with the listen event. Does that make sense?

Rather than using a touch_start event, you want to place your code within a listen event. And in order to make a script actually trigger listen events, you must set up a listen handler/filter with the command llListen. The llListen command requires several parameters which will act as a filter. This is important because you want to filter out as much chatter as possible so as to not accidentally trigger the event - similar to how your original code checks if the owner was the person who touched the object. The wiki pages I linked above can give you the full details on how to set this up, but for a quick example, the following code can set up a listen which will trigger when the object's owner speaks the word "command" in local chat and is within hearing range of the object. llListen( 0, "", llGetOwner(), "command" ); //sets up a listener filter for when the owner says "command" on channel 0

Ah, yes it was the vehicle flag I was half remembering. I'm not very familiar with that, so others may be able to provide better advice. However if you intend to remove it completely, I believe you don't need to continually turn it off in the control event. Instead, you can set/remove the flag once at the beginning in something like the state_entry and then leave it be.

Hard to tell what's going wrong without seeing the code, or getting a better picture of the expected behavior verses how it's misbehaving when you enter mouselook. Saying it's "just awful now" doesn't give us a lot of info to go on. But if I were to hazard a guess, I imagine you might be getting tripped up by the fact that the left/right arrow keys behave differently when you enter mouselook. Normally they trigger the CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT respectively (these turn your avatar). But when you're in mouselook, they instead trigger CONTROL_LEFT and CONTROL_RIGHT (these strafe your avatar). So if your script doesn't account for that, that could be your problem... But again, I don't know how your script is expected to work in third person, so I can't say for sure without more info. In any case, yes, it's relatively simple to code your control event to behave differently when in mouselook or not. Use llGetAgentInfo to query the status of the target avatar and check the resulting bit field against the AGENT_MOUSELOOK constant. Separate your different control code with an IF ELSE statement. integer x = llGetAgentInfo(llGetOwner()); if(x & AGENT_MOUSELOOK) { //do mouselook control stuff } else { //do non-mouselook control stuff } Edit: Oh, wasn't there also some kind of mouse steering for vehicles? I vaguely remember something about that, but can't seem to locate it on the wiki...

If you're looking to commission a scripter (or even get an estimate on what a potential job would cost) you really should be posting in either the Inworld Employment forum, or the Wanted forum. The LSL Scripting forum is geared more towards discussions of scripting tips/techniques/questions/etc between people writing their own scripts. If you were looking to write your own combat HUD and needed suggestions or guidance, then this would be the place to ask - but you'd need to be much more specific with what you where having problems with.

Yeah, if your parcel is larger than that, that's another limitation

So you basically want to avoid the overhead of a potentially lengthy list returned by llGetAgentList... I suppose you could circumvent that by using a sensor event, since the num_detected parameter can be used as an index to all targets sensed within the sensor sweep. You would need to iterate over num_detected and for each one, pull out the uuid with llDetectedKey and perform some operations on that single user to determine if they're over your land. If the target is over your land, increment a counter. As for how to determine if an individual avatar is over you land, one approach is to extract the target's position and check that position against llGetLandOwnerAt. Edit: I forgot that sensors only return the first 16 hits, so this may not be the most robust solution...

llGetNumberOfPrims only returns the total number of prims in the linkset. That's not going to be very helpful here. For example, if you have ten prims in your linkset, that function will return the integer 10 every time. You were on the right track with using the KEY = llDetectedLinkNumber(0). Try taking your previous example and modifying the llSay to look like this: llSay(0, "linknumber " + (string) KEY + " pressed, and it's name is "+llGetLinkName(KEY)); The above code (when placed inside a touch event) will tell you the linknumber and the name of the prim touched. Now my previous suggestion depends upon placing copies of the sound assets directly into the piano's inventory. This is because we can rename them to match their associated piano key names. The LSL functions that actually emit sounds allow you to specify a sound either by UUID, or by the name of the sound file (as long as it exists in the object's personal inventory). So the idea here is to make a given key and its associated sound have the same name. For example, find the prim with linknumber 2 and in the build tool, rename the child prim to "KEY2". Then, get the sound asset you want for that key, place it in the piano (wherever the script will reside) and rename the sound file there to be "KEY2" as well. By doing this, we can eliminate the need for all those IF checks. Instead of checking "if key 2 is pressed, play this uuid" we can instead simply say: llPlaysound(llGetLinkName(KEY),1.0); The trick here is that since the specific key and associated sound have the exact same name, we don't need to do any tests. We just feed the prim's name into the sound function directly. Try adding that to your previous example.

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.