Innula Zenovka

So, leaving aside issues like the Mono rezzing bug, does this mean it's better to compile short, simple scripts in LSO or in MONO?

I know that the idea is that we should eventually be able to specify how much memory we want a Mono script to reserve for itself, but I thought -- and I could be mistaken -- that at the moment, 64KiB get allocated to all Mono scripts, regardless of what they actually happen to be using at the time and regardless of how much they might ever need. I would have thought the fact the memory has been allocated to one script would mean it's not available to allocated simultaneously to another one. Am I mistaken in this?

I thought they combined outstanding balances with your regular accounts, both L$ and US$. I'm pretty sure that's what happened to my monies when xStreet closed.

Acheron Gloom wrote: Thats a surprise to me ;o. Does it do that for all permissions? And when would they dissapear? Could be slightly useful for me since almost everything I make uses permissions, and I always request on attach, when I can just request once on state_entry (due to the way my scripts work). I still think, however, that even having the attach event in the first place would be overall less efficient than only a touch event, since the event activating for attach/detach is much more to do than a quick and simple function, and it would take up more memory/bytecode. And if you're running in mono, the additional memory makes a difference (since mono dynamically allocates and LSL doesn't). I've not tested, but according to the wiki it looks as if all permissions persist, other than PERMISSION_CONTROL_CAMERA, until the script revokes them or is reset. Some TPVs let you revoke PERMISSION_TRIGGER_ANIMATIONS from the viewer, and there's a long-standing jira about making them release permisssions, VWR-13228, but as far as I know, under normal circumstances scripts retain permissions otherwise. I still always test, though, to make sure I've got them. I don't quite understand your point about Mono and memory. Eventually, we're going to be able to allocate memory with mono, or so we have been assured for the last couple of years, but I thought that, at the moment, 64k are allocated to every Mono script whether or not it needs them (as opposed to 16k with LSO). And, at least at present and of particular relevance to llDetachFromAvatar, SVC-3895, "Rezzing Mono scripted object cripples sim FPS", is a very good reason for not using mono in attachments unless you absolutely have to.

