Innula Zenovka

My impression, for what it's worth, is that there's still a lot of serious vampire RP, including Bloodlines, but it's mostly confined -- understandably -- to vampire and lycan sims. So most of us don't get to see much of it. I'm not into vampire stuff, particularly, except I spend too much at Avid, but my business partner makes a lot of vampire and lycan anims, so I get to talk to the customers sometimes. Certainly they seem to spend most of their time in SL doing vampire and lycan stuff on their own sims, and not really interacting that much with the rest of us, at least not as vampires and lycans. And when I do go to the vampire sims, they seem pretty impressive places. I don't think the serious vampire role players have much time for vamps who hang around Ahern and Waterhead hassling new residents and generally making a nuisance of themselves, and I think such behaviour is now as atypical of vampires as is similarly irritating conduct at such places by non-vampires atypical of most non-vampire residents. Certainly the vampire clans generally seem to have taken on board the wholly justified criticism of "spampires" and "mosquitoes" a couple of years ago.

Storm Clarence wrote: I agree Innula. But I look back at some older threads on Vampires and it is the general consensus and the advise to newer residents to: "NOT ACCEPT BITE REQUESTS." Why is that? You would have to ask the people giving that advice, I guess, but perhaps the idea was to discourage spampires from making a nuisance of themselves by pestering people with unsolicited requests to bite them.

Or possibly someone at LL has reasoned that some of the many fans of series like True Blood and Twilight might be intrigued at the possibility of engaging in vampire RP in SL and will come and sign up and give it a shot, and has also reasoned that it will not cost LL anything to publicise this opportunity by means of Facebook?

Nope. Poseballs (and other things that animate avatars) send instructions back to your computer (and the computers of anyone who can see you) telling them to animate your avatar -- as far as the sim is concerned, the avatar is just standing or sitting there, motionless. If you want to animate prim linksets, it's a completely different method; you tell the sim to move the component parts of the object about, using functions like llSetLinkPrimitiveParametersFast. There's several tools available on the marketplace to help you do this, otherwise you could try some of the free ones in the wiki, like this one or this one.

It's a newish feature, and it's like following on Twitter -- they see what you post on your wall. You can't see it on your own profile, but this is what it looks like to me: you can control this by going to the privacy page on my.secondlife.com and adjusting the settings in the first drop-down box on the privacy tab:

I'm wondering how the exhibition came to be built and organised in the first place. I mean, someone at the Smithsonian must have been sufficiently familiar with SL to have had the idea in the first place, and between someone having the idea and the event taking place there must have been reasonably experienced people involved to set up the build and the event. That being the case, how come no one seems to have thought about security or estate managers?

