KT Kingsley

Well, yeah. I guess I was still thinking in pre-mesh terms, when you'd have to phantom the whole linkset. But also, non-phantom off-parcel rocks and scenery blocking waterways.

Low bridges.

Unfortunately I'm a very poor animator who relies on much better animators to sell me their creations. Maybe I should think about replacing my sits with full perm ones. I think that way I might even be able to pull the UUIDs straight into my script using llGetInventoryKey.

Long ago I wrote myself an AO script that used the llSetAnimationOverride function. It cycles the sit and stand animations. It has a "smart sit" feature that works by checking if one of my own sit animations is playing while my avatar is sitting and only cycling if it is. It uses llGetAnimationList to get my current animations and then llListFindList to see if what would be my current sit animation is there. This works fine most of the time and appears to fail only when either the object I'm sitting on also happens to use the same animation I'm using in my AO (very rarely) or the object's script fails to stop my own animation before imposing its own (also very rarely). Now, to test the contents of the llGetAnimationList list I have to find the UUIDs of my sit animations. I've done this rather tediously by playing those animations and examining the results of llGetAnimationList to try to distinguish between my sit animation and the background body movement animations. Is there a better approach I could use?

Nope. Only one timer per script. Several possible workarounds, though. I think for what you want, a global integer flag that you set or reset when you start your animations would do to let you know what's supposed to happen in the timer event. Also there's the evil cheat of using llSensorRepeat with settings for something that'll never be sensed, and reacting in the no_sensor event. There are also a few scripts floating around that implement multiple timers, but I think they'd mostly be overkill for what you want.

Oh - and another thing that can go wrong when you link unrelated objects is sit targets. I think it works like this: when you sit on a link set the simulator looks through the links for the first one with an unoccupied sit target and sits you there. But when you link, say, a bath and a chair to your house you can end up with a situation where you click to sit on the chair but end up in the bath because the bath prim with the sit target has ended up with a lower link number that that for the chair. Or something like that.

Fionalein alludes to this above, but one problem you can encounter when linking unrelated objects is that their scripts can lose track of the link numbers they use when creating special effects. Lights and lamps are a prime example. Well scripted objects should search out the new link numbers for their relevant components automatically when the link set changes, but not all of them do. Some will do so when the script is reset and some just assume the link numbers won't change from when the creator first created them. Also, setting the whole link set to convex hull physics type can cause problems if any of the components have been deliberately set to prim or none physics types. And also be aware that linking some "tortured" prims (prims which have been subjected to radical transformations) to a link set can send the LI through the roof. Always experiment on copies of your objects first. Preferably in a sandbox rather than your own parcel so that sudden and unexpected LI changes don't destroy your build.

Regarding A: if your buttons are circular, or you're ok with using circular touch targets over non-circular buttons, llVecDist between the touch coordinates and the centre of the button can greatly simplify the maths. If you resize a copy of the texture you're using in your image editor to, say, 1000 x 1000, you can more easily figure out the coordinates you need to use in your script. Regarding B and C: the functions llDetectedTouchFace and llDetectedLinkNumber are what you're after. Either of these options is good if you want the button to react in some way such as flash or toggle using colour, fullbright, glow or use different textures for, say, on and off states. If your buttons are placed discretely on a panel (as opposed to packed together like a keypad or keyboard) and you're as fussy as I am, you might want the touch cursor to appear only over the clickable items. If so you'd have to go with option B, putting touch notifier scripts in each button prim. The downside of which is obvious. A way of getting around this might be to make an invisible mesh root prim with cut-out holes over the button images on the face(s) of a child prim behind it. The root prim, if it required a script, should not contain any touch events, which should be consigned to the child prim. (Also, I think this might work if, rather than the root prim being a mesh with holes, it was using a texture with alpha holes.)

Yes, I hadn't really looked beyond the code itself, but a single call to llSetLinkPrimitiveParamsFast would have more streamlining effect overall than any amount of code tweaking. The parameters list wouldn't need to be a global variable, just local to the function. Loop through the pre-prepared lists (which would be global) and rather than calling SLPPF for each face just add the parameters (including PRIM_LINK_TARGET and the face numbers) to the list and call SLPPF once for LINK_SET after the loops have been completed.

