Jump to content

Innula Zenovka

Advisor
  • Posts

    10,660
  • Joined

  • Last visited

Everything posted by Innula Zenovka

  1. I thought it looked a bit odd, but maybe it's to avoid breaking the permissions by trying to animate someone who's not on the same sim -- that is, if you can't find them, don't try to animate them. If that's the reason, I realise there's a better way of doing it (test for llGetAgentSize), but I can't think why else the 96 meters restriction is there.
  2. Here's an alternative way of doing it, which makes it warn you and then detach itself if it's attached to the avatar. Not tested, but I think it should work. default{ on_rez(integer start_param) { if(llGetAttached()==0){ state running; } else{ llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } attach(key attached) { if(attached){//i shouldn't be! llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer permissions) { if(permissions & PERMISSION_ATTACH){ llOwnerSay("You must rez me on the ground"); llDetachFromAvatar(); } }}state running{ state_entry() { //do explosives stuff llSleep(2.0); llSay(0, "This is a funny candle, it's sparkling!?"); llSleep(1.0); llPlaySound("dynamite", 1.0); llSleep(5.0); llPlaySound("dynamiteboom", 1.0); llRezObject("spark", llGetPos()+<0,0,0>, <0,1,0>, <0,0,0,0>, 0); llWhisper(666,"blowup" ); llSleep(2.0); llDie(); }}
  3. Ah.. if muting the owner works, that's rather less alarming, I guess, assuming you know who it is.
  4. I guess the difficulty -- one difficulty, anyway -- must be to find a way to communicate to a script in an object that's not necessarily on the same sim, and, indeed, not necessarily rezzed in world at all, that it no longer has permission to animate someone.
  5. The relevant jira, as well as the one noted by Rolig, is probably this one: VWR-13228 :Object can obtain and retain permissions indefinitely without avatar's knowledge and no way of knowing who took it - possible security issue LL is apparently well aware of the problem, but designing a fix that won't break existing legitmate content is apparently proving rather tricky, as the comments in that lengthy thread indicate.
  6. Normally I use Dolphin and RLV, which don't have this problem, but I want to install the latest version of the official viewer to test some stuff. Whenever I've done this in the past, it's wiped all my chat and IM logs. Other than moving them to a different location while I do the update, is there a way of avoiding this? I've probably been doing it wrong.
  7. Rufus Darkfold wrote: What viewers support RLV and also support mesh and MOAP? None of them is capable of uploading mesh as yet, but the RLV Version 2.7.3.2, Dolphin V3 and the Firestorm Mesh Beta all support RLV, and can see mesh and MOAP.  ETA: To my delight, Kitty Barnett has updated her Catznip Viewer, which, of course, includes her version of RLV, RLVa, after a long hiatus. Her 2.8 can see mesh and, of course, MOAP.
  8. It appears to have been removed from the list of Public User Groups. Anyone know what's happening?
  9. It's only possible, I think, if you use RLV -- then it's really easy. Simply list the names of your favourite windlight presets in the script, use llDialog to select the one you want and then, in the listen event, have something like llOwnerSay("@setenv_preset:"+message+"=force"); If you don't normally use RLV, don't worry; all you have to do is turn it on, and wear a hud with this script, and nothing else is going to be able to affect you with RLV (for that you would need to be using a relay, too).
  10. NP. I have now, as promised, checked with Live Help and they confirm the rumour is completely baseless.
  11. Sounds like a hoax to me. I will check with live help later today, if i remember, but I can't imagine LL -- bad as they are at communicating at times -- doing something like that without warning us. I'm wondering, though, how much of an issue all these defunct accounts are. Yes, they and their inventories are taking up space in LL's database, but other than that, I wonder how much they actually slow stuff down. I guess an initial cull of -- say -- all NPIOF accounts more than 18 months old who were less than a week old when they last logged in and who haven't logged in for over a year would free up a lot of space, and probably the people involved wouldn't notice the loss.
  12. I'd far prefer it to work on link targets, too, but I think as it stands it's at least a way of acheiving smooth and not too laggy non-physics movement. Let's hope it's just the first stage of something bigger.
  13. A very helpful introduction to llSetKeyframedAnimation, a feature I'm really looking forward to playing with, over in Inara Pey's blog. Apparently it's likely to be available on parts of Aditi soon.
  14. Depends on the script, I guess. In general, though, I try to avoid using llResetScript() unless I do, in fact, want to reset everything, because, more often than not, it means I'm telling the script to reset of things that don't need resetting, which is inefficient, and, quite possibly, I'm wiping out the values of variables I would want to keep. In this example it doesn't make much difference, I agree, but I try to stop myself from using llResetScript too readily.
  15. I've not seen the "Remove Scripts" option in Firestorm, but I don't use Firestorm much; I prefer Dolphin 3 and Marine's RLV. So it could well be lurking somewhere. I agree, "Remove Scripts" is a very useful function to have. If it's not there yet, maybe they'll include it in the next version.
  16. Set Scripts to Running works, too, but for that to work you must take the item back into your inventory after propagating the scripts and then rez it again before trying to set the scripts to running. Otherwise it doesn't work. Both Set Scripts to Running and Recompile are in the Scripts submenu of Firestorm's (or any other V2 or V3-based viewer's) Build Menu Here's what I use to remove scripts: //removes all scripts, particles and bling from a linkset. Put it in the root prim, take back into your inventory, re-rez, select with edit tool, choose "set scripts to running in selection" from the tools menu on the toolbar, and bingo...list contents;integer i;integer max;GiveScriptToLinkedPrims() { integer p = llGetNumberOfPrims(); integer i = 0; for (i = 2; i <= p; i++) { key prim = llGetLinkKey(i); llGiveInventory(prim, llGetScriptName()); }}remove_stuff(){ max = llGetInventoryNumber(INVENTORY_SCRIPT)-1; for(i=max;i>=0;--i){ contents+=llGetInventoryName(INVENTORY_SCRIPT,i); } contents = llDeleteSubList(contents,llListFindList(contents,[llGetScriptName()]),llListFindList(contents,[llGetScriptName()])); max=llGetListLength(contents)-1; for(i=max;i>=0;--i){ if(llList2String(contents,i)!=llGetScriptName()){ llRemoveInventory(llList2String(contents,i)); } } llRemoveInventory(llGetScriptName());}default{ state_entry(){ if(llGetLinkNumber()==LINK_ROOT){ GiveScriptToLinkedPrims(); llLinkParticleSystem(LINK_SET,[]);// comment out (or remove) this line to keep particles/bling llOwnerSay("please take me back into your inventory, re-rez me, and set all scripts to running from the tools menu"); } llSetText("",ZERO_VECTOR,0.0); //comment out (or remove) this line to keep hovertext remove_stuff(); }}
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. I can't find the option to do that anywhere. Maybe I'm looking in the wrong place, or maybe it's been removed?
  22. 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)?
  23. 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(); }}
  24. 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.
  25. 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?
×
×
  • Create New...