Innula Zenovka

Thank you so much.

I want to highlight scripted objects, 'cos I've lost something. In Snowglobe-based viewers I would have done View-Beacons etc. How do I do it in Viewer 2? All the stuff in the wiki and KB I have been able to find seems to talk about how to do it in V1.23.

Something like the wiki's example of a HTTP Post request to a PHP server, do you mean, or these LSL HTTP server/examples?

This article (by an RL graphic artist) on proportions and SL shapes is worth reading.

As an alternative to a particle effect, and depending what you're making, you might consider llSetTextureAnim. I've used that to create quite satisfactory effects for some items my business partner and I make for our vampiric customers.

I've not been asked for it a great deal as yet, but I fully expect so to be as people find it increasingly difficult to find one-word names that haven't been taken as usernames and, understandably enough, lose patience and call themselves jane123 on the basis they can choose a more sensible display name later. When I have been asked about it, it's been primarily for interactive devices for the RP market; for example, I make stuff that lets you animate (and do other things, if your willing victim uses RLV) another avatar. People like the menus to say "what do want to do to Innula?" or give a list of names, and I can quite understand that, if someone's gone off to Gor or the realms of fairie and adopted a suitably Gorean or Sidhe name, they'd rather the toys use their adopted name than insist on calling them "bill789". My main problem is deciding how things that refer to you by your first name, if you have more than one, should cope with someone like "The Mighty Quinn" or "Old Mother Hubbard." I suspect they'll have to put up with being called simply, "The" or "Old," but I'm suspending judgment on that one for a bit.

Not being able to open boxes drove me almost to tears when I started. But at least now I can take comfort in the fact I know that nothing in SL, not even the complicated scripting or building problem, can possibly be as impossible as once I thought opening boxes must be, and that turned out not to be too difficult after all. First, make sure you are logged in using "advanced mode" in the drop down menu on the log in screen. Then, find somewhere you can rez stuff (type in "sandbox" in search if you need to) and follow the simple instructions outlined here

Yeah, but look up the store mentioned by the OP in the Marketplace, and look at what they sell, and look at how long the owner has been in SL. Sure doesn't look like a fly-by-night BOB operation to me.

I rather gave up on trying to get my head round some of the problems associated with trying to script stuff that uses people's Display Names for communication because of the problems llGetDisplayName was having, and concentrated instead on making sure stuff could handle one-word usernames and handle both legacy names as well as legacy names in a username format (that is, it can cope with names in the formats bob123, Bob123 Resident, innula.zenovka and Innula Zenovka). Is llGetDisplayName now reliable enough to merit time working on again? I've not seen loads of ???s above people's heads lately, but I don't know how much to read into that.

Heavens -- are you saying that because you paid annually (as do I) you weren't able to switch to a monthly billing cycle?

No, you can use multiple attachments, using the V2 system, in 1.2n-based viewers like Dolphin, Phoenix, Cool VL and Singularity, certainly. I switch between those and the official and TPV V2 viewers a lot and my attachments all stay put. You can only have one clothing item on a layer in anything V1 based, but most 1.23-based TPVs now support the V2 version of multiple attachments in the same slot.

It works on all recent Viewer 2-based viewers, official and TPV, as far as I know. Most Snowglobe-based TPVs support multiple attachments (apart from Imprudence, I think) but none can cope with multiple clothiing or tattoo layers. The official viewer 1.23 can't handle multiple attachments, either.

