Jump to content

Innula Zenovka

Advisor
  • Posts

    10,717
  • Joined

  • Last visited

Posts posted by Innula Zenovka

  1. Sorry, I'm confused.   I've updated Blue Goo in both Chrome and Firefox 4.  

     Sample scripts produced in both LSLEditor and Notepad++ look OK when I copy paste them and press the +LSL button but when I click Preview it seems (both visually and from the HTML) to take out all the tabs and carriage returns/line feeds.   And when I copy paste the results back to either editor, I just have one long line of code.

    Have I missed out a crucial step somewhere?

  2. I've not tested it, but something on these lines might do it.    The idea is that llGetObjectPrimCount(llGetKey()) will return the number of prims in the linkset -- assuming it's in the root prim, otherwise I guess you need llGetObjectPrimCount(llGetLinkKey(1)) -- while llGetNumberOfPrims() is prims plus seated avatars.

    Worth a try, anyway.

     

    key av;
     default {
     state_entry() {
     llSitTarget(<0.0,0.0,0.5>,ZERO_ROTATION);
    }
     changed(integer change) {
     if(change & CHANGED_LINK){
     av = llAvatarOnSitTarget();
     if(av!=NULL_KEY){
    if(llGetNumberOfPrims()>(llGetObjectPrimCount(llGetKey()) + 1)){
     llUnSit(av);
     }
    }
    }
    }
    }

     ETA -- dunno what's happening with the editor

    • Like 1
  3. As far as I can remember from SnowGlobe, you used to be able to change the default texture for prims by putting in the appropriate UUID in Debug Settings -- DefaultObjectTexture and relogging.

    Then after you'd done that, while prims still rezzed as plywood, you could change them to your preferred default texture by going to the texture picker, clicking blank, and then clicking default again.

    I can't, though, get this to work in 2.6.8 -- the value for DefaultObjectTexture just reverts back to the default plywood,"89556747-24cb-43ed-920b-47caed15465f", each time I relog. 

    Am I doing it wrong or is it broken?   I've not tried doing it before in V2.

  4. Yes, I understand.

    But I am asking if you get this message everywhere, or just on one sim.  

    There are several different reasons you might be getting this message, and if you can tell me if you get it everywhere you go, or if you only get it on one sim, then that will help me to know what the most likely reason is.

  5. The line is as I posted it -- llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]);

     

    Note the [ square brackets ] round [PARCEL_DETAILS_NAME].

     

    They are there because lsl uses them to enclose lists, and, as you will see if you look more closely at the wiki article, llGetParcelDetails requests a list of details about the parcel -- you're using it to request a list with only one item, but you could just as easily be asking for details of the description, owner, size, and stuff at the same time, so the request has to be presented as a list, and lsl knows something's a list if it's enclosed in square brackets.

     

    Since you've asked for a list of details about the parcel, you get a list in reply, albeit one with just one item, so you will need to decode the list, using the format llList2String(my_list,0); That means "find the first item in the list (lsl starts counting at 0, not 1) and turn it into a string so you can say it, or display in hovertext or whatever.

     

    Tl;dr -- you need the [ ] round PARCEL_DETAILS_NAME or it won't compile, and you need to turn the results of the call into a string so the script can do something with the parcel name when it knows what it is.

    • Like 1
  6. The syntax is llGetParcelDetails(vector pos, list params);

     

    So something like this should do the trick.  

     

    default{	state_entry()	{		//llSay(0, "Hello, Avatar!");	}	touch_start(integer total_number)	{		llOwnerSay(llList2String(llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]),0));	}}

     

    ETA -- what this means is that llGetParcelDetails takes two arguments -- the vector location of the parcel whose details you want and a list of the various possible details you want it to tell you.  

    It returns a list of what those details are -- it has to be a list, because you might be asking for the parcel description, or its owner or area or whatever as part of the same call.   In this example, you're only asking for the description, which is a string and is the first (and only) item in the list that's returned, so you change it into a usable string with llList2String(list, 0) -- "find the first item in the list and return it as a string".

  7. Another way to do it would be to turn the listener on and off each time you wear it.   This way, though, it's only going to listen to you when it's worn:

     

    integer g_intListenHandle;default{	state_entry()	{		updateParticles();	}	attach(key attached)	{		if (attached!=NULL_KEY){			g_intListenHandle=llListen(5,"",attached,"");		}		else{			llListenRemove(g_intListenHandle);		}	}	listen(integer channel,string name,key id,string message)	{		if(message=="fall on") updateParticles();		else			if(message=="fall off") llParticleSystem([]);		else llOwnerSay("usage:\n/5 fall off\nor:\n/5 fall on");	}}

     

     

    • Like 1
  8. Are you getting this annoying message everywhere, or only on one particular sim?

    Try TP-ing somewhere else and see if that stops it.    Then TP back to where you were before and see if it starts again.

    You see, one reason you'd get this message is if you rezzed the item rather than wore it as a hud or attachment (and when you say it's not appearing in your inventory, that makes me wonder if you rezzed a no-copy item).   The only fix, if that is the case, is to try to find the item, take it back into your inventory and wear it.

    If you are on a private island, the owner or someone with estate rights should be able to locate it for you, and return it, using the estate management tools.   I don't know how it works on the Mainland, though.

  9. As Blackdog suggests, it sounds like you need to update the listener to listen to the new owner (I'm assuming, since it's a dress, only the wearer can talk to it).

    Try dropping this changed event  into your script -- there are more elegant ways of doing it, but without seeing the script, this is all I can suggest that I know will do it.

     

    changed(integer change){		if(change & CHANGED_OWNER){			llResetScript();		}	}

     

     

    • Like 1
  10. When I had two adjacent islands, I sometimes used Ezian Ecksol's Camjumper script to get between the two of them.   That goes in an attachment, finds your destination by where your camera is, and then calls llMoveToTarget repeatedly to move you there very fast -- so fast that you normally blast through apparently solid objects with ease.

    I don't know, but I'm wondering if the same method wouldn't get you from sim to sim if you sat on something that used it.   I know warppos looks as if it should, but doesn't do it at all reliably, so I'm not sure how well the physical equivalent would do.  Though, as I say, when called from an attachment it always worked well for me.

     

  11. Thanks, everyone.    Void's method seems ideal, combining the advantages of both.

    There's one thing I don't understand, though.   If I set TEMP to FALSE when I sit down and then back to TRUE when I stand up, does the timeout period always restart or does it depend on whether the initial timeout period has expired while TEMP was FALSE or what?

  12. Why do some people see Ruth, still, and most of us see clouds? I know you can -- or used to be able to in 1.n -- to change a debug setting to get Ruth back, but it's not the sort of thing you'd do without realising it, I would have thought. Sometimes, come to think of it, I see people as Ruth very briefly when they''ve TPd to where I am and are still rezzing (like still in the air), but not very often.

  13. I'm making some items, containing animations, that people can rez from a hud.  

    I want the items to delete themselves after use, but not immediately (so that if the user clicks the wrong button and unseats him- or herself, there's a grace period to get back on). 

    What's safer -- start a timer on rez and start, reset and stop it in the changed event, or do the same with PRIM_TEMP_ON_REZ (or doesn't it matter?)?

  14. What a horrible thing for someone to make. Your friend, I am afraid, doesn't sound like a particularly nice person -- particularly because if he or she knows enough to make something like that, he or she must also know that an experienced RLV-user like me would realise very quickly that something was amiss, possibly as soon as they attached the piercing (if they've got RLV debug messages turned on, which I have a lot of the time), and know to relog without RLV, get rid of the thing and AR him. So his intended victims must be the naive and inexperienced.

  15. As Vania said, the only way that someone can force-tp you somewhere and prevent you from leaving is if you're using a third-party viewer with RLV enabled and if you're also wearing something that's designed to let people force-tp you and and stop you leaving (i.e. just using and RLV viewer and enabling RLV doesn't  do much in particular) and (at least with any legitimate RLV product) that you've explicitly told the thing you're wearing that people can use this functionality on you.

    The simplest way for your daughter to check if she's got RLV turned on or not (and people do get confused sometimes) is for you to send her an IM while she's online, simply saying "@version" (without the quotes -- just @version on a line on its own).   If RLV is turned on, she won't receive the message but you will receive an automatic reply with details of the version she's using.   Then she can simply turn it off and relog, or use the official LL viewer.

    If anyone does find themselves in a predicament from which they can't, because they're using RLV, extricate themselves, there's always a very simple solution.   Either turn off RLV in the viewer's preferences and relog or simply log out and relog using the official viewer.   

    But, as I said, the only way this can have happened with RLV is if she's wearing something designed for role-play that's let it happen.   If she'd like to IM me (here or in-world) I can probably help her identify the item and tell her how to use it safely.

     

    • Like 2
  16.  


    Kenbro Utu wrote:

    So you have to update the sit target as the child prim moves.  That could qualify as a pseudo-trick.  :smileywink:

     

    Well, sort of.   Except you aren't updating the sit target at all (that doesn't have any effect while the avatar is seated, you see).   The UpdateSitTarget function by Strife Onizuka and Escort DeFarge (which poseball-free animation systems like nPose and Perfect Sitter use) uses llSetLinkPrimitiveParams to move the avatar about in the way we've all wanted to when we've said, "If only you could update the sit target when someone's sitting". 

    I took their calculations and method and played round with them a bit to get the platform child prim and the avatar sitting on it to move together to the correct end positions without drifting too far apart in transit.

     

     

  17. In that case, so long as you're careful about what order you turn things on and off, I think llMove2Target should do what you want.   When I'm stopping stuff, I always turn physics off first, before I do anything else, and when I'm starting I always turn it on right at the end of calculating everying, just before I start moving again.  And if I'm making the object phantom, then I don't do that, if I can help it, until I'm actually moving.

    The not_at_target event, which is called constantly while you're moving, is a very good place to check if you're where you think you should be and to take any necessary corrective action.

    As a general point, I would suggest putting a listener in your moving physical object when you're testing it , though, that either turns physics off and uses posjump to bring the object back home, or simply kills it, and having a simple prim by you, which calls something like llRegionSay(some channel, "where the **** did you go?") when you touch it.    I have learned this the hard way.

×
×
  • Create New...