Jump to content

Innula Zenovka

Advisor
  • Content Count

    9,388
  • Joined

  • Last visited

Community Reputation

2,737 Excellent

4 Followers

About Innula Zenovka

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm trying to debug something and I'm running into difficulties understanding data I'm seeing because, I realise, I'm not completely sure how llSensor is supposed to behave. Assuming I'm looking for scripted objects called "Target" in an environment where there are probably a lot of scripted objects around. I know from the wiki that "Only 16 objects will be scanned each time." I know that this means if I call llSensor("","",SCRIPTED, 20.0, PI); it will return a list of up to 16 scripted objects, if there are that many within a 20 metre radius, ordered according to how close they are to the scanner. However, what I'm less sure about is whether the simulator actually picks the 16 nearest objects and presents them in an ordered list, or if it picks 16 objects within the radius according to some other criterion and then orders them by distance from the scanner. I suspect it's the former but I'm, given what I'm seeing in my tests, I'm not completely sure, and would find it very helpful if someone knows the definitive answer. Similarly, if I run llSensor("Target","",SCRIPTED, 20.0, PI); am I guaranteed to find all the scripted objects called "Target" within the 20 metre radius, up to a maximum of 16, or will the scanner scan all the scripted objects in range, select 16 according to whatever hidden criteria it uses, and then return details of any that happen to be called "Target"? I would expect the former behaviour but, based on what I'm seeing, I'm really not sure. Again, it would be very helpful if anyone could point me towards the definitive answer.
  2. https://www.hrc.org/blog/hrc-files-amicus-brief-with-major-companies-supporting-trans-students
  3. Depends how much he wants to receive blank looks from the whole class.
  4. If the OP wants to make the emoji vanish, wouldn't it be better to display TEXTURE_TRANSPARENT rather than TEXTURE_BLANK ?
  5. To avoid problems with IP, people might want to try this (untested). Drop it in an object (an attachment, maybe) and touch it to get a warning if anyone on the parcel is wearing fangs or "colmillos." It's completely untested and I make no promises that it will even work but I think it should do pretty much what the magic ring is said to do. I post this not because I have anything in particular against vampires (so long as they don't send me unsolicited bite requests) but in order to reduce the reasons people may think they have for redistributing things without the creator's permission: //posted by Innula Zenovka under the "This example script is completely untested and comes with no guarantees whatseover, and I certainly don't promise to provide tech support for it, do whatever you want to with it but I'd prefer you dont sell it" licence. default { touch_end(integer num_detected) { list lAvs = llGetAgentList(AGENT_LIST_PARCEL, []);//check all avs on the parcel if(lAvs != []){//if there are any integer iMax = -llGetListLength(lAvs); do{ key k = llList2Key(lAvs, iMax);//check each av in turn list temp = llGetAttachedList(k);//get a list of av's attachments if(temp != []){ //if av is wearing any integer index = -llGetListLength(temp); do{ key kAttachment = llList2Key(temp, index);//check each attachment in turn string str = llList2String(llGetObjectDetails(kAttachment, [OBJECT_NAME]),0);//get the name if(~llSubStringIndex(llToLower(str), "colmillos")|| ~llSubStringIndex(llToLower(str), "fangs")){//if it contains "colmillos" or "fangs" -- not case sensitive llOwnerSay("Beware! The avatar called "+llGetDisplayName(k)+" ("+llGetUsername(k)+") is wearing an attachment called "+str+" and may therefore want to spampirize you");//then warn the owner } } while(++index); }//end if temp } while (++iMax); }//end if lAvs } attach(key id) {//added to ensure the script keeps running in no-script areas, provided it was attached in an area where scripts are allowed if(id){//item has just been attached llRequestPermissions(id, PERMISSION_TAKE_CONTROLS);//needed to keep script running in no script areas } } run_time_permissions(integer perm) { if(perm & PERMISSION_TAKE_CONTROLS){ llTakeControls(CONTROL_FWD, TRUE, TRUE);//needed to keep script running } } }
  6. As a general point, anything I post here (as opposed to in the Script Library, should I ever get round to doing that) is to demonstrate a point about how to do something and almost certainly requires further work (particularly error handling) before it's suitable for use in a finished product. I think Rolig once said any examples posted here should be treated like a example on a chalkboard (thus showing her and my age) in response to a question. I think that's the best way to use them.
  7. Because shop owners who don't have areas in their shops where rezzing is allowed frequently say that their customers prefer to be able to attach a box containing the item(s) and have the contents appear in their inventories rather than have to take it home to unpack. Often these boxes are in the form of a shopping bag, complete with holding animation.
  8. That looks like a script I've posted somewhere (my style of formatting and the sort of comments I put in public examples). If it is, then clearly I missed out a test in the changed event, to ensure the script gives the folder there only if it's rezzed on the ground rather than attached to the avatar. Something like this: list lContents; string strFolderName = "A folder of goodies";// change to the name you want for your folder default { state_entry() {//some preliminary work to set things up //first, populate the lContents list string strThisScript = llGetScriptName();//note the name of this script, since you don't want to give that as part of the folder integer max = llGetInventoryNumber(INVENTORY_ALL);//note the number of items in the object's inventory integer counter = 0; do{ string str = llGetInventoryName(INVENTORY_ALL, counter);//check the name of each item if(str!=strThisScript){//and if it's not this script lContents +=[str];//add the name to lContents } } while(++counter < max);//and keep on doing this, advancing the counter each time, until all items have been checked. if(llStringLength(strFolderName)== 0){//sanity check -- if no folder name is provided strFolderName = llGetObjectName();//then use the name of this object for the folder } } changed(integer change) { if(change & CHANGED_INVENTORY){//if the contents of the object's inventory change llResetScript();//then reset the script in order to rebuild the list } else if(change & CHANGED_OWNER){//if the object's owner changes, give the folder to the new owner if(!llGetAttached()) {//if the object is not attached llGiveInventoryList(llGetOwner(), strFolderName,lContents);//give the folder to the new owner } } } attach(key id) { if(id){//if someone attaches the object llGiveInventoryList(id, strFolderName,lContents);//give them the folder } } }
  9. @Qie Niangao I know it's supposed to detach automatically when you enter a parcel that doesn't have the Experience allowed but, at least in my experience, that's not wholly reliable. At least it certainly wasn't particularly reliable during the early days of Experience Tools, shortly after they were released. Then I ran into all sorts of difficulties with HUDs not detaching after people left the region, so I got into the habit of including some code to ensure that they would definitely detach even if the expected automatic detach didn't work. That, however, may now be redundant. I don't know because I've always -- possibly now unnecessarily -- included similar code since then to ensure things work at expected.
  10. Sorry for the delay in replying -- I meant to and then First Life became rather busy and I forgot! Thanks for explaining your reasoning. I understand now what you mean, but all I can say is that I don't read the section in the same way you do. I understand the whole article to mean that LL were interested in introducing mono primarily because it runs so much faster on their servers, thus allowing a lot more script actions to take place at the same time without slowing down other operations. They weren't particularly interested in how much memory the scripts use, since, as the article puts it, I don't understand how that works but somehow using Mono means that, while individual scripts use up to four times as much memory as do LSLO ones, because Mono allocates memory more efficiently this means LL can run them using the same memory capacity as LSLO scripts (maybe less, even). So my take on the article as a whole is that LL wanted to introduce Mono so they could run more scripts simultaneously without increasing processor capacity. To ensure nothing broke in the process this meant they had to increase the memory allocation for individual scripts but the question in LL's corporate mind at the time was "how much memory should we allow existing scripts to have so they don't break when compiled as Mono?" rather than "what's the least amount of memory we can get away with giving them?" That is, they were focussed on making the transition to Mono as seamless as possible, and that's all. But now I do see how you reach the conclusions you do, even though I don't read the article the same way you do.
  11. That's certainly how I would do it changed (integer change){ if(change & CHANGED_REGION){ llDetachFromAvatar(); } } As far as I remember, that works even if the new region doesn't support the experience. Since temp attach items die when detached , that should be all that's needed
  12. My advice for a workaround would be to display a numbered list of names, and have the buttons display the numbers. Click the corresponding number to chose a particular name. That's how I always handle names in dialogs now. I don't like to use llGetUsername for these purposes because people clearly prefer to be called by the name they've chosen as their display name and often it's the only name people see in their viewers, at least without taking extra steps to see what the avatar's username is. Fortunately, there's a very good example readily to hand, by Rolig. I would suggest trying that approach and see how it suits you
  13. Do they wear attachments besides HUDs? As you'll know, llGetAttachedList can see the former but not the latter, unfortunately.
  14. Thanks, @Whirly Fizzle I think there was more to it than that, though, wasn't there? I recall I first became of it when one of the "whitehat" devs (LordGregGreg) went public about it, and warned everyone on his friends list (including me) that he was no longer confident Emerald was safe to use. It's too long ago to remember the details but I'm sure I recall mysterious commits to the repository and checksums played some role in it all.
×
×
  • Create New...