Innula Zenovka

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.

Great clothes, Vivienne. Thank you for showing them us. Could I, though, ask a question about mesh clothes that's been bothering me? If and when mesh is released on the main grid, and I download the latest viewer and go and buy some great-looking mesh clothes and wear them, what am I going to look like for people still using Snowglobe-based viewers like Phoenix and Imprudence (or, indeed, earlier versions of the official viewer)?

Have you somehow unchecked "strech textures" (top section of the edit tool, right hand side)?

The first thing to do is to check that they're not hiding in your Lost and Found in the form of a "coalesced object". If you removed them by returning them all to yourself, they won't have been returned as 300 separate items, but as one collection of objects, identified in your inventory by an icon that looks like a stack of boxes rather than one single one. And, which is where the confusion really start, this "coalesced object" will be identified by the name of one of the individual objects contained in it. So if you return to yourself three objects all at once, "chair", "table" and "TV set", you'll find in your Lost and Found a coalesced object called "chair" or "table" or "TV set" and no apparent sign of the other two. See How to Retrieve Coalesced Items for more details. The really bad news is that you can only rez them all at once and that they'll rez in the same spatial relationships to each other as they were when you returned them -- so if, for example, they were spread out all over an area 64x64 meters when you returned them, you'll need at least as much space to re-rez them and take them back one at a time (when they should end up in the appropriate folders). You will probably need to find a nice quiet sandbox when you've got a bit of time to undertake this task.

Seems I'm in a minority, but I can't see any particular reason not to use one of the exchanges listed in the wiki as using LL's Exchange Risk API.

I know what's happened. It's not an error and it's nothing to worry about. You must have clicked the "edit" button instead of the "save" button. The "edit" button is there if you want to edit the script in an external editing programme (like LSLEditor or Eclipse) and the viewer was telling you that you haven't told it which external editor to use. But if you're just doing stuff like editing TP scripts, you really don't need to bother about an external editor.

There's a known issue with the servers, which seems to have become much worse over the last couple of weeks, as described at SVC-6403 in the jira. So the merchant is probably all too aware that transactions are failing more frequently than expected, and should be reasonably sympathetic to your complaint. Fortunately, from the latest comments, it seems a fix is being tested at the moment on the "Second Life RC BlueSteel" channel, so with luck the problem should be resolved in the next few days.

The RLV is simple. First set up a folder at the top level of your inventory -- that is, not inside any other folders -- called, simply, #RLV (in capital letters). Inside that, put a folder called anything you like. Let's call it "ShortNeckShape". Inside that folder, put the shape, plus anything else that goes with it (skin, maybe?); The RLV, assuming you are triggering it from an attachment or something you own, is simply, llOwnerSay("@attach:ShortNeckShape=force"); And that's all there is to it. It will force you to wear it, replacing your existing shape. If there are any attachments, they need to be named so the viewer understands where to put them; Marine Kelley has a couple of lengthy but very helpful tutorials on the subject in her blog. The full RLV API is to be found in the wiki at LSL Protocol/RestrainedLoveAPI.

I want to loop though a list of a couple of dozen prims in a large linkset, changing their alpha value on all sides (and nothing else). Is there any advantage to using llSetLinkPrimitiveParamsFast rather than llSetLinkAlpha in such circumstances? They're all the same colour, and I know what it is, so I don't have to worry about knowing what colour vector to use if I do use llSetLinkPPFast. NevertheIess, I can't think of any particular reason to prefer llSetLinkPPFast, but I thought it wisest to check.

I see, I think. So, assuming "hug" and "hugged by" are different, do I need 8 animations for each partner (male hugs female, male hugs male, male hugged by male, male hugged by female, female hugs male, female hugs female, female hugged by male, female hugged by female), and let the script figure out which pair to use?

You need a simple binary switch, like this: integer toggle;string sound;default{ state_entry() { sound = llGetInventoryName(INVENTORY_SOUND,0); } touch_start(integer total_number) { toggle=!toggle; if(toggle){ llLoopSound(sound,1.0); } else{ llStopSound(); } }}

