Innula Zenovka

I'm not completely sure, but I think it's because what was called "Prim Equivalence", and is now apparently “Land Impact”, for mesh items can change quite a bit if, for example, you drop a script into a non-scripted object . Since it's now possible to go over a parcel's prim limit without necessarily rezzing any more prims, a new way of returning objects is necessary.

Rhys Goode wrote: Server updates are announced every week. For example: http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2011-09-12/m-p/1097979#M2204 Sadly, they do not include predictions about whether or not one of the updates contains a buggy bug fix, or a successful bug fix. Yes, I realise that. But my point was nothing to do with announcements about server updates. What I was trying to suggest, but obviously not sufficently clearly, is that once it's discovered that a server update has introduced a major bug that actually damages content when that content is used normally, it might be a good idea to for LL to warn people of the bug has been discovered, so as to try to minimise the disruption and damage caused by the bug.

I don't think that's particularly accurate any more, Ishtara; Oskar is certainly very active in the Second Life Beta Group, for example, and certainly at least one of the Lindens who has friended me (because of user group stuff I'm involved in) seems to log in and out quite frequently.

Case in point. The last sim rolling restarts including an emergency fix for a new permissions exploit. Unfortunately, this fix introduced a bug that makes attempts to update worn attachments fail, at least, and, at worst and more likely, in some circumstances render them completely useless by deleting scripts they contain. The bug is acknowledged and a fix will apparently be available soon; further details in the jira at https://jira.secondlife.com/browse/SVC-7283 Something -- one of the many things -- that's rather annoyed me about this is that here's this bug that affects, apparently, a lot of content creators and their customers and can -- has done -- breaks a lot of existing content. But LL seems to be relying on in-world groups and on people posting in external blogs, forums and on twitter to get the word out. I found out about it because Amethyst Rosencrans, who discovered the bug after complaints from her customers, opened the jira on it and posted a warning to her product update group, to which I belong. Other content creators have found out about it by receiving complaints from customers and asking in in-world scripting groups WTF is going on, and those of us who're aware of the jira are able to help. But, as yet, there's been no general warning about this, not even on the grid status page (which not that many people read, I think). Yes, Maestro and Oskar have been very open about it in the jira, but people are only going to look there if they've already encountered the problem, whether as a result of customer complaints or as a result of trying to update their collar or hud or whatever and finding it's been trashed. So, I guess my question is, whether people think LL should publicise this sort of major issue -- because of this bug, stuff's not only not working as expected but actually getting ruined -- rather than leave it to residents to spread the bad news and, if so, what sort of warning would be appropriate? I can see the problem that most issues -- certainly this one -- are very important for a not-insubstantial number of residents but don't really affect most people, so it might be a tricky decision about when something's important enough to publicise, but I'm not sure that just relying on residents to get the news out to affected parties is the best solution.

I can't find the option to do that anywhere. Maybe I'm looking in the wrong place, or maybe it's been removed?

Thanks, Miranda. I hadn't seen the api page and will most certainly have a play with it. Void, I don't quite understand what you mean by "I think it's been changed so that only the video uploader can do that now" -- do you mean there's an option I can set when uploading the video to YouTube (in this case, that would solve the problem)?

Try something like this, Amaranthim (and yes, you may take it to any grid you like :matte-motes-grin: string my_anim;string hovertext =""; //if you want any hovertext, put it here, inside the double quoteslist gAnimations = ["express_open_mouth","express_repulsed_emote" ];restartAnimations(){ integer max = llGetListLength(gAnimations) ; string ani ; while (max--) { ani = llList2String(gAnimations, max) ; llStopAnimation(ani) ; llStartAnimation(ani) ; }}default{ state_entry() { llSitTarget(<0.0,0.0,0.25>,ZERO_ROTATION); //change if necessary llSetText(hovertext,<1.0,1.0,1.0>,1.0); llSetAlpha(1.0,ALL_SIDES); my_anim = llGetInventoryName(INVENTORY_ANIMATION,0);//use whatever animation is in my inventory if(llGetInventoryType(my_anim)!=INVENTORY_ANIMATION){//sanity check my_anim = "sit"; } } changed(integer change) { if(change & CHANGED_LINK){ key av = llAvatarOnSitTarget(); if(av){//someone's sat on me llRequestPermissions(av,PERMISSION_TRIGGER_ANIMATION); } else{ llSetTimerEvent(0.0); llSetText(hovertext,<1.0,1.0,1.0>,1.0); llSetAlpha(1.0,ALL_SIDES); if(llGetPermissions()&PERMISSION_TRIGGER_ANIMATION){ av = llGetPermissionsKey(); if (llGetAgentSize(av)!=ZERO_VECTOR){//still on the sim list l = llGetAnimationList(av); integer max = llGetListLength(l); while(max--){ llStopAnimation(llList2Key(l,max)); } } } } } if (change & CHANGED_INVENTORY){ llResetScript(); } } run_time_permissions(integer permissions) { if(permissions & PERMISSION_TRIGGER_ANIMATION){ llSetAlpha(0.0,ALL_SIDES); llSetText("",<1.0,1.0,1.0>,0.0); llStopAnimation("sit"); llStartAnimation(my_anim); restartAnimations(); llSetTimerEvent(1.0); } } timer() { restartAnimations(); }}

According to Maestro Linden's reply in the jira, This error message is sent by the server whenever an avatar or object tries to rez another object which has been blocked by the sim. Usually such assets got blocked because it took too long (longer than 15~30 seconds) to rez, and the sim thinks there might be something wrong with the asset (for example, that the object might be designed by griefers to ruin sim performance). The blocked object should become unblocked after a few minutes, unless the rez attempt is repeated before the all-clear. Those of you who see the error at a constant interval are probably dealing with a rezzer that continuously attempts to rez the object, extending the block. If you look at the script error/warning window that contains the "Unable to create item .." message, you should see the name and region coordinates of the rezzer (this is true in Viewer 2.1 and 1.23, at least)The blocked object should become unblocked after a few minutes, unless the rez attempt is repeated before the all-clear. Those of you who see the error at a constant interval are probably dealing with a rezzer that continuously attempts to rez the object, extending the block. If you look at the script error/warning window that contains the "Unable to create item .." message, you should see the name and region coordinates of the rezzer (this is true in Viewer 2.1 and 1.23, at least) So if it's being caused by one of the objects trying to rez stuff, then taking it to a no-script sandbox and trying to rez it there might be an idea.

If I put a YouTube video on a prim, is there any way (short of resetting the script, I guess, which I don't really want to do) of returning to the start of the video when it ends, rather than stopping at the page with links to other, similar, videos?

When you say, " the tips said something bout a channel that it had to be sent over.." do you mean the vendor said something like "If you want to send this as a gift, say your friend's name on channel 5 in the next 30 seconds and then pay"? If that's what you mean, the vendor is asking you to say /5 Innula Zenovka if you want to send me a present. Then the vendor looks up my uuid using an external service and sends the item to me rather than to you. If you've already bought it and it's no transfer, I'm afraid you're out of luck.

Hi.. please, I would very much like to test it!

Does Phoenix default to showing Old-Style names? I know you can set it to show them, but I thought (and I might be mistaken) that the default is to show the Display Name with the username in parentheses if it's different. Firestorm, I'm sure doesn't use "Resident" by default (and possibly not at all). The only viewer I can think of, offhand, where an account without a last name appearing as "Resident" can't be fixed with a simple change somewhere in the settings, is 1.23. And, since I thought the OP wanted to stop appearing as "Resident" in her chat and IM windows, she can easily fix that, either by changing her settings, or changing her viewer from 1.23 (to Phoenix, Cool VL, Singularity or, I think, Imprudence, if she wants to stick to the older format). And I agree about usernames, but username != legacy name. If a scripted object wants her username in an access notecard or something, and she puts in "ErinClover2 Resident" rather than "ErinClover2" it'll break unless the scripter has made specific provisions for precisely this confusion between usernames and legacy names.

What viewer are you using? While I hate to disagree with Rolig, I'm afraid she's mistaken about usernames; yours is erinclover2, and mine is innula.zenovka and hers is rolig.loon. The "Resident" placeholder was used for a while by viewers that expected everyone to have a last name, but all the major TPVs (and, of course, the official V2) that I'm aware of now know to call you something like "Erynn Clover (erinclover2)" in chat. The short answer to your question, to my mind, is to use a more up-to-date viewer. You'll still see "ErinClover2 Resident" in output from older scripts, because the functions they use, such as llDetectedName(), expect you to have a last name, but there's no need for you to see in chat and IMs.

Once someone repeatedly crashed one of my sims because he was upset about being banned from a club there. I complained, as the sim owner, to LL that it kept on crashing and asked them to investigate, and they resolved the matter very quickly and effectively. They have tools we don't. So my advice is to ask the sim owner to get LL onto the case. In the meantime, turn off rezzing, object entry and running scripts for everyone but group members; while there are ways to get round this, it should stop the more obvious sim-crashing methods.

Do a search for "sandbox". You can build stuff in those.

Thanks for the guide, amarock. Are you, though, talking about scripts causing "lag" (i.e. placing an unnecessary burden on the sim because they're very active) or about taking up a lot of memory? I've not looked in detail at the updater script, for example, so I may be mistaken, but my impression is that it's only using much script time when it's checking to see if there's an update available, which only happens when you rez the collar/attach it or ask it to check. The rest of the time, while it's taking up memory, it's not using any more script time than any other active script that's not doing anything. To my mind, the biggest single thing collar wearers -- be it an Open Collar or any other sort -- can do to reduce the collar's demand on sim script time is to tell collars to stop listening to 0, the open chat channel, and to listen on some other positive channel instead. And that you can normally do with a couple of simple chat commands (http://code.google.com/p/opencollar/wiki/UsersGuide#4.0_-_Control_commands explains how OC users can do it), Open listeners on the chat channel are a bad thing, to be avoided if there's any reasonable alternative (which sometimes there isn't, particularly for vehicles), because they give both the sim and the listening script so much unnecessary work to do whenever anyone says "Hi" to someone else on the same sim.

Can you give some more details of the spec? One option, for example, which might be attractive in some circumstances, is to prepare textures for the sign, and change those by chat command or whatever. This can be combined, sometimes, quite effectively with the " multi-prim single-letter on a face" method Void mentions. So much depends on what the sign's going to be like and what sort of (and how much) text it needs.

Choose "Add" from the right click menu, rather than "Wear".

For more details of Aditi, including how to access it, see https://wiki.secondlife.com/wiki/Aditi

I'm wondering if it would not be a good idea to make all Linden-run sandboxes premium The reason for this is that there's plenty of private and group-owned sandboxes, which are generally far more peaceful and better run than their Linden equivalents. A main reason for this, to my mind, is that, as I understand it, it's very difficult (and probably very undesirable, too) to give residents the sort of group land powers that you sometimes need to keep things running smoothly and peacefully. So, in effect, LL's only way of keeping things under control in their sandboxes is to make it impossible for throwaway alts to come in and cause difficulties. I can see that this might just shift the problem to private or group sandboxes, but they're in a much better position to control things because group officers will almost certainly be able to pay more attention to the situation in a particular sandbox than are LL employees trying to wade through innumerable ARs about almost anything someone's taken exception to.

For what it's worth, using animated textures is far kinder to the sim than repeatedly changing stuff on a timer.

The problem is that the script is listening to whoever was its owner at the time it started running. It doesn't realise that the owner has changed unless you tell it to check, something like this: integer handle;default{ state_entry() { handle = llListen(0,"",llGetOwner(),""); } changed(integer change) { if(change & CHANGED_OWNER){ llListenRemove(handle); handle = llListen(0,"",llGetOwner(),""); } } listen(integer chan, string name, key id, string mes) { if (mes=="on"){ llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.2]); } else if (mes=="off"){ llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0]); } }} The changed event can detect various types of change, including a change of owner. So what the script now says is something like "if the owner changes, stop listening to the old one and start listening to the new one". Is it really necessary to have it listen on the open chat channel? Open listeners on 0 really do contribute to lag and, to my mind, should be avoided unless there's a very good reason to be listening on the chat channel.

I've learned a great deal by asking questions here. And if you need a more immediate response, there are several in-world groups where you can usually find someone who's able to help. I'd recommend College of Scripting, Script Academy and Scripts as three very helpful places where you can usually find some well-informed people who're happy to offer explanations and guidance.

The safest course is to assume you can't unless the site making the mesh available explicitly says you can and, if you're in any doubt, get in touch with them, explain what you want to do, and seek their approval.

This is a bit of a shot in the dark, but what viewer do you use? I ask because if you use a TPV with RLV turned on, I can think of a way someone could be using that to play a nasty practical joke on you, but you'd need to be using such a viewer and also wearing a scripted item they'd given you. It's not very likely, though.