Innula Zenovka

Lindal Kidd wrote: Anyone who believes that a company whose primary business is selling demographic information doesn't retain said information...I have some soon-to-be-beachfront land in Nevada for sale. So are you saying, in terms, that Aristotle lied to LL and LL repeated the lie in good faith or that you think they were in it together?

Kyle Steig wrote: Say it again. Clearly and unequivocally where it can be quoted later in the event of a legal action. Demonstrate in that statement that it might actually be true because it is so unmistakably quotable in the event of a legal action. Something on the lines of "Some of you have raised the question whether the age verification vendor we have selected, Aristotle and their Integrity service, is complying with various global privacy laws, which generally pertain to collection, use and storage of personal data. We’ve been assured by them that they are in compliance with all relevant privacy laws. But the most important point here — which we think makes a big difference in evaluating safety and compliance — is that no data is being taken, retained or stored. Rather, an automated check is done at the point of contact, and all data is then purged. Thus, there is no collecting, using, storing, or transferring of your personal information beyond the one-time match. Period. Certainly, you are not being asked to place your information in a database." http://community.secondlife.com/t5/Features/More-on-Age-Verification/ba-p/603022

Kyle Steig wrote: Here's what I'd demand: - Get confirmation for us that our records have been purged from Aristotle. But LL and Aristotle always said that our data wasn't retained in the first place. What sort of confirmation would you accept that Aristotle have purged data they say they haven't got because they never recorded it?

I would recommend Builders Brewery, too. I've attended several of their classes, and been very impressed.