Ishtara Rothschild wrote: As far as animations go, I'd find this feature very useful too. It doesn't matter as what gender people identify. Fact is, the female avatar mesh behaves different from the male-based one. For example, the arms will be closer together if the same animation is applied to male- and female-based avis. Good animated furniture should be able to compensate for that, and it doesn't matter if my female-based avatar is supposed to represent a woman, transsexual, herm, androgyne or whatever. In any of these cases, I'd want my arms to be somewhere outside the body of my partner when playing a couple animation. But since most couple anims are optimized for one male-based body, I always end up sticking my hands in someone else's shoulders. I don't know enough about animations to be sure if I'm understanding you. Aren't you going to have to correct the offsets for the users' own bodyshapes anyway, by moving the poseballs about or using llSetLinkPrimitiveParams, regardless of what their AvatarSex is in debug settings?

Let's take a practical example -- and, while it's drawn from collars, which some people associate with adult content, it's quite a general one. Many collars have built-in AOs, which are usually configurable by the user but also come with some default male and female walks, stands and so on. They sometimes come with emotes or cute confirmation messages that need the wearer's gender (my collar says something like, "Innula adjusts her collar" when I open the menu (though it's a sensible one, so it does it with llOwnerSay and doesn't spam people). On the face of it, it would be cool if the collar could automatically adjust itself to your gender, so it knows whether to use the built in male or female walks and so on. But, since you'd have to allow for the fact it's going to get your gender wrong a lot of the time -- many people who make their own shapes start out with the default settings for the opposite sex, not for any gender-bending purposes but because it's often easier to make the shape you want that way (particularly if you are a smaller guy, I understand) -- you'd have to let people over-ride the script's decision about your gender. So my attitude is, in that case, why bother to try to read something in the first place? It's as simple, and far more accurate, to tell the user, "by default, this item assumes a Male (or Female) user. If you want to change this, please do it via the menu". I suspect the maker's guess in setting the default is usually going to be almost as good as would be detecting it by script. As to the greeter, yeah.. I see the point, but I wouldn't use a greeter -- if I used them at all -- that I knew was certainly going to get people's gender wrong in some cases, because I don't want to embarrass them or make myself look stupid (plenty of people will confirm I'm perfectly capable of making a fool of myself without scripted assistance). If it could be guaranteed that llDetectGender would be completely accurate, then yes, I agree it would be useful. But since it can't be, I think it's more trouble than it's worth. As I said, I could detect the gender of many of my customers with RLV, and have been able to for some time, but I've never, in practice, found a situation in which it seems the most sensible way of determining their gender when I need to know it.

If you are trying to verify your age, the service LL uses can be a bit unreliable at times. You can verify your age manually, as described here: http://community.secondlife.com/t5/English-Knowledge-Base/Age-verification/ta-p/700021 Alternatively, if you don't want to wait 5 days or so, you can access adult content simply by putting some payment info on file -- that is, use a credit card or PayPal or similar either to buy some L$ or to buy something on the Marketplace.

Has she tried contacting the merchant and asking him or her to attempt redelivery? I find that a brief notecard or IM explaining the problem and giving details of the transaction -- which she can find in account--transaction history on her dashboard -- usually gets things fixed. There's a known issue with llGiveInventory() at the moment -- that's the function the "magic boxes" use to deliver stuff -- that's driving merchants nuts, and even manual transfers have been difficult today. It took a friend of mine on a different sim three attempts to give me an object earlier today.

Sounds like you will have to go through the manual verification process, as described here by Jeremy Linden -- sending them a scanned copy of appropriate ID. Alternatively, if you just want to access Adult content, you can do that by getting payment info on file -- either go premium or just buy some L$ or something in the marketplace using a credit or debit card, or PayPal if that's available to you (which it isn't, at present, for non-US residents)

What's not true? It's certainly true that I've never, in practice, found a use for @getdebug_AvatarSex in any of my stuff, and that's despite the fact I can be pretty sure most of my customers use RLV. When I first read about the function I was really pleased. Then I started trying to think how I'd actually use it, and very rapidly realised it would be way more trouble than it was worth, since I'd have to let people override it manually anyway to allow for the many times it would give me inappropriate results. People are well used to having to select which gender anims they want to use from a hud or menu, as you say, or sit on an appropriate poseball, and it just seemed to mean a lot of extra work and complexity to make something I knew wasn't actually going to solve more problems than it created. The solution Vesta and I use in our furniture at the moment is simply to either to produce separate Masters' and Mistress' editions of stuff when it matters, or provide different menus. It's pointless trying to second-guess what gender or genders the Master or Mistress's submissives will be in any given case, so we let the person controlling the menu handle that. It's also true that I've never actually come across any RLV toys made by anyone else that use it. That's not say there aren't some, and I'd love to take a look at any you suggest, 'cos I'm always looking for new ideas. but, as it is, I just haven't come across any.