Is this the sort of mechanism you mean? default{ state_entry(){ llSitTarget(<0.0,0.0,0.25>,ZERO_ROTATION);//need a sit target for the changed event in the next state to work llSetClickAction(CLICK_ACTION_TOUCH); } touch_start(integer total_number) { llSay(0,"Touched"); } touch_end(integer total_number) {//nb -- if you want to change states in a touch action, DONT use touch_start -- //if you do, the first touch action in the new state won't fire state next; }}state next{ state_entry() { llSetClickAction(CLICK_ACTION_SIT); } changed(integer change){ if(change & CHANGED_LINK){ if(llAvatarOnSitTarget()==NULL_KEY){//when someone gets up state default;//back to default } } }} ETA: If you do want to force sit people as part of a touch event, then you (and they) need RLV. Assuming you want it to work on anyone wearing an active RLV Relay rather than just the owner of the object, the basic syntax is integer rlvrc = -1812221819; //the channel, by convention, all rlv relays usestring arbitrary_indentifier = "sit"; //part of the rlv syntax -- doesn't do anything in this example but has to be theredefault{ state_entry(){ llSitTarget(<0.0,0.0,0.25>,ZERO_ROTATION);//need a sit target pr the RLV won't work } touch_start(integer total_number) { llSay(rlvrc,arbitrary_indentifier+","+(string)llDetectedKey(0)+",@sit:"+(string)llGetKey()+"=force"); }} The toucher's relay processes the rlv command and makes the toucher sit on the prim (which has to have a sit target). You can have other stuff happen either in the touch event or the changed event when the avatar sits.

How would a "one time payment of $25 USD (or yearly fee) to open business in Second Life as a merchant" help customers if, having paid the fee and been in business for some time -- possibly years -- a bona fide merchant then took an extended break from SL for whatever reason and his or her vendors started to malfunction during his or her absence?

You might try asking your question about Imprudence over at the Imprudence Help Forum, too. I've always found them very helpful indeed.

Probably best to click the Watch On YouTube button, so you see it full size, or look at the wiki article on Multiple Attachments, which is where I found the video.

What's the best way of testing list source; string test; if(~llListFindList(source,[test])){ //test is in the list } without needing to worry about inconsistent upper- and lower-case letters (which drove me almost to tears yesterday before I realised that was why things weren't working right)? So far I've come up with if(~llSubStringIndex((llToLower((string)source),llToLower(test))){ } but I'm wondering if there is a better way. There usually is.

I'm glad it's working again, but I would really strongly recommend considering some variation of Darkie's or my methods and identifying the target prims by reading their link names or descriptions. It's so much easier and less error-prone than hardcoding the actual link numbers, and you don't have to worry about having to redo everything if you decide later to alter the build.

When I've had that as a persistent problem the culprit has almost always turned out to be something with a corrupted texture, or at least one that the sim finds difficult to load. Prims with alpha textures (hairs, for example) are good to investigate first.

Thanks, everyone.. that's clarified things for me a lot. I think I'm on safe ground, though I will test more thoroughly. I'm not changing states while I do this stuff, and the chat messages start by telling the reciever script what they are, so the receiver knows which group of prims it needs to change. I've been playing with a prototype and it seems to hold up, though I think I'll take to a very laggy club and see what happens there.

I'm making a texture and colour changer to control several large (as in lots of prims) and complex pieces of body jewelry at once. The basic mechanism is that you select -- e.g.. -- a gem texture from a menu in the main piece (which probably the most complex one) and the script looks up the appropriate parameters for that gem, tells all the other attachments what they are and that they should apply them to all the gem prims, using llSetLinkPrimitiveParamsFast, and then applies them to the gem prims it contains. Same for the metals, fabrics and so on. This is all working well. However, I've been asked to include some presets, so you select a style and then it changes all the gems, all the metals and all the fabrics to an appropriate combination, and I'm a bit worried. What I'd like to do is look up the gem textures, tell the other pieces to change their gems, change the gems in the main piece, then when I've finished that, look up the metals, and do the same thing. Then when I've changed all the metals in the main piece, look up the fabrics and change those. However, I'm slightly concerned about what happens if one of the component pieces receives a chat message that it's got to turn into something it can use for fabric parameters while it's only half-way-through changing the metals. Does the message get queued for the script to deal with once it's finished what it's doing, or do I have to find some other way to do it (maybe tell the component scripts to wait till they've received all the sets of parameters and then process them)?

I do that slightly differently. I build, in state_entry, the attach event, the changed event and anywhere else that seems sensible, lists of prims I want to change, using something like this: list leather_prims;list metal_prims;string leather = "leather";string metal = "metal";find_prims(){ leather_prims=[]; metal_prims=[]; integer max= llGetNumberOfPrims()+1;//link numbers start at 1, not 0 while(max-->1){ string s = llToLower(llStringTrim((string)llGetLinkPrimitiveParams(max,[28]),STRING_TRIM)); //LSLEditor doesn't know PRIM_DESC if(s==leather){ leather_prims+=[max]; } else if (s==metal){ metal_prims+=[max]; } }} Then, when I want to change the metal prims, I say something like max=llGetListLength(metal_prims); while(max--){ llSetLinkColor(llList2Integer(metal_prims,max),colour,ALL_SIDES); } I find that's far faster, in a large linkset, than checking the link name or description of every single prim each time (I'm in the middle of making a colour and texture changer for a ginormous jewellery set, so it's a matter much on my mind at the moment).

You might want to try reposting your message either using a viewer other than IE 9 or, if you prefer, Enable Compatibility View in IE 9 and see if that helps.

Vivienne Daguerre wrote: I think most people will switch to Viewer 2 or a third party compatible viewer for mesh and larger prims. I cannot imagine anyone willing to settle for a lesser experience of Second Life. They would constantly be missing out. Mesh is going to take off when it hits the grid. That's not my point, though. I'm going to be among the early adaptors to a mesh compatible viewer, as soon as Marine brings out an RLV viewer that can see mesh. But what I'm saying is that, despite being able to see mesh, I'm very unlikely to wear anything made of it, or use it in any builds, much as I might want to, until I'm confident that most other people can see it properly too. I'm simply extrapolating from people's attitudes towards the old Emerald illegal attachment points. When Emerald and then all the other TPVs introduced them I thought, "how useful," but then I realised that only people using particular viewers would be able to see them properly and that, if they weren't, they'd see my attachments floating round near me rather than where they should be. So, despite the fact the extra attachment points would have looked OK to me, and to most of my friends, I didn't use them because I knew they'd look very odd to lots of other people. It's a bit like with RLV, which comes in various flavours. I make things that work with RLV, and I often feel frustrated that there's all sorts of stuff I know I can do with the newest version that I daren't use in anything I sell until Phoenix and Firestorm have released versions that support it too. But I know it's pointless to try to tell people they'll be able to make the product work perfectly well if they switch from Phoenix to Marine's RLV or to Dolphin or Cool VL, because they won't switch, so I have to wait until Phoenix and Firestorm catch up. In short, what I'm saying is that while I'm going to be able to see, early on, how amazing mesh clothes and builds look, I'm not going to be using them until I'm sure most other people think they look amazing too, and that they won't keep on asking me why I'm wearing pyramids and that I'm not going to have to deal with a load of complaints from people who bought something from me on the strength of the great-looking picture in the marketplace advert and then rezzed it and found they appear to have been sent a pyramid by mistake.

How is it getting Sheronda's uuid?