Profaitchikenz Haiku

The only time I ever had problems with a surfeit of alts on the island I ran would not have needed IP-matching to identify them, you could see instantly by their profile descriptions that it was "Oh them again...". However, this was just an RP environment. I can see the justification for stopping alts invading contests, trying to crowd somebody, or swamping lucky chairs (from my previous experiences I got up to 10 alts of one person so it's not inconceivable somebody could get themselves 26...)

Seconded.

I'm curious to know how this might affect colleges, businesses, institutes etc that have one ISP provider for their users? I admit it's a bit of a forced scenario given that SL/Opensim is such a niche thing that the chances of there being more than one person at a shared IP address wanting to access the same region at the same time is of the same order as a dead-cert dropping dead on the final furlong, but....

Reminds me of the time Andre Previn appeared on Morecombe and Wise "You're playing all the wrong notes!"

There's a couple more events seem to be sometimes slipped or significantly delayed, moving_start and moving_end, at random intervals in regions where scripts run is less than 40%. Again, as Lucia says, it became most noticeable at the end of 2019 However, as these problems are "hard" ones, I have a suspicion that GUI inventories will be rolled out to take people's minds off the problems by giving them something new to play with

I wonder if a simpler effect could be by an animated texture on the surface of a cone which is centred on the avatar?

The particles can be made to move towards a target UUID which would be Cinderella, the arch effect will take some experimenting but I suspect you will have to give them an initial direction to raise them over the avatar and then let them fall under gravity. Have a look at the wiki page for the particle system for these options ETA just saw Wulfie's post, I've not seen the movie but if that's the desired effect the tiny spheres could be made to follow a complex path using keyframed motion, and they would have to emit the sparkles,

I'd not spotted that before! I see a whole new venture before me. Retirement? I've never been so busy

Providing the mesh content isn't of horrendous LI when linked together, you could try this: Create a single prim, flat, which is the root prim and contains the script and is the sit target prim. Texture it as the shadow prim of the chair Link to this two or more mesh chairs (which are themselves 1LI items), and set each of them to prim physics NONE Set each chair to have two sizes, and two local position and rotations Size one is the hidden size, the item is reduced to the smallest practical size, is set fully transparent, and is moved down out of the way. Size two is the item scaled up to the required size, now fully visible, and positions so that the avatar (sitting on the root prim) is apparently seated on the chair. Change the root prim shadow texture to suit. You might have to reposition the avatar if the different mesh chairs do not adapt to the basic sit pos and rot. The key to making this idea work is finding mesh chairs that are 1LI on their own and do not create ridiculous LIs when linked to other things. After that, it's lists of sizes, local positions, local rotations, and possible altered sit pos and sit rot amounts.

No, notecards have to be created or amended by human interaction via the edit-floater. All you can do with object inventory content under script control is remove it.

You know, as I typed the post I just knew I was going to be wrong, but like Dougal in the cockpit with the big red button, I couldn't resist it. You raised a point I had forgotten about, the local orientation, I think I'd better look again at this using a child prim. In all of the scripts I've created using rotations of attachment, avatars on objects... I've always obtained the current local rotation and multiplied it by the desired adjustment then re-applied it, and now I'm wondering if I've just been luck all this time (although I always only apply rotation adjustments one axis at a time, and this was what I seemed to be seeing in my earlier post, single-axis changes seeem Ok).

I did a quick test inworld to see what the effect of changing the order in which you multiply rotations might do, and the results are very interesting. TL;DR If you're working on an object with zero rotation, then you'll get away with ignoring the order, but that's an IFF The Script, dropped in a simple cube with initially zero rotation // check the order of multiplying rotations key owner; rotation rot1; rotation rot2; rotation rot3; vector angle1 = <0.0, 0.0, 90.0>; vector angle2 = <45.0, 45.0, 0.0>; vector angle3 = <90.0, 0.0, 90.0>; rotation baseRot; rotation result; vector answer; default { state_entry() { owner = llGetOwner(); baseRot = llGetRot(); rot1 = llEuler2Rot(angle1*DEG_TO_RAD); rot2 = llEuler2Rot(angle2*DEG_TO_RAD); rot3 = llEuler2Rot(angle3*DEG_TO_RAD); } touch_start(integer touches) { result = baseRot * rot1; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("BaseRot * rot1 = " + (string) answer); result = rot1 * baseRot; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("rot1 * BaseRot = " + (string) answer); result = baseRot * rot2; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("BaseRot * rot2 = " + (string) answer); result = rot2 * baseRot; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("rot2 * BaseRot = " + (string) answer); result = baseRot * rot3; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("BaseRot * rot4 = " + (string) answer); result = rot3 * baseRot; answer = llRot2Euler(result)*RAD_TO_DEG; llOwnerSay("rot3 * BaseRot = " + (string) answer); } } and the answers, first with the cube having zero rotation, then with the cube turned 45 degrees counterclockwise on the Z axis 13:42] checkRotOrder: BaseRot * rot1 = <0.00000, 0.00000, 90.00000> [13:42] checkRotOrder: rot1 * BaseRot = <0.00000, 0.00000, 90.00000> [13:42] checkRotOrder: BaseRot * rot2 = <45.00000, 45.00000, 0.00000> [13:42] checkRotOrder: rot2 * BaseRot = <45.00000, 45.00000, 0.00000> [13:42] checkRotOrder: BaseRot * rot4 = <90.00000, 0.00000, 90.00000> [13:42] checkRotOrder: rot3 * BaseRot = <90.00000, 0.00000, 90.00000> [13:43] Profaitchikenz Haiku: turned 45 degrees (and reset the script to get the new base rotation) [13:43] checkRotOrder: BaseRot * rot1 = <0.00000, 0.00000, 135.00000> [13:43] checkRotOrder: rot1 * BaseRot = <0.00000, 0.00000, 135.00000> [13:43] checkRotOrder: BaseRot * rot2 = <45.00000, 45.00002, 45.00001> [13:43] checkRotOrder: rot2 * BaseRot = <-16.32497, 58.60028, 73.67507> [13:43] checkRotOrder: BaseRot * rot4 = <90.00000, 0.00000, 135.00000> [13:43] checkRotOrder: rot3 * BaseRot = <90.00000, 45.00002, 90.00000> It makes a difference in anything but the simple case. If you want to rotate an object by an amount, the correct order is objectRot * amountRot; Looking at the above output, if your object has zero rotation, or if the amount you are rotating it by is only non-zero in one of the three axes, it seems to be commutative, but the moment you have non-zero values on more than one of the three axes it is non-commutative. One of these lovely gotchas

What Rolig said will do it

I agree, in this case with simple rotation to and fro around the z-axis it will, but The wiki is quite definite about the rotation multiplication and division being non-commutative. If rotation1 * rotation2 == rotation2 * rotation1 why state the operation order is important? I can see somebody adapting this script to make adjustments to a chiild prim in more than one axis at a time and coming unstuck. I could of course be wrong and I am confident that the usual subjects will be along shortly to put me in my place

That's because although you negate rotSwing immediately after using it, the next time into the listen it is re-initialised to 90 degrees and your previous negation is thus trashed. Move the initialisation of rotSwing into the state_entry and the altered value of rotSwing will be available next time in the listen.

Don't feed the alligators.

This should be the other way round, r * rotSwing (r is the actual local rotation, rotSwing is the amount it is to be altered by) More interestingly though, I can't see how this bit is going to work state_entry() { llListen(-3928573,"","TURN",""); } listen(integer channel, string name, key id, string message) { You're listening on channel -3928573 for any name talking, with an id of "TURN" , for any message? If it works at all it's because whatever the key value of "TURN" equates to it just happens to be the key of your sender?

Um, he said "We knocked the bugger off" If was George Mallory who made the quote you referenced

I think that's banned too.

You can use llSetLinkPrimitiveParamsFast(linkNum, [PRIM_ROT_LOCAL, newRotation]); Calculate newRotation by getting the current link local rotation and multiplying it by a small amount on the particular axis you want to spin around. Repeat this on a timer, probably in whatever timer loop your wanderer script already has. To speed things up you can bypass the getting current local rot and simply have a rotation variable that gets turned and applied to the child, when the script resets, reset this variable to the initial rotation and apply it to the child as part of the reset procedure. Slow rotation is very hard to achieve in this manner without a certain amount of jerkiness, Omega often gives a better result.

Omega is client-side, so you are having to refresh your viewer because the server has no idea what the amount of actual rotation is. The simplest way to constrain to a parcel is to keep checking llGetPos() and testing X and Y against the parcel bounds.

/me makes a note to himself not to get drawn into playing "Doctors and Nurses" with Innula or Arielle.

I've tried in the past with new users, the biggest problem I think is that there is so much they need to know.It takes a lot of patience and I personally have about five minute's worth of it. However, I've also found quite a few new users are actually returnees, looking for a fresh start. I am starting to wonder if SL has become specialised to the point where it can't be promoted widely to all and sundry as the OP hopes it could be, simply because there is so much to explain, starting with "How do I play this game?" and then going on to explain Gor, RP, ... I honestly think the best thing we can do to prolong SL as an active thing is to help it financially. Spend money on land, clothes, toys, tips, ... Linden's principal revenue source is their percentage they get from all of that. So long as it's a healthy percentage they're not going to be looking for a wind-up strategy.

Molly's suggestion is the simplest if you only ever want to have one instance of an object, there is no need to keep lists of name and keys in the rezzer, the rezzed object does all the housekeeping. One point you need to know is that an object saying something on a channel it is listening to doesn't hear what it says. So add the two snippets she's posted in the object that is to be rezzed, together with any other things you want it to do. If you want to stop an object from hearing the die command, simply close the listen and it will keep going until some other method is used to remove it.

Sooooo, what happens when you rezz four objects all called "ThereCanBeOnlyOne" and they all tell each other to die (I am hypothesising a situation where you manage to rezz them all siulataineusly at the same time)