The one time a sim I owned was subject to repetitive grieifing -- someone had been banned from a club there, and retaliated by crashing the sim several times a day -- LL were very quick to send Spike Linden (who was one of the best Concierege Lindens, to my mind) over when I complained to Concierge Support about repeated crashes (I didn't even realise it was a griefer at the time). Spike spent about an hour there with me and the club owner, investigating the matter, and then announced he knew who the culprit seemed to be and how he was was doing it, and that we shouldn't have any more problems. We didn't.

The most common way is for the recipient of your messages to share them with someone else. They might, of course, deny that's what they've done, but, on the principle that the simplest explanation of the available data is, in general, to be preferred, that's the explanation that would first occur to me unless I had compelling reasons not to think it were the case. Otherwise, I'd suspect that someone -- a relative or roommate, perhaps -- had gained access to your or the other person's computer and looked at the chatlogs. Or, at a pinch, I'd suspect a keylogger of some sort, since I know they exist and how they work, while I've never heard of a way to hack IMs, at least not if both parties are using any legitimate viewer.

Gooden Uggla wrote: So... everything related to age verification, all the economy-destroying bullsh*t surrounding the forced ghetto at Zindra was a great big waste of time. Congrats LL, a new low, even for you... I don't know if it was all a great big waste of time. I always had the impression -- and the more I heard from Blondin at Adult Content office hours, the stronger this impression became -- that LL were primarily interested in what the Mainland, search and (to a lesser extent) the Marketplace looked like and that "will no one think of the children???" was all a bit of a red herring. IOW, I don't think, "we've got to keep the naughty stuff out of children's impressionable eyes or we'll get sued/you'll get sued/Congressman Snooks will get upset and have a law passed" was ever the real worry. It's just someone thought that might sound a bit better than "all this in-your-face sex stuff everywhere you turn looks rather tacky and is a bit of embarassment when we're showing the place off".

Ceka Cianci wrote: i beleive you go into your dashboard and then there is something to click to agree..i saw one in mine even though i already did age verification lol here is what it said in my dashboard under he age verification tab..it had my birthday above it and a check box next to this line.. By checking this box, you're confirming that the date of birth entered above is true and accurate. Adult content in Second Life is just that — for adults only. We'll spell it out for you: if you are under 18, do not check this box! If you are — check it, and off you go! But I'm not under 18; I'm an adult and over 18 -- what do they want me to do?

If I had to guess, I'd guess it's objecting to "cyber". But, as Rolig says, you're going to need to go through it word by word.

LL's changed the Age Verification procedure, to match that used by most other places on the internet -- that is, you provide them an appropriate date of birth, and they trust you to be telling the truth. I didn't believe it when I was told about it, so I created an alt to test it, giving my correct DOB. I then went to her dashboard, chose the Age Verification option, and that asked me to confirm the DOB I'd provided was correct. This I did, and that took me to a screen confiming that I could now access Adult areas of SL if I chose to adjust my preferences when I logged in next. So my alt logged in, adjusted her preferences, and was able to TP off to Zindra without needing to trouble Aristotle or anyone else, or to put payment info on file. I was not surprised to see that the landing state at the main Zindra sim is still set to phantom, by the way, so you end up in the river. It's only about 18 months since Blondin promised to get it fixed.

I think you need two scripts. llSetPayPrice has to be called from the root prim, and affects all the prims in the linkset, but it only actually does anything if the prim you touch -- not necessarily the root prim -- contains an active script with a money event. I've just tested this by linking together three prims. In the root I put this script: default{ state_entry() { llSetPayPrice(PAY_DEFAULT,[50,100,200,500]); } touch_start(integer total_number) { integer n = llDetectedLinkNumber(0); key av = llDetectedKey(0); if(n==1){ llRegionSayTo(av,0,"should be giving a gift"); } else if (n==2){ llRegionSayTo(av,0,"should be inviting you to join a group"); } }} Linknumber 2 has nothing in it. And linknumber 3 (the first of the three prims I touched when linking them up) has this in it default{ state_entry() { llSetClickAction(CLICK_ACTION_PAY); } money(key id, integer amount){ llRegionSayTo(id,0,"thank you for the tip"); }} Touching each one produces the desired effect for that particular prim.

You don't say what viewer you're using. Certainly I found that the new inventory fetching method introduced in V2.5 (so also used in most, if not all, TPVs based on V2) makes a huge difference to how fast and how reliably my inventory loads.

Thank you, Void.. at last I understand. Bookmarking this for future reference.

Thanks, everyone. I finally, before I'd read all the replies, got it working with if((change) && (held == up_left)){ llOwnerSay("up left"); }

I'm a bit confused with control events. What I've got, having studied the article in the LSL wiki, is integer up_left = CONTROL_ROT_LEFT|CONTROL_FWD; if((held & change) && (change & up_left)){ llOwnerSay("up left"); } I was expecting it to say "up left" only if I've pressed both the left and up arrow keys, but instead it's firing if I press either. What I want it do to is say "left" or "up", as appropriate, if I press one, and then "up left" if I press both. Where am I going wrong, please?

I don't know if it will fix your problem, but when my clothing layers fail to show, I've found that taking off a few tattoo layers usually fixes it for me. At which point I can put the tattoos back on and everything appears normal again.

Brad Oanomochi wrote: Edit: I actually read elsewhere on this site "By default, each Resident account has access to General and Moderate content," and it was written by LINDENS. It's the answer to the first question in the FAQs section: http://community.secondlife.com/t5/English-Knowledge-Base/Maturity-ratings-and-search/ta-p/828865 According to the Lindens, the only thing I shouldn't have access to is ADULT content. This article was edited just a few days ago and it was made by HIGHLY, HIGHLY reliable Lindens! Yeah, by default, people are assumed to be 18 or over, because that's what the vast majority of SL residents are.

Fraid you're out of luck. What it says is, https://wiki.secondlife.com/wiki/Linden_Lab_Official:Teens_in_Second_Life Second Life is generally for adults 18 years and older; however, if you are 13 years of age or older you can use Second Life with some restrictions. If you're:16-17 years old you can access regions and search results that have a General maturity rating. I don't know how your friends manage to access mature areas, but they shouldn't be able to. Do you know for a fact that they can -- that is, you've stood on the border between a mature and a general area and seen them on the other side, but you can't get in -- or have they just told you they can?

If you don't want to get billed for your premium account anymore you'll have to downgrade the account to basic and cancel the subscription (don't just cancel the subscription and expect it to downgrade automatically -- it won't, and you'll end up getting locked out of your account for non-payment). In order to own Linden land or to qualify for your tier-free 512 plot you need a premium account, owning land and having a premium account aren't one and the same.

I think I see. I don't actually want to move the component elements at all relative to the old root, just swivel everything through 180 degrees. So, does this mean I use the new local position relative to the new root prim (which I've already read and recorded), subtract their positions relative to the root prim of the TV set when it was a freestanding unit at ZERO_ROTATION (so nothing to subject in the case of the old root prim, now a child prim in the new build), multiply that by 180 degrees, and then add back in the numbers I've just subtracted? That is, the one piece of the puzzle I'm missing at the moment is the positions of the TV set prims relative to the root prim of the TV set when it was just a TV set rather than something linked to larger build?

Void Singer wrote: ((local_pos_child - local_pos_old_root) * rotation) + local_pos_old_root Thanks. What, though, does "rotation" represent there? At the moment I know the old and new values for PRIM_ROT_LOCAL and I can read various values at run-time. Which do I need? Or should I have recorded/calculated something else? Sorry to be so obtuse but I'm a bit unclear what I'm doing, maybe because the position values I've recorded are (PRIM_POSITION - llGetRootPosition())/llGetRootRotation(), and I'm now not quite sure if that's what I should have done.

Thanks, both. I'm rotating round an arbitrary point -- what was the root of the TV set before I linked it to the rest of the build -- and that's where I'm going wrong, I see, and why my original formular worked for my stuff but not for this. Let me try to understand what I need to do, though, in setting the new position. I think I've got the two offsets read correctly -- that is, I know the prim's offset from the root in the old position and in the position it's going to. So I subtract the old offset from the new one (I think) -- and then what what do I do? I've got the old PRIM_ROT_LOCAL and the new one. I can read PRIM_ROTATION and llGetRootRotation and so on, of course, but I'm really not sure where I go to from here. The actual build is, as I said, a TV set that started off as a free-standing unit. It's now part of a larger build, and the idea is that it should swivel round through 180 degrees on what used to be its vertical axis so you can watch TV from the bed or a couch on the other side of the room.

Thanks, Void. And I guess no one at the Lab thought to keep an back-up and check on how successful the conversion had been before finally committing the changes. I really wish they'd check with involved users before doing some stuff. As we all know, those archives are an invaluable reference source and learning tool, and it really upsets me when they get trashed through carelessness, whether or not the damage is fixable. For several forums, it's no big deal if the archives are there or not, I guess, but for us it obviously is, and I'm not sure LL are always aware of this. I'm planning to start attending the Community Tools User Group anyway, since I'm a bit concerned that LL have twice recently made serious factual mistakes about age verification in KB articles and videos, and this is another reason to attend, I guess.

I'm still reeling from the discovery that all the examples of how to do this seem to have been mangled while being archived. Anyway, I'm at my wits' end. I've looked out some scripts I have used in the past to read and set link primitive params using PRIM_ROT_LOCAL, and, while they certainly worked with the stuff I made, I can't get them to work now with something I'm making -- possibly because there's something I didn't need to correct for in the previous builds but I do now, like an oddly aligned root prim or some such. What I'm using to read the parameters into lists is: integer max; integer i; default { state_entry() { // llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { max = llGetNumberOfPrims(); llOwnerSay((string)max); i=2; vector r = llGetRootPosition(); do{ list l = llGetLinkPrimitiveParams(i,[PRIM_POSITION,PRIM_ROT_LOCAL]); vector v = (llList2Vector(l,0)-r)/llGetRootRotation(); rotation rot = llList2Rot(l,1); llOwnerSay((string)i+","+(string)v+","+(string)rot+","); } while(++i<=max); } }That, I think, is giving me the offset from the root prim, corrected for the root rotation. Then I'm trying to set the positions with variations on the theme of touch_start(integer total_number) { toggle=!toggle; if(toggle){ my_list=a; } else { my_list=b; } integer max=llGetListLength(my_list); while(max--){ if(max%3==0){ integer i = llList2Integer(my_list,max); // vector vPosLcl = (llList2Vector( llGetLinkPrimitiveParams( i, [PRIM_POSITION] ), 0 ) - llGetPos()) / llGetRot(); rotation vRotLcl = llList2Rot( llGetLinkPrimitiveParams( i, [PRIM_ROT_LOCAL] ), 0 ); //-- Sets on PRIM_POS are local to the next highest frame of reference //-- that means child relative to root, and root relative to region. llSetLinkPrimitiveParamsFast( i, [PRIM_POSITION, llList2Vector(my_list,1),PRIM_ROT_LOCAL,llList2Rot(my_list,2)] ); //-- local pos + (local offset * local rot) == local relative change in position } } } and it's going all over the place. It's a flat-screen TV, swivelling round on a table, so it doesn't get much change to move out of position (though I think it is) but the rotations of the component prims are clearly off. I've tried multiplying and dividing by every permutation of llGetRootRotation() and vRotLcl I can think of, but either I've read it wrong in the first place or there's something I'm missing when I'm setting stuff. Can anyone please show where I'm going wrong?

Has anyone else noticed this? I was looking for some examples in last year's archives and, as far as I can make out, all formatted examples containing lists have lost the lists. So something that originally read, llSetLinkPrimitiveParamsFast(n,[PRIM_POSITION, ......]); now just reads llSetLinkPrimitiveParamsFast(n, ); This is a real pain in the neck -- there were loads of good examples in discussions of how to get and set link primitive params when the new functions came out. Does anyone here have any influence with the powers that be to get them to send out search parties for our missing lists? ETA https://jira.secondlife.com/browse/WEB-3924