Fenix Eldritch

From SLPPF caveats: If you want to move the entire linkset, use LINK_ROOT. I just tested this in-world with a multi-primmed hud attachment and it seems fine. Do note that if you're just using successive SLPPF calls, the functions may be too fast to get the shake movement you want. You may need to add some artificial stalls to give the effect time to be noticed by the user. Here's my quick demo: (script written/added while the object was already attached to hud center) default { state_entry() { llSetPos(<0,0,0>); } touch_start(integer total_number) { llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,.001>]); llSleep(0.05); llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]); llSleep(0.05); llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,-.001>]); llSleep(0.1); llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]); llSleep(0.05); llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,.001>]); llSleep(0.05); llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]); } } Edit: updated demo with 0.001 positional movements and even smaller sleep values to closer match OP's intent

I'm not familiar with the mechanics of breedables, but I presume you'll want to follow Profaitchikenz and KT's advice to maintain a list of detected objects and check against that on each iteration of your sensor. If the uuid isn't already in the list, then we assume it's a freshly rezzed object. So send the announcement out and also store the uuid in a list. The next time the sensor fires, it will follow the same sequence: for each uuid the sensor detected, check to see if it's already in the list. If so, do nothing. If it's not in the list, it's new, so announce and add the uuid to the list. Lather, rinse repeat. You'll want to also setup a controlled environment for this where the breedable is corralled in an circular area that is the same radius as the sensor range. Try to have no other objects inside that range except for the sensor and the target breedable. That way you minimize the number of objects you need to process on each sensor pass.

Adding to Rolig's post, you can turn on a viewer debug setting to check if your object has a script in it which is producing updates - like color changes. Press Ctrl+Alt+Shift+U to turn on the "Show Object Updates" feature. Any time an update occurs, a colored particle will be emitted from the object. Press the key-combo again to turn it off. More info here http://wiki.secondlife.com/wiki/About_the_Update_Indicators Alternatively, if there aren't any scripts in the object but its colors continue to change, then it may be the result of a texture animation, which is another prim property that can persist without scripts. If that is the case you can use this line of code to turn off all texture animations on the object: llSetLinkTextureAnim(LINK_SET, FALSE, ALL_SIDES, 0, 0, 0.0, 0.0, 1.0);