They do persist, though, as is easily demonstrated with this example: default{ state_entry() { //llSay(0, "Hello, Avatar!"); } attach(key id){ if(id!=NULL_KEY){ if(llGetPermissions()&PERMISSION_ATTACH){ llOwnerSay("No need to ask for permissions again; got them already"); } else{ llOwnerSay("Need permissions; requesting them now"); llRequestPermissions(id,PERMISSION_ATTACH); } } } run_time_permissions(integer perm){ if(perm & PERMISSION_ATTACH){ llOwnerSay("got permissions now"); } } touch_end(integer total_number) { if(llGetPermissions() & PERMISSION_ATTACH){ llDetachFromAvatar(); } }}

But there's no need to keep on requesting permissions, even though they're granted automatically. They persist, after all, so just asking for them when you attach the object (or even checking, when you attach the object, and asking for them if you haven't got them) would be sufficient. Having said that, I'd always -- as a safety measure -- check I've got the right permissions before actually doing anything, and request them if I haven't got them. Whenever I don't bother, someone always finds a way to lose the permissions, thus breaking things.

Randall Ahren wrote: I do have some experience with LSL scripting, but I have never used that function. From the description, it appears that the avatar wearing the clothing item must grant permission for the other avatar to detach it. That's close to what I want to do, but it would remove some spontaneity in role play. Just to clarify, the script needs to call llRequestPermissions(owner, PERMISSION_ATTACH) once, in the attach event, to work at all.  In addition, it's normal, when making them for sale, to include something that asks the wearer each time someone wants to remove your clothing, because you might not want that to happen every time someone clicks, or to include functionality to add blacklists and whitelists and so on, but that's not necessary for llDetachFromAvatar to work. So if you're happy that anyone can remove the item, possibly by accident, there's no need to have it bother you each time someone clicks it.

Try rezzing the board on the ground, then right click it and select "open". Then click "copy to my inventory" and you should find it creates a new folder in your inventory with the clothes in. You might find this helpful.. http://community.secondlife.com/t5/English-Knowledge-Base/Opening-boxes/ta-p/700185 And just a heads up -- we're not supposed to criticise other residents by name in these forums.

Thanks, everyone.. I've managed -- I think -- to get it working for my purposes by grabbing the avatar's key in the run_time_permissions event and also following up Thex's suggestion, which provides me with a neat way to find out when that particular spot is unoccupied again. It's for an RP item that can seat several people, but I'm only really interested in one of the seats because when someone sits on that is when the fun really starts and my special effects start to happen.

Thanks, but that's not really what I'm looking for. But I've just had a thought .. maybe I'm looking at the wrong event -- because I'll know in the run_time_permissions event when I trigger a certain anim, won't I? /me runs off to investigate....

No strong feelings on the matter. Yes, it's one of the first things I set when I install a new viewer, but I don't find it particularly arduous so to do.

I've got several linked prims, each containing a simple script and a different animation. And, not surprisingly, the appropriate animation plays when I sit on the appropriate prim. What I'm stuck on is, how do I tell when someone has sat on a particular prim, thus triggering the animation it contains? As it happens, I know the UUID of the anim, so I guess I can check llGetAnimationList whenver someone sits down, but that seems a very complicated way of doing things. I can't use llAvatarOnSitTarget() in the changed event on its own, I don't think, because AIUI that's just going to tell me the last person who sat, no matter prim it was. I want to know when someone sits on link number n, thus triggering animation such-and-such. The sim must know, somehow, which child prim someone has sat on, because it sends the right animation to the viewer. But I can't figure out how my script can find out -- which frequently means it's simple really but I've missed someting basic.

Randall Ahren wrote: Maybe it is because there is a script that can be dropped into a modify item that will clone the item so that others are then able to copy it and sell it as their own. It's possible to copy the prims that way, certainly, but you can't read the uuids of sculptmaps or textures by script unless the item is full perms. To my mind, that must make using llGetLinkPrimitiveParams a very unattractive tool for someone who wants to rip off content -- far easier to use a ripper client (or the regular viewer plus something installed on your PC alongside it), since that doesn't worry about perms at all. I take the point about creators not wanting people to start modding their items and making a hash of it, thus making them look bad, but, on the other hand, I like looking good, too, which means wearing stuff that fits, so I take a lot persuading to buy anything I can't modify. And I won't buy no-mod hair or clothes (as opposed to shoes and jewelry, sometimes) because there's no need to -- plenty of people sell very good quality items you can adjust.

Yoki Enoch wrote: leliel Mirihi wrote: Yoki Enoch wrote: Since I do not use a TPV but only the "poorly operating" Viewer 1.23, you have me at a disadvantage. At least with my Viewer 1.23, I can tell you how many estate sims are available for sale or lease at any moment in time, whereas you can't. You can do that in any v1 based viewer...even TPVs. It is a bone basic function that one can not do in Viewer 2.x - just one symptom as to why it is a piece of crap. Yeah, most people need to know how many estate sims are available for sale or lease at any momet at least once a ... errm.... Seriously, because I've always used For Sale By Owner to buy and sell stuff, what's V1 got in the regard that V2 hasn't, if you sort the land for sale in descending order by size?

One problem, which would certainly account for the ball's returning to the start position, is that the original target doesn't get removed properly. Take a look at llTarget(), at_target() and llTargetRemove()

As Darkie says, it sounds like something else in your script that's causing the problems. Here's a very basic script that works for me -- just tested it: default { state_entry () { llSetStatus (STATUS_PHYSICS, TRUE); // make sure that Physical is turned on } collision_start (integer total_number) { llSay (0, "Collided with "+llDetectedName (0)); llApplyImpulse (<2, 0, 0>, FALSE); }} ETA -- there's a tutorial on making a kickable ball at http://www.ibm.com/developerworks/rational/tutorials/r-radsl/section3.html (the first two sections you can skip -- it's all about how to install Eclipse and stuff -- and the interesting stuff starts at that link).

Tigger Genira wrote: Gibraltar are kinda/sorta in the EU does anyone know if privacy legislation extends to them ? Do they have to take account of the Data Protection Act ? They have to take account of the EU Directive, certainly. http://www.gra.gi/index.php?site=dataprotection&section=main

Yoki Enoch wrote: Innula Zenovka wrote: Yoki Enoch wrote: leliel Mirihi wrote: Yoki Enoch wrote: Do what? Cripple SL? LL will do this because that is its destiny. It had a good shot at it 3 years ago and almost succeeded. This time it has a much better chance.. You're intentionally dodging the question and invoking the will of the gods, aren't you? What makes you so certain that LL will one day prevent TPVs from logging in? For those who can come up with a scenario that could not possibly be put into effect because of its stupidity, have yet to meet Linden Lab. The creation of Viewer 2.x is testament to this fact. There's a big gap, though, between "something could possibly happen" to "it's going to happen" or even "there is any indication it's likely to happen," is there not? Oh yes, there are big gaps there. We can be assured though that as long as LL keeps pushing Viewer 2.x, SL will keep declining in use. Ever since Viewer 2.x was introduced, the decline in concurrency started a downward trend. You can see this by LL's own published stats. Why oh why LL doesn't try to hide those stats too is beyond my comprehension. You will, of course, be familiar with the logical fallacy post hoc, ergo propter hoc. Surely LL's banning traffic bots and also changing the search ranking methods to make traffic gaming less rewarding anyway must have had some effect on concurrency, too? At least some of the fall in concurrency must be because not so many people are now bothering to keep umpteeen bots logged in, surely?

Yoki Enoch wrote: leliel Mirihi wrote: Yoki Enoch wrote: Do what? Cripple SL? LL will do this because that is its destiny. It had a good shot at it 3 years ago and almost succeeded. This time it has a much better chance.. You're intentionally dodging the question and invoking the will of the gods, aren't you? What makes you so certain that LL will one day prevent TPVs from logging in? For those who can come up with a scenario that could not possibly be put into effect because of its stupidity, have yet to meet Linden Lab. The creation of Viewer 2.x is testament to this fact. There's a big gap, though, between "something could possibly happen" to "it's going to happen" or even "there is any indication it's likely to happen," is there not?

https://wiki.secondlife.com/wiki/Under_Age_Boot

We had a discussion about how to do something very similar over in SLU's scripting tips last year -- http://www.sluniverse.com/php/vb/scripting/40643-diving-into-rotations.html. You might find that helpful. And this might be worth a look at, too http://www.sluniverse.com/php/vb/scripting/50228-need-help-tiny-zeppelin-script.html

Yoki Enoch wrote: Innula Zenovka wrote: Yoki Enoch wrote: I can cope with the Viewer 2.x interface, just like I can cope with an MS-DOS interface versus a Windows 7 interface. However, I refuse to downgrade to Viewer 2.x, in the same way I would refuse to downgrade to MS-DOS 6.1. Yeah, but if someone asked me to explain why I would find MS-DOS now so difficult to use as compared with Windows 7, it would be easy for me to tell them that I can't remember all the commands and find remembering file paths, and typing them out in full, and having manually to change directories, and so forth, very arduous as compared with just clicking on stuff with my mouse pointer and using context menus and dragging and dropping and so on. What is it about V2 that you find similarly arduous? I simply refuse to use downgrades unless forced to do so. With SL, I am not so forced to do so. Thus, when I am forced to use the Viewer 2.x interface, I simply won't. Since it takes 3 to 4 extra clicks to accomplish the exact same thing one can accomplishes in a Viewer 1.x viewer with fewer clicks, not to mention the non-existent search function in Viewer 2.x, which is affecting the economy in SL, believe it or not....should I go on? While I know people say everything takes a lot more keystrokes, I can't say I've noticed it most of the time when I'm building and scripting, though looking at (and changing) permissions on items in your inventory is a bit of a pain. And I am told that if you're a serious clothes-maker, V2 isn't the viewer of choice, which I can understand. Search could certainly use some work, or so I am told, but I've long been out of the habit it of using because it was -- at least when i gave up on it, almost four years ago, just after I started -- pretty hopeless, anyway. So I couldn't say for sure. In contrast, some things, like being able to pin your favourites to a hideable menu bar at the top, are great timesavers -- just click and tp. And I find being able to put multiple items on the same clothing layer a huge convenience when putting together outfits -- e.g. a long blouse or shirt and a jacket on the same layer, which always looks better than having the blouse as two separate layers. It's also a moneysaver -- instead of buying several different skins, identical safe for the makeup, I can get one base skin and some packs of lipsticks, eyeshadows and so on, as tattoo layers, at considerably less expense. I tried V2 when first it came out and hated it, so I saw no reason to bother with it. But earlier in the year I decided to bite the bullet and familiarise myself with it, partly because I wanted to be sure my scripts, particularly RLV ones, worked the same way in both V1 and V2-based viewers (they don't always -- and my advice to any serious scripter now is to test your products, RLV or not, in both viewers plus the main TPVs, otherwise you're asking for trouble), and partly because I wanted to be able to support customers who use V2. So I made myself start using Catznip, Dolphin and Marine's RLV, and found that they really weren't too bad to use. And after a little while, I decided that, for me at least, their benefits outweighed their disadvantages, at least for most purposes. So now I use one of those all the time except when I need to take advantage of the specialised building tools in some of the Snowglobe-based TPVs (being able to have the edit window do simple mathematical calculations is sometimes very useful, for example, and for that I use Imprudence). You used the comparison of Windows 7 and MS-DOS. I think a more accurate comparison -- based on my experience, anyway -- would be between XP and Windows 7. I was quite content with XP and only changed because I upgraded my PC, and for a few days I didn't much like Windows 7, because a lot of stuff wasn't where I was used to finding it -- though I soon overcame that -- and some things were - - and continue to be -- simply easier to do in XP. But, on the other hand, there's lots that's easier in Windows 7 and, on the whole, I'm glad I switched. All I'm saying is that, while it may well have been reasonable to dismiss V2 out of hand when first it was released -- I did, after an hour or so -- it's no longer reasonable so to do, particularly if you apply one of the Starlight skins. I don't say people should use it, but I do say that they shouldn't be put off trying V2.6 simply because they hated V2.1.

Yoki Enoch wrote: I can cope with the Viewer 2.x interface, just like I can cope with an MS-DOS interface versus a Windows 7 interface. However, I refuse to downgrade to Viewer 2.x, in the same way I would refuse to downgrade to MS-DOS 6.1. Yeah, but if someone asked me to explain why I would find MS-DOS now so difficult to use as compared with Windows 7, it would be easy for me to tell them that I can't remember all the commands and find remembering file paths, and typing them out in full, and having manually to change directories, and so forth, very arduous as compared with just clicking on stuff with my mouse pointer and using context menus and dragging and dropping and so on. What is it about V2 that you find similarly arduous?

Yoki Enoch wrote: Innula Zenovka wrote: BayleeSimone wrote: If I have to take a class to figure it out, it is too complicated. I dunno. Phoenix is a very popular viewer, of course, despite the fact they offer frequent classes, "Phoenix 101", in how best to use it. That suggests to me a fair number of people must feel in need of assistance in figuring it out. Oh boy. LL dares not reveal that Viewer 2.x needs a post-graduate degree to learn how to use it. Forget "Viewer 2.x 101". All I can say is I can't see how it's any more complicated for a new user than is 1.23, which is hardly the most intuitive of UIs, though we all rapidly became used to it when first we started. And I didn't find it particularly taxing to get used to the new V2 UI. I found it a bit like driving a new car you're not used to; it's a bit hairy at first because everything's in the wrong place, but after a day or so it's second nature. The keyboard shortcuts are all the same, as far as I can tell, which I found a great help. What do you find so difficult about it? I'm not disagreeing with you, nor saying you should like, or even use, V2. It's just I use Marine's RLV a lot and -- maybe because it's got a Starlight skin -- I find it perfectly simple to use.

You might find some of the Mobile Device Clients discussed here of interest: http://www.sluniverse.com/php/vb/alternative-sl-clients/48834-chalices-list-sl-clients.html#post1016314