Well yeah, I wasn't going to rewrite the whole thing. Having got as far as your example, I figured you already knew where you could stick your exceptions. It's a suggestion as to how you could use do-while and while loops to streamline your for loops. I don't think there's much you can do about the exceptions, except maybe combine the "designation" and "activity" conditions with an && into a single if. But then again, unless things have changed, I understand that LSL will evaluate all the conditions in an if even when one of the earlier ones fails, so maybe it's better to do them separately. A whole different approach might be to pre-prepare a list of links called "designation" at startup (and redo it on CHANGED_LINK) and a list of the faces you want to operate on and loop through those lists.

Does this make sense, or should I stop trying to think about abstract code first thing after I wake up? integer link_number = llGetNumberOfPrims (); do { integer face_number = 8; while (face_number--) { //... } } while (--link_number);

Make the parameter of your debug function a list and output that list as CSVs. This saves a lot of effort casting all the different types of variables and literals when you call the function. Debug (list values) { llOwnerSay ("Debug: " + llList2CSV (values)); } You can now chuck in whatever strings, floats, vectors, etc., etc. you like, in whatever order you like. Debug (["Some state, some event", "my vector", my_vector, "my integer", my_integer, "my list"] + my_list + ["the end"]);

I've a vague idea that the ProductEngine surname was used by the outsourced company M had working on the notorious Viewer 2. But my memory of SL in those times is a bit hazy.

I don't think an avatar's scripted agent status is visible to anyone but its user and the Lab?* Those herds of green dots may well be acting as a visual lure on the map, but you can't know if they're registered as scripted agents and thus not counting towards traffic numbers, and thus perfectly legal. Indeed, the only evidence, albeit somewhat tenuous, is that they are there and are thus acceptable to Linden Lab. (I'd bet LL get plenty of ARs about suspected traffic bots. While it's possible that they routinely ignore all of them, it's also possible that they do investigate at least some, and of those mostly find them to be correctly registered scripted agents.) *I have been told that unregistered bots float on system water, while registered scripted agents will sink.

I think some people may be looking at this as if it was the introduction of a new feature. Actually, it's the reintroduction of an old feature. This is how things were back in the old last name days. The only new thing about it is the possibility of changing an existing name for a fee.

Google searching the actual image brings up this interesting page: https://marketplace.secondlife.com/p/CLICK-The-Casino-Props-for-Photographers/270694.

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Bot_policy: The prohibitions are: So if you are operating bots on a searchable parcel: (There's a lot more discussion of all this on the page, of course.)

If you have the correct permissions for the specular map texture you could use llGetLinkPrimitiveParams to get the key for the texture – indeed all the parameters – and just replace the glossiness parameter in the resulting list before feeding it back through to llSetLinkPrimitiveParamsFast. Something like… llSetLinkPrimitiveParamsFast (link_number, [PRIM_SPECULAR, face] + llListReplaceList (llGetLinkPrimitiveParams (link_number, [PRIM_SPECULAR, face]), [glossiness], 5, 5)); where link_number, face and glossiness are your specified parameters, and 5 is the position of glossiness in the list of parameters for PRIM_SPECULAR. WARNING: not tested inworld, and posted after a glass or two of wine. There's long been a desire, and maybe even a JIRA or two, for a LEAVE_IT_ALONE parameter to use in llSetLinkPrimitiveParams.

What the OP is asking for is what experiences do:

I'm certainly not in favour of this, but then again, maybe some roadside billboards wouldn't be that much of a problem. Except for the problem that SL road traffic is so light that few advertisers would be willing to pay more than a few cents for them. Billboards at infohubs would be another thing, especially with premium rates during rolling restarts. People might even be willing to pay a couple of dollars for that. Except for the mass of grey people blocking the view of the grey rectangles, and the primacy of the urge to get the hell away from there overriding any inclination to stare at those grey rectangles in the hope that eventually they'll render a solution to a problem you never knew you had.

You need to be wearing it (or have it rezzed on the ground) for it to work. The scripts in objects in your inventory do not run. They are suspended in the state they were in when they were taken in or detached, and will resume from that point when they are rezzed or attached.

First, check that the object's face is coloured white.

Sure. Tomorrow or yesterday, but never today.

I do need L$1250 for my rent right now… I'll pay you back later… Honestly…

I think what you want is the program SLURL Proxy available here: http://wiki.phoenixviewer.com/slurl_proxy. This lets you select the SL viewer you want to fire up when you click an SLURL on a web site. Without this, generally, the most recently installed viewer will grab ownership of the SLURL protocol.