Innula Zenovka

I've not looked at the contents of the OC Updater (though I think it's full perms) but I would imagine they use something like this, posted by Dari Caldwell in the old, old forum.

Are you using a viewer with RLV enabled? If you are, and you have something locked, then that would explain it. And, if you can tell us what viewer you are using, I can probably tell you the settings to use to get your wear option back.

Jenni Darkwatch wrote: All good points, and IMO all true. Scripts in SL are, mostly, atrocities as it is. The main reason for that, I suspect, is that all too often someone will get hold of a perfectly good script -- perhaps from the script library -- that does its job as it should. He edits it a bit, and then some time later someone asks in a builders' group, "anyone got a script to do such-and-such?" The first person passes his over, and then, soon after, an edited version of his edited version gets passed to another builder who "doesn't know much about scripting but I can edit them a bit" who, more by luck than good judgment gets it to work for his purposes, possibly by dropping bits of another script in... and so it goes on. A while ago, someone gave me a gun script to have a look at that they'd got from a friend but couldn't get to work. The thing was a bloated nonsense with whole sections, clearly by a variety of different people, that either did nothing at all or cancelled out what something else did. I told him it was gibberish and that I was amazed it had ever worked, to which he replied, "but it's by a Linden -- look at the creator field". So I looked more closely, and realised it had started out as the pop-gun script in everyone's library before half a dozen different people had hacked it about. I gave him a copy of the original and explained to him how to use it, checked what he did with it and he ended up with a decent script. Then there's the related reason, I guess, that someone decides to write a script for sale that has to be endlessly configurable, often by notecards, to adapt to the particular circumstances in which it's to be used, and you end up with something that's very good at covering all the bases but massive overkill for the particular base that needs covering on any particular occasion. I can't be the only person who started out thinking that the Timeless Door Script was wonderful, though possibly more complex than necessary for what I wanted to do (and certainly too complex for making a wardrobe), and then, on deciding to learn a bit about scripting for myself, came across Void's really simple door and got a bit of a shock. But I don't really see there's solution to the problem, other than helping people write better scripts for themselves.

Depends what country you're in, jules. Residents of Northern Ireland (and, for all I know, of other parts of the UK) in your position have reported success using their National Insurance number, for example, (but I don't know if that still works). But that's not much help if you're not in NI, any more than would be an equivalent fix that works for the French (if there is one) would be much use for a German resident and vice versa.

Unfortunately, Brett Linden seems to have made the same mistake in his video about Account Verification (maybe he read the uncorrected article?). See How To Adult-Verify Your Account about 30 seconds in.

Thanks, both. That confirms what I thought. It just looked so odd, I wondered if it was a clever trick I'd never seen before.

Someone asked me to help them tweak a script they'd bought, which I did, and while I was so doing, I noticed something I've never seen before. The script was switching between listening to the owner on integer chat_channel and integer dialog_channel, depending on whether there was a menu open or not. Now, when I do this, I have a global called integer handle, and then say llListenRemove(handle); handle = llListen(dialog_channel,"",owner,""); // or handle = llListen(chat_channel,"",owner,""); as appropriate, which is how I learned to do it from the old lsl wiki. The way this script did it, though, was on the lines of llListen(-999,"",owner,"");//open the dialog listener //and then llListenRemove(-999);//to close itI don't think anything gets closed that way, and I've certainly never seen it done like that. I thought the integer you remove in llListenRemove(integer number) was the callback number and nothing to do with the channel. However, the original script was clearly written by someone who was reasonably competent, so I'm wondering if it's a shortcut I didn't know about.

I got the same message, too. I'm wondering about replying, explaining that my late uncle was the oil minister of a West African republic until his untimely death recently and, as a result, I'm faced with the task of smuggling out of the country the several kazillion dollars he embezzled while in office, and wondering if my new friend would care to assist me, in return for an absurdly generous share of the loot...

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.