Innula Zenovka

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?

/me jumps up and down with excitement at the news!

I stopped simply randomizing the list each time because I grew tired of explaining to people that the fact "it sometimes says the same thing three or four times in a row" certainly doesn't necessarily mean "the script you gave me doesn't work properly".

I'm glad you've been promoted :smileyhappy: Though I agree, we need proper emoticons like the arsenal at our disposal over at SLU.

I can't see what''s wrong with it, either. For what it's worth, whenever I've made this sort of thing, I've done it rather differently -- read the whole notecard into a list at one go, randomise the list, and then work my way down it, chatting out the next line in order when the prim is touched. When I reach the end of the list, I randomise it again and start over. So I only actually read the notecard once (or if the contents are changed, of course). It's not really random, but since I'm making a toy rather than an experiment in probabilities I don't really worry -- it chats stuff in a different order each time and it doesn't keep repeating the same thing, which is all I'm really worried about.

Thanks.. I rather feared something like that would be the case. I don't have a problem with updating my viewer, but I do have rather a problem with the idea of going round looking to most people (or even a sizeable minority) like I'm wearing a pyramid, so I'm not too sure I'm going to be wearing much in the way of mesh clothes until not only have the Firestorm team got a mesh-capable viewer out but also that most Phoenix users have switched to it. Let's hope that's sooner rather than later.

The "de-ruthing rocket" is a device that blasts you high up into the air, well out of draw distance of wherever you are, and brings you back to earth again. The idea is this forces your textures to reload, causing other avatars (and textures generally) to reload for you. It's to de-ruth other people rather than you. You can achieve much the same effect by tp-ing out of the region and coming back a minute or two later or even, quite frequently, simply by changing your group tag. But please IM me in world and I'll see if I have on in my inventory; I probably do somewhere.

Also, many of them quote rates in major currencies other than US$, which is sometimes advantageous to people who otherwise get hit for two sets of transaction charges (buying USD from PayPal or their credit/debit card company and then, immediately, another set when they sell the US$ to LL for L$, rather than simply buying L$ direct for Euros or Stirling or whatever) and it certainly makes it easier to see what it's costing you.

A very good point. Thanks, Rolig. I should have mentioned that.