Ah. The fact the box was checked and RLV was enabled would explain it, but I am certain that it didn't check itself. You must have done it and forgotten about it -- a collar couldn't turn it on for you. Be that as it may, then, yes, it is possible to tell if someone's got RLV activated. One way is simply to IM someone with the single word "@version" (no quotes) in a line on its own. If they're using RLV, then they won't get the IM but you'll get an autoreply giving details of what version they're using. If they aren't using it, of course, then they'll wonder why this strange person is IMing nonsense at them. If they're using a relay, there's another way to ask their relay if it's turned on, but I'm assuming you wouldn't be wearing an RLV relay without knowing about it. The little robot must have contained a script that, when you attached the object, issued a couple of commands to remove all your clothes and attachments; if RLV commands come from something that belongs to you (which something you're wearing does, by definition), then they're executed automatically. Or, indeed, the robot could just have checked if you were using RLV when you attached it and, on discovering you were, gone on to remove your stuff. That's how some of my toys work -- if you're not using RLV they don't bother trying to do anything else, so you don't get spammed with incomprehensible commands from them, but you know my stuff uses RLV when you buy it. It's a nasty trick to play on someone, though I have to say that there's other pretty nasty things people who are that way inclined can do to someone who is incautious enough to accept and wear an unsolicited gift from someone they don't know, RLV or not. I've been using RLV for three years and change, now, and I've never had any mishaps I didn't want to happen (except when I'm testing and debugging items, as my unfortunate testing alt could confirm).

It's off by default in Firestorm. The setting is Prefs → Firestorm → General → Allow scripted viewer controls. This should be unchecked, if you don't want RLV activated. If, for some reason, it is activated and you don't want it to be, uncheck it and relog. But it shouldn't be unless you've turned it on for some reason.

Are you using a viewer with RLV turned on? If you are, then I know how to remove all your clothes and attachments by script, but otherwise it's just not possible.

Sassy and I have just been chatting about this in world, and we think we know what happened. Sassy's busy and asked me to post our solution. We think that the little robot gave you a copy of itself in a folder, and you accidentally clicked "Replace Current Outfit" rather than "Add to Current Outfit". I can't think of any way other way to do what you describe unless you're using a viewer with RLV turned on.

Thanks. So, again, one's about a third of the other. So it looks as if they may now be measuring different things (or reporting the same measurement in different ways?).

This, I think, is the structure you want: integer handle;key owner;default{ state_entry() { owner = llGetOwner(); } touch_start(integer total_number) { if(llDetectedKey(0)==owner){ llListenRemove(handle); handle = llListen(0,"",owner,""); llSetTimerEvent(30.0); llOwnerSay("Please state the amount you'd wish to set the current game to!"); } } listen(integer channel, string name, key id, string message) { llListenRemove(handle); llSetTimerEvent(0.0); integer i = (integer)message; if((string)i == message){//quick test for a valid integer other than 0 llOwnerSay( "You've entered "+message+"!"); //do stuff to set the appropriate value } else{ llOwnerSay("Sorry, but \""+message+"\" is not a valid integer. Please try again"); } } timer() { llListenRemove(handle); llSetTimerEvent(0.0); llOwnerSay("Sorry, timed out"); }}

Thanks, Void. I guess I will need to keep an eye on this and see what happens. I'd be very grateful, in the meantime, if other people with access to Top Scripts could take a look and say if they see any big discrepancy between the figures there and the stats bar, particularly on the main server channel. There was certainly something very odd happening on the sim in question yesterday; time dilation (as reported by the stats bar and as was obvious from trying to do anything) started going all over the place and, when I checked, an apparently innocuous scripted tree that's sat there for a couple of years hardly taking up any script time seemed suddenly to have gone berserk for no apparent reason and was somehow showing a time of 60+. I disabled scripts in it, but that didn't do much good, so I restarted the sim, after which things stablised but I first noticed this big discrepancy, which was still there a couple of hours after the restart. All the other figures in the Top Scripts window looked pretty much as I would have expected (though the total figure was a lot lower than it has normally been) and the stats bar looked pretty much as usual, too -- it's just there was now a big discrepancy. I've never really paid much attention to Top Scripts until now, unless there's a problem or I'm looking for something I've lost, but now I'm wondering.

That's changed, though, Rolig. According to the wiki TOP SCRIPTS: Prior to server version 11.06.17.233176 (released 2011-06-28) the times reported represent only a brief instance in time and are inaccurate. Server 11.06.17.233176 changed it so that the times reported are now the average script time per frame for the last 30 minutes for all scripts on the object. If the object has been in the region for less than 30 minutes the number reported will be the average time per frame since the object entered the region. I'm not certain, and would appreciate confirmation or correction on this, but I think, from the wiki articles, the Stats Bar tells me how many scripts are running and Top Scripts tells me how many scripted objects there are (though I've never noticed so great a discrepancy before). But this doesn't explain -- at least not to me -- why what's supposedly "the average script time per frame for the last 30 minutes for all scripts" in the region is about a third of the figure in the stats bar.

In my experience, that particular message tends to indicate either a problem with the particular sim (or with teleports between sims) or with my internet connection rather than with the viewer.

I've just noticed that the figures for the number of scripts and the script time on my sim differ considerably between the stats window and the "top scripts" shown in the Region/Estate tools. The figures in the stats window are about three to four times those given by the Region/Estate tools. This is the case in both Catznip (which is based on 2.8) and the latest beta viewer. I don't remember there being such a wild discrepancy in the past. Are they now measuring different things, or is something bust?

The viewer you're using shouldn't make a difference here. What's happened is that this beachball expects to animate you and to accept control events (that is, respond to your pressing the arrow keys on your keyboard). If you're wearing it as an attachment, when the script asks for permission to do this, it's all done silently and automatically, so you don't notice. However, if it's not attached, the script has to send a pop-up asking you. That's the way LSL works. Whoever wrote the script doesn't seem to have included proper error-handling to accomodate a situation in which the ball is rezzed on the ground, as opposed to worn, and the owner doesn't grant it the permissions it wants, with the result it keeps on asking you every time -- I would think -- you appear on the sim. It must be somewhere on the sim. The sim owner or an estate manager should be able to find it, and return it to you, using the estate tools at their disposal. If this is a problem, then some third-party viewers like Firestorm have a search facility that should help located it, or you could try putting this script into a prim and touching it. If the item's in 96 meters of the prim (assuming the name is right), it should locate it for you: string s = "FreeBee SwimBall 0.9 (wear me)";default{ state_entry(){ } touch_end(integer num){ llSensor(s,"",ACTIVE|PASSIVE,96.0,PI); } sensor(integer total){ while(total--){ llOwnerSay(s+" detected at "+(string)llDetectedPos(total)); } } no_sensor(){ llOwnerSay("couldn't find anything"); }}

If you ask the owner of the sim (or someone with estate manager powers) to use the Region/Estate tools to search in "top scripts" for the object by name, he or she should be able to locate it easily and return it to you, from that window. ETA -- I don't think you can be wearing it; if you were, you shouldn't be seeing those messages.

To be fair, though, Dora, crashing at Old Lars is by no means an unusual experience -- it must be one of the most densely populated parcels in SL most of the time.

What does it say right at the top of the pop-up? In my silly example, it tells you it belongs to me: If you identify the owner of the object from that, you can AR them (do the AR with the spammy menu open, so it gets captured in the automatic screenshot) and then mute them, which should mute the object, too.

Deltango Vale wrote: Sigh. The UK will go dark again at 4 o'clock in the afternoon. It would take maybe 20 minutes for Parliament to fix the problem (by simply leaving the UK on BST year round), but politicians breed in the dark. Thus, the UK will remain home to vampires and werewolves for another year. /me is old enough to remember when that was tried as an experiment for a few years in the late '60s or early '70s. It proved hugely unpopular, the more so the futher north you got. Up in the north of Scotland, as I recall, it meant the sun didn't rise till about 10:30 in the morning.

I would share your brother's concerns. The advice in the Official FAQ on Phishing is to forward any suspicious emails to security@secondlife.com before deleting them.

I think you have the USA and Europe switched round. Certainly daylight saving in the UK (and, as far as I know, in the rest of the EU) ends on the last Sunday of October each year -- October 30th, this year -- and, at least according to this, it ends in the USA and Canada on November 6th. There's a complete list here http://www.timeanddate.com/time/dst/2011.html

As I understand it, all the third-party name-to-key systems work by collecting names and keys from sensors and the like in busy areas and sending them to the external database. So if you never happen to have been somewhere they're operating, they won't know your name. I really wish we had a native function in LSL retrieve people's uuids from their username. Scripts need to do it so frequently and, as Void says, your uuid isn't confidential information; you expose it to scripts every time you touch something or say something. There's a long-standing jira about it at https://jira.secondlife.com/browse/SCR-91

Vendors that allow you buy gifts for friends normally interrogate websites like that, because they need the avatar's uuid, rather than name, to send items to him or her.