The trick in this scenario is to grant PERMISSION_ATTACH to the attachment object before you place it into the rezzer's inventory. That way, each new instance will be a copy of the object who already has the permission given. The state_entry event won't trigger when the object is rezzed from the rezzer, only the on_rez event. A simple proof of concept for the attachment script: default { state_entry() { //request permission when script is first started llRequestPermissions( llGetOwner(), PERMISSION_ATTACH ); } run_time_permissions( integer vBitPermissions ) { if ( vBitPermissions & PERMISSION_ATTACH ) { llOwnerSay("Granted"); //simply verify we have permission } else { llOwnerSay( "Permission to attach denied" ); } } on_rez(integer rez) { llAttachToAvatarTemp( ATTACH_LHAND ); //attach when object is rezzed } } Note that this example lacks error checking. It would be a good idea to do a double-check just before we attach to make sure we still have permissions. And perhaps another check to see if we were rezzed from player inventory or the rezzer. That can help for making future edits and whatnot.

Rider Linden has a thread in the EEP forum which outlines the LSL hooks. According to that, llGetTimeOfDay should be EEP aware.

Tread carefully here - because something like this can very easily venture into griefing territory. It would be advisable to make sure all who participate in this are aware of what's going on and agree to it. Otherwise you may find yourself on the receiving end of abuse reports. There are a few approaches, though all of them have different drawbacks and limitations. I don't think any of them are any simpler than what you are already doing - though I am not familiar with using RLV. llTakeControls has the ability to disable avatar movement controls depending on the value of the pass_on parameter. Although even when "frozen" like this, the avatar can still rotate in place via mouselook. And this does not disable the Flight control (though if it's disabled on the parcel, that can help). This also won't stop the avatar from being pushed around by external forces like gravity or other avatars/objects. I suppose you could have your attachment take controls, play the animation, and rez an invisible cage around them for the duration to prevent outside interference. Another approach is to use llSitOnLink to force the target to sit on an invisible object (doesn't need to be a cage in this case). Combine that with PRIM_ALLOW_UNSIT to prevent them from prematurely standing up. Call llUnsit when the frozen period expires to free them. But llSitOnLink and PRIM_ALLOW_UNST only work if the objects and avatars in question are part of an Experience and on land that allows said Experience. Edit: what Lucia said.

So if I'm understanding you correctly, you're saying you do something like this? Read a notecard line into a string. Split the string into a temp list with something like list temp = llParseString2List(notecardline,["|"],[]); Add this temp list to a combined list. You called it "Name" in your above post. Repeat steps 1-3 until you've read all the notecard lines you need. Attempt to treat the combined "Name" list as a strided list to build a menu. But you hit problems because the strides are not consistent. Is that correct? If so, you can inject a dummy element into your list in step #2 by checking the length with llGetListLength. A typical input like "Item Name|Command 1|command 2" would have a length of 3. Whereas the alternate case of "Item Name|Command 1" would have a length of 2. If the temp list in step #2 has a length of 2, simply add an extra list element to it before appending the whole thing to your combined "Name" list. That will enforce the three stride structure you appear to be going for. list temp = llParseString2List(notecardline,["|"],[]); if(llGetListLength(temp) == 2) { temp += ["X"]; } Naturally, you'll need to also update the part of your code that builds the menu and have it check if the element it's looking at matches your dummy flag and not add it to the final menu. Edit: And this is just assuming you only ever have either one or two command elements in your notecard line. Is that a given? Is it possible you might see a notecard line with no commands, or more than two?

Unfortunately no, particles do not have the ability to collide with and react to solid objects in the way you are describing. The closest I can think of is PSYS_PART_BOUNCE_MASK which makes falling particles bounce off of an invisible plane set to the height of the emitter's origin. The trouble is this plane is oriented to the region's z axis instead of the emitter's. So that won't help in this case. As an aside, depending on your needs, you may be able to reduce the number of particle systems. A system with the explosion pattern and zero burst speed min/max would create multiple particles randomly placed within a spherical area. Combined with making the particles short lived and having their beginning scale something like <0.0, 0.1, 0.0> to an end scale of something like <0.1, 0.0, 0.0> would make a quick flash/sparkle that winks out nicely. Repeat for each unique color. In your gif, I counted four colors, so you could potentially get away with using that many to get a similar effect.

No. You've gone off the rails entirely. Forget about experiences, I regret even bringing them up. They will not help you with where you are at right now. Focus on just getting the teleport example to work. Endure the permission requests each time you reset the script. Edit: "discrimination" are you kidding me? Get out of here with that nonsense. And no, you don't need to be premium to use an experience key. Only to create one. But that's neither here nor there. You have a SLRUL. Contained within that is the name of the region. You must extract the region name from the SLURL before you give it to llRequestSimulatorData. Given a string, strip out the unneeded junk until you are left with what you want. For example, this is what a SLURL to MiddleEarth might look like: http://maps.secondlife.com/secondlife/MiddleEarth/128/128/25 All you want, all llRequestSimulatorData cares about, is the region name i.e. "MiddleEarth". None of that other stuff makes a valid region name. Discard it. All you want is the stuff between "http://maps.secondlife.com/secondlife/" and "/128/128/25" llParseString2List can be used to break up the slurl into individual sections, such as separating them by "/". You can then grab the specific list entry that contains the region name. If the region name has spaces in it, they will be denoted by %20. You can convert that back to spaces with llUnescapeURL. Good luck, I'm out.

See the Knowledge Base article on experiences for more generic information. It was a passing suggestion, but if you aren't down on the basics yet, then it's probably best to ignore experiences for now. Work on getting more comfortable with the regular stuff first. As with all things, having additional llOwnerSay commands peppered throughout are helpful in debugging. Have an llOwnerSay speak the result of the parsed region name. If you're not extracting a valid name from your SLURL, then the subsequent call to lRequestSimulatorData will be using a non-existent region name, and the dataserver entry will never fire.

A teleport freezing/failing halfway might just be a generic network problem. They can still happen once in a while, though it's getting rarer in my experience. Just try again in a moment. If you are using the example from llTeleportAgentGlobalCoords, all you need to do is change the top variable simName to be your target region. In your case you would need to parse "MiddleEarth" from the SLURL. I've tried it now and the teleport works fine. The example script as written will ask you every time it is reset. You can move the request out of the state_entry to lessen the immediate ping, but the script will need to ask you at some point before doing the teleport. Once you do grant permissions, they will persist and it won't ask you again.... unless you reset the script, or someone new tries to use it (recall that a script can only hold permissions for one avatar at a time). You can also use Experience Permissions to make the script not bother users with repeat requests, providing they are in the same experience as the script.

Sorry, I was speaking pretty loosely when I said you can plug that into the other function. I will clarify and edit the above post afterwards. llRequestSimulatorData returns a handler for the dataserver event. You actually get the information you requested in that event, not instantly from the function itself. If you look at the example on llTeleportAgentGlobalCoords, it shows the basic sequence. The script starts by requesting the data in state_entry. When the dataserver event fires, it populates the global variable with the coordinates. Finally, the teleport function is triggered on a touch_start, hopefully after the initial setup is done (it does a sanity check beforehand to ensure the global coordinates are indeed populated and if not, request again).

Re-read the specification for llTeleportAgentGlobalCoords again (I'm assuming that's what you meant to say, as there is no llTargetAgentGlobalPosition function). It tells you right at the beginning that the function targets the destination region by using global coordinates and that you can discover any region's global coordinates via llRequestSimulatorData(region_name, DATA_SIM_POS). If you have the SLURL, then you have the region name. Parse it out and feed it to the other function. Edit: ok, you can't feed it in directly. You need to go through the dataserver event, as that is where the actual coordinates are given when you call llRequestSimulatorData.

The wiki page for llVolumeDetect I linked above has more details (and examples on how to use) but generally speaking, llVolumeDetect works similar to phantom. The object becomes non-solid and avatars and physical objects pass through with ease. Unlike phantom, the server still keeps track of collisions with llVolumeDetect objects. So when something moves through, it will trigger collision_start and collision_end events for any scripts within the object.

Essentially, you want to play the sound on a collision_start event. Phantom objects do not raise collision events, but llVolumeDetect ones do.

That's pretty much using llSetLinkTextureAnim() as Lucia and Rolig mentioned. But also careful mesh design, particularly with the UV mapping and splitting up of multiple material slots. Most of the signs in that video seem to share some common design element in that each letter (assuming they are separate links) likely has at least two material slots: one for the outline, and another for the solid fill. Take the third sign, "Sarah's Technic Corner" for example. The effect of snaking the light around the letter's outline could be done by unwrapping the outline material slot to be a contiguous linear strip on the UV map and then simply panning the texture from left to right. Making the texture at least half lit/unlit gives the appearance of it "filling up" as it slides across. Indeed, since these neon lights are generally a solid color, a very small texture can be used, as all you need is the color and necessary offsets working in tandem with the UV.

You cannot build past 4096 meters in elevation, so I can't imagine a skybox being in excess of 7000 meters high. Having said that, there are a few options for positioning yourself. When an avatar sits on an object, it becomes part of the linkset and can be moved around with the llSetLinkPrimitiveParamsFast function. You could potentially do that to shift the avatar's position and the unsit them. But I believe the practical limit is 1024 (at least that's what I saw testing vertically just now). Alternatively, you could surround the sign with a transparent prim that when sat upon, will move itself (and the seated avatar along with it) to the target destination. Use llSetRegionPos to instantly move there. Edit: ah, too slow.

By "one system", do you mean a single call to llLinkParticleSystem? If so, that is not possible. The particle system functions are not like the llSetPrimitiveParams functions which can let you target multiple discrete prims at once via the PRIM_LINK_TARGET in the parameters list. There is no equivalent for llLinkParticleSystem. Your only options for that are to use the single link number parameter which can be a specific number or one of the special LINK_* flags. If you want to turn link #3 and #5 into particle emitters, then you need two separate calls to llLinkParticleSystem, specifying the appropriate link each time. That is why I split things up the way I did in my example. The majority of the particle parameter list was identical between the two, so I created that separately and then made an ad hoc list appending the unique parameters (the target) when actually calling each llLinkParticleSystem.

Correction: you can STOP animations by UUID. Apologies for not catching that error in my post before the forums edit window elapsed.

First up, when and how often are you calling that startParticlesF function? I see you are passing a single integer into this function, but only using that to clear the particle emitter on that single link. In my previous example, I started with clearing the particles from the entire LINK_SET simply as a shortcut for the demo. If you have the link numbers of the emitters already saved, and they aren't going to change, you can use that instead. My main point is that looking at this function in isolation, it seems you aren't properly cleaning up. (but that is tangential to the current issue you're seeing) Secondly, if the desired behavior is shown in picture 2 (after region crossing) and you aren't repeatedly calling startParticlesF on a region crossing, then it's probably safe to assume you have the correct link numbers stored and the problem isn't with them. I'm not able to reproduce your issue, but perhaps you could try removing the extra particle parameters that are not being used. Failing that, my guess is that it might be a viewer/networking issue. Maybe. Hard to tell. I've experienced a similar oddity with a vehicle that is supposed to have a short lived particle exhaust that follows the source emitter. In practice, I will see that the particles be drawn ahead of the actual emitter - but the behavior corrects itself on a region crossing. Been meaning to write up a JIRA on that, but I need to make a demo that reliably produces the issue. This might not help, but see if your viewer has "velocity interpolate objects" and "ping interpolate object positions" enabled (look under Develop > Networking menu items)

llPreloadSound has a forced delay time of 1.0 seconds. There's no getting around that. Having said that, why are you calling llSleep on each loop iteration? We don't see what preload_load_time is being set to, but I suspect it's not necessary here.

There has been no change to how UUIDs work in SL that I am aware of. There are several different kinds of UUIDs, some of which can change under certain conditions. See http://wiki.secondlife.com/wiki/UUID. Inventory items are just wrappers which point to the actual asset UUID. The asset UUID only changes if the asset itself has been modified... well technically, assets are immutable (cannot be changed) so what's really happening under the covers is that you're creating a new asset every time you edit it. For example, whenever you update the contents of a notecard and save, you are creating a new notecard with a new asset uuid. Objects that can be rezzed in-world are a different beast as well. As far as animations go, once you upload it, that's it. The asset UUID won't change because you can't edit it further (renaming it or changing the permissions don't count because that's editing the inventory item wrapper, not the actual asset itself). I've verified this just now, by taking a full perm animation in my inventory, noting the UUID and then making copies, renaming them, changing their permissions, transferring them to an object's inventory and making similar edits to those copies. In all cases, the UUID reported by the "Copy Asset UUID" viewer function or a script with llSay(0,(string)llGetInventoryKey(llGetInventoryName(INVENTORY_ANIMATION,0))); all report the same unchanged asset UUID. But all of this is moot, because you cannot start/stop an animation by its UUID anyway. You must use the inventory item name, which means the animation must be in the same object as the script trying to use it. The sole exception to this are the built-in internal animations listed on the wiki.

You're going to need to be more specific. What effect are you trying to achieve? Just describing it as "animated" doesn't really tell us much.