Looking over the recently announced TPV policy changes I just got to wondering: will this have a (minor) impact on RLV/RLVa? The one that I have in mind is this:
2.j : You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.
Consider version checking in the RLV API, both via the @version IM call and via the @version= request. In both cases, not only is the version of the RLV API returned, generally information about which viewer, and which version of that viewer, is being used, is returned.
For example, an IM sent to me, that is nothing more than "@version", will return (at this moment, while I'm in on Firestorm):
RestrainedLove viewer v2.7.0 (Firestorm 3.3.0.24880 - RLVa 1.4.3)
Likewise, if a request is made via my relay (as is done with my relay scanner and relay checker), you get the same reply:
RestrainedLove viewer v2.7.0 (Firestorm 3.3.0.24880 - RLVa 1.4.3)
In both cases this reveals not only the viewer being used, but also the version of the viewer being used. This would seem to fall foul of the policy that says that a TPV "must not include any information regarding ... software ... in any messages sent to other viewers".
Of course, it could be argued that turning on the RLV API is the exception that means the user has "explicitly elected" to allow this information to be transmitted, but I'm not sure it's a terribly compelling argument.
Edit to add: According to this post by Tonya Souther Linden Lab have said that the act of turning on RLV is seen as the user having "explicitly elected" to allow the information to be transmitted. This actually bothers me a bit in that no user, turning on RLV, will know that that information will be transmitted (it's been my experience that a large number of people who turn on RLV don't have a clue about most of what it does). There's no doubt that RLV stays within the spirit of the policy, but I don't think it's within the letter of it. This is concerning because it shows how badly-worded these new policy changes are. I think this alone highlights how, be it an intended consequence or not, there's enough wiggle-room here for the Lab to turn around and tell you you've read it wrong.
(For now I'm not even going to begin to consider the idea that RLV in general could possibly fall foul 2.k -- it seems unlikely and would seem to need a paranoid reading of that section but... it's not an impossible interpretation. Edit to add: in the Tonya Souther post it's also stated that RLV wouldn't be banned under this policy so it seems there's no need for a very paranoid reading of this change -- that's a bit of a relief)
2012-02-24
Ban for group membership?
Before I go any further with this post I just want to make something clear: I absolutely agree with the idea that the owner of a private estate, or even a plot anywhere, has the first and last say on who gains entry. I own a business in SL, I own land in SL, I fully expect to be able to say who can and can't have access and I fully support anyone else's right to do so -- even if I think their decisions are totally wrong.
Earlier today I saw something that worries me a little, it's something I'd never seen before in SL. That's not to say that it doesn't happen -- I have little doubt it does -- but it's the first time I've seen it displayed in a location I go to.
I was at a sim that has a sign up displaying disapproval of a BDSM-related practice and saying that it's unwelcome on the sim. Now, of course, that's fine. Here at Raven Park we've got a few rules too; it's rare to have a hangout or playground that doesn't have some rules. Moreover, personally, the practice in question isn't one I have much like for either and I have some sympathy with disallowing it on a sim (I won't go into details but it's worth pointing out that it's nothing terrible, it's just a style of domination).
What it is doesn't matter too much. What bothered and concerned me is that the sign said that people would be banned even if they were a member of a group, or had a profile pick, that related to the practice. I'm not quite sure what to make of that. Personally, for me, that oversteps a mark that shouldn't be overstepped. It's one thing to say "please don't do X on this sim", that makes sense, it's another to say "if we even think you might have an interest in X, we'll ban you". It might be that it's more by accident than design but... it comes over more than a little Orwellian.
I suppose this does, in some way, raise a number of questions about how we see ourselves in Second Life and how we portray ourselves. Few would have a problem with a "no nudity" rule, or a "no childlike avatars" rule, etc... Those things are easy to police and, even if you disagree with the rule itself, you can generally appreciate that the sim owner doesn't want these things on their sim. The same goes with how you conduct yourself generally (how you conduct yourself in public chat, or how you IM people while there, etc...). But it's hard not to think of a profile as something else, something different. A profile is something others have to go out of their way to read, something others have to decide to read. I'm more than happy to change my clothing to conform with a sim's rules. I'm not sure I like the idea that I should hide groups and profile picks for the same reason.
Potentially banning someone because you've read of an association of theirs, in their profile... I'm struggling with that idea. I'm struggling with it a lot.
Earlier today I saw something that worries me a little, it's something I'd never seen before in SL. That's not to say that it doesn't happen -- I have little doubt it does -- but it's the first time I've seen it displayed in a location I go to.
What it is doesn't matter too much. What bothered and concerned me is that the sign said that people would be banned even if they were a member of a group, or had a profile pick, that related to the practice. I'm not quite sure what to make of that. Personally, for me, that oversteps a mark that shouldn't be overstepped. It's one thing to say "please don't do X on this sim", that makes sense, it's another to say "if we even think you might have an interest in X, we'll ban you". It might be that it's more by accident than design but... it comes over more than a little Orwellian.
I suppose this does, in some way, raise a number of questions about how we see ourselves in Second Life and how we portray ourselves. Few would have a problem with a "no nudity" rule, or a "no childlike avatars" rule, etc... Those things are easy to police and, even if you disagree with the rule itself, you can generally appreciate that the sim owner doesn't want these things on their sim. The same goes with how you conduct yourself generally (how you conduct yourself in public chat, or how you IM people while there, etc...). But it's hard not to think of a profile as something else, something different. A profile is something others have to go out of their way to read, something others have to decide to read. I'm more than happy to change my clothing to conform with a sim's rules. I'm not sure I like the idea that I should hide groups and profile picks for the same reason.
Potentially banning someone because you've read of an association of theirs, in their profile... I'm struggling with that idea. I'm struggling with it a lot.
Impressive radar (or not)
As some of you might know, this weekend is the second birthday of Z&A Productions and, to celebrate, we're holding a mini-hunt around the sim all weekend.
So, there I am, sat in the workshop, minding my own business, and I happened to have a copy of all the hunt objects rezzed out on the floor in front of me. Keep in mind that the workshop is a couple of thousand or so meters up in the air -- nowhere near ground level.
And, out of the blue, an avatar (who was already on the sim, down at ground level) rezzes in front of me, right on top of the collection of hunt objects. The only reasonable explanation I can think of is that they were using a radar of some description (either built into the viewer, or something scripted, I guess) and had happened to find the objects in front of me.
Of course, they didn't stay long -- the workshop has a security system that TPs unauthorised avatars back to their home location -- but what a way to get found out "cheating" (not that I'm totally opposed to the use of radars on hunts, just as long as they're used as a last resort). And how impressive (or unimpressive, depending on how you look at it) is that radar that it found the objects a couple of kilometres away but didn't find the ones down on the ground?
So, there I am, sat in the workshop, minding my own business, and I happened to have a copy of all the hunt objects rezzed out on the floor in front of me. Keep in mind that the workshop is a couple of thousand or so meters up in the air -- nowhere near ground level.
And, out of the blue, an avatar (who was already on the sim, down at ground level) rezzes in front of me, right on top of the collection of hunt objects. The only reasonable explanation I can think of is that they were using a radar of some description (either built into the viewer, or something scripted, I guess) and had happened to find the objects in front of me.
Of course, they didn't stay long -- the workshop has a security system that TPs unauthorised avatars back to their home location -- but what a way to get found out "cheating" (not that I'm totally opposed to the use of radars on hunts, just as long as they're used as a last resort). And how impressive (or unimpressive, depending on how you look at it) is that radar that it found the objects a couple of kilometres away but didn't find the ones down on the ground?
2012-02-12
A change of skin
Following on from yesterday's post about my current experiences with Firestorm 3.3.0, this evening I switched skins to check if the problems I was having that I took to be skin-related were down to the skin choice.
Using the "Firestorm/Grey" skin (instead of vintage, which is what I was using) does seem to remove the problem with the overlapping controls in the object content permissions dialog:
At least, sort of. As you can see above, there is still a bit of an overlap and, looking at the version of this dialog from the vintage skin:
you can see that the text that tells you how the permission change went seems to overlap about as much as the text area in the vintage skin. So it might be that the problem is in the design of the dialog and it's just more obvious in the vintage skin.
One thing I have noticed with Firestorm and this dialog, that I don't like, is that it doesn't give you any sort of progress when the permissions are being bulk changed. Whereas in Phoenix you get a list telling you which items have been processed, in Firestorm it seems it just puts the output in a single line, each progress overwriting the last. That's not terribly helpful.
Perhaps it's supposed to and what we're seeing here is a problem with the control that should contain that output? I'll test this a little more and consider doing a JIRA for this.
The other problem that I tested was the script window seasickness problem. With the "Firestorm/Grey" skin I'm seeing no evidence of that at all. It seems that it really is down to the vintage skin.
So, right now, if I'm going to be using Firestorm most of the time (and, the way it's going right now, I think I will be), it looks like the "Firestorm/Grey" skin is probably the best choice for me. At least for now.
Using the "Firestorm/Grey" skin (instead of vintage, which is what I was using) does seem to remove the problem with the overlapping controls in the object content permissions dialog:
At least, sort of. As you can see above, there is still a bit of an overlap and, looking at the version of this dialog from the vintage skin:
you can see that the text that tells you how the permission change went seems to overlap about as much as the text area in the vintage skin. So it might be that the problem is in the design of the dialog and it's just more obvious in the vintage skin.
One thing I have noticed with Firestorm and this dialog, that I don't like, is that it doesn't give you any sort of progress when the permissions are being bulk changed. Whereas in Phoenix you get a list telling you which items have been processed, in Firestorm it seems it just puts the output in a single line, each progress overwriting the last. That's not terribly helpful.
Perhaps it's supposed to and what we're seeing here is a problem with the control that should contain that output? I'll test this a little more and consider doing a JIRA for this.
The other problem that I tested was the script window seasickness problem. With the "Firestorm/Grey" skin I'm seeing no evidence of that at all. It seems that it really is down to the vintage skin.
So, right now, if I'm going to be using Firestorm most of the time (and, the way it's going right now, I think I will be), it looks like the "Firestorm/Grey" skin is probably the best choice for me. At least for now.
2012-02-11
So far so good with Firestorm
It's been a couple or so days now since I updated Firestorm to 3.3.0 and, so far, so good. Unlike back in June last year, when I first tried it, I seem to be sticking with it in preference to Phoenix. The subsequent releases of Firestorm had me using it less and less so this is a bit of a first -- a version of Firestorm that is "sticking".
It's not without it's problems, of course. I've found that pressing the people button (to get the radar) can, randomly, cause a crash to the desktop. In this case it seems that it's only the first use of the button in any session. If it works first time it'll work for the rest of that session. I've yet to work out what the pattern is here.
The only other big problem I've found so far is the coding sea sickness issue I mentioned earlier. I'm still not sure if that's a skin issue or a general issue -- I must find the time to give that a proper test.
Some of the very minor niggles that used to bother me seem to have been fixed too. One good example is that they've introduced the description field into the payment dialog. This was always a handy thing for me in Phoenix. I use a different account to hold the money for Z&A Productions so, when I transfer money to that account, I make sure I give it a useful description so as to help keep track of what's what (same when going the other way too). Firestorm didn't have that so no payments could have those useful descriptions. Now that that's in Firestorm that's one less thing that gets in my way and drives me back into Phoenix.
So far, in the past couple of days, only one thing has driven me back into Phoenix. I needed to perm the contents of a build and the permission setting dialog is a bit messed up. One of the check boxes is partly hidden behind another control:
While it's no show-stopper, I was busy and needed to get it sorted there and then so it was quicker to switch to Phoenix so I could have confidence that the operation was working as I needed. I suspect this might be a skin issue (I'm using the vintage skin which I really like as it makes me feel right at home).
Another thing that's (still) missing is the ability to click on avatar names when they show up in local as part of radar alerts (the chats that tell you when an avatar has entered the region, or come in draw distance, or come in chat range, etc...). I did JIRA this back in the middle of last year (FIRE-1439) and I thought it had been added but, as of 3.3.0, it still doesn't happen. Looking at the JIRA again I see that it says that it's fixed for "Phoenix Firestorm 4.0.1" so I guess it's done but merged into a body of code that isn't 3.3.0.
As someone who looks after a region, runs a store and provides a public hangout it's an annoying omission. It does make keeping an eye on things just a little harder than it is under Phoenix.
It goes without saying that search is still terrible. I really don't like how it's done now. Of course, this isn't the fault of the Firestorm team, that's down to the Lab, but I wish they'd do something a bit faster and less directly web-based.
In summary: so far, so good. I'm logging in with Firestorm pretty much every time now that I'm using 3.3.0. I've only switched to Phoenix once because of a problem.
It's not without it's problems, of course. I've found that pressing the people button (to get the radar) can, randomly, cause a crash to the desktop. In this case it seems that it's only the first use of the button in any session. If it works first time it'll work for the rest of that session. I've yet to work out what the pattern is here.
The only other big problem I've found so far is the coding sea sickness issue I mentioned earlier. I'm still not sure if that's a skin issue or a general issue -- I must find the time to give that a proper test.
So far, in the past couple of days, only one thing has driven me back into Phoenix. I needed to perm the contents of a build and the permission setting dialog is a bit messed up. One of the check boxes is partly hidden behind another control:
While it's no show-stopper, I was busy and needed to get it sorted there and then so it was quicker to switch to Phoenix so I could have confidence that the operation was working as I needed. I suspect this might be a skin issue (I'm using the vintage skin which I really like as it makes me feel right at home).
Another thing that's (still) missing is the ability to click on avatar names when they show up in local as part of radar alerts (the chats that tell you when an avatar has entered the region, or come in draw distance, or come in chat range, etc...). I did JIRA this back in the middle of last year (FIRE-1439) and I thought it had been added but, as of 3.3.0, it still doesn't happen. Looking at the JIRA again I see that it says that it's fixed for "Phoenix Firestorm 4.0.1" so I guess it's done but merged into a body of code that isn't 3.3.0.
As someone who looks after a region, runs a store and provides a public hangout it's an annoying omission. It does make keeping an eye on things just a little harder than it is under Phoenix.
It goes without saying that search is still terrible. I really don't like how it's done now. Of course, this isn't the fault of the Firestorm team, that's down to the Lab, but I wish they'd do something a bit faster and less directly web-based.
In summary: so far, so good. I'm logging in with Firestorm pretty much every time now that I'm using 3.3.0. I've only switched to Phoenix once because of a problem.
2012-02-10
I made another mesh!
Nope, still haven't RTFM. Yup, faffed about some more and made a second pointless object. Hey, come on, you have to dabble first and then RTFM, right?
And, before you ask... no, I have no idea what it is. It's three shapes, stuck together, and mangled up a bit, just to see what happened if I stuck three shapes together and mangled them a bit.
And, before you ask... no, I have no idea what it is. It's three shapes, stuck together, and mangled up a bit, just to see what happened if I stuck three shapes together and mangled them a bit.
I made a mesh!
I'll happily and readily admit that I have no idea what I'm doing. But, having grabbed the free downloads of Hexagon and DAZStudio the other day, I just followed my nose between the two of them and, more by luck than judgement, I appear to have made my very own mesh object.
No, I don't know what it's supposed to be either. But it's all mine!
At this rate I might have to actually RTFM and figure out what this is all about. Or I could stick to scripting, that's easy.
No, I don't know what it's supposed to be either. But it's all mine!
At this rate I might have to actually RTFM and figure out what this is all about. Or I could stick to scripting, that's easy.
2012-02-08
Seasick
Earlier today I installed the latest version of Phoenix Firestorm (v3.3.0). So far I'm reasonably pleased with it. While I've not had the chance to try every part of it that matters to me, yet, I've been using it rather than Phoenix all day and I've not got anywhere near as frustrated as I have with past versions.
There is one small wrinkle though. If I'm editing some code in the script window and the code is more than one window length in length the code scrolls upwards a couple of pixels for every single keystroke. I think, in all my years as a software developer, this is the first time I've ever felt seasick from coding.
It's possible that this is a problem with the "vintage" skin that I decided to use this time. I did ask in the support group but didn't get a response (it was fairly busy at the time so I'm not surprised). When I get a moment I'll see about using a different skin and seeing if the problem still exists. Either way, when I can, I'll see about filing a JIRA about it.
Seems a shame that I might have to switch back to Phoenix to write a non-trivial body of code when, in all other respects, I'm feeling at home in Firestorm right now.
There is one small wrinkle though. If I'm editing some code in the script window and the code is more than one window length in length the code scrolls upwards a couple of pixels for every single keystroke. I think, in all my years as a software developer, this is the first time I've ever felt seasick from coding.
It's possible that this is a problem with the "vintage" skin that I decided to use this time. I did ask in the support group but didn't get a response (it was fairly busy at the time so I'm not surprised). When I get a moment I'll see about using a different skin and seeing if the problem still exists. Either way, when I can, I'll see about filing a JIRA about it.
Seems a shame that I might have to switch back to Phoenix to write a non-trivial body of code when, in all other respects, I'm feeling at home in Firestorm right now.
2012-02-07
Random content giver
Yesterday Miss Eve IMd me in-world to ask if it would be possible, with a script, to give a random object out from an object, on touch. Moreover, would it be possible if the objects were transfer-only. Obviously, I've written plenty of code before that gives inventory, but I've never done anything that quite relates to this particular situation (coincidently it also crossed over nicely with a question that had been asked in a scripting help group the day before, to which I'd suggested an approach but which I'd not tried myself).
So, having said that I couldn't see a reason why it would be a problem, I had a quick play. What follows is the result. I'll stress that this was just for testing purposes, I suspect that it wouldn't scale too well if you had an object with a large inventory to give out, and I'd suspect that the script time peak when loading the array would be higher than I'd like too.
But, on the off chance that it's a useful start for someone to work from, here's what I came up with when testing (note that it also has a "give only once to each avatar" checker in there too):
So, having said that I couldn't see a reason why it would be a problem, I had a quick play. What follows is the result. I'll stress that this was just for testing purposes, I suspect that it wouldn't scale too well if you had an object with a large inventory to give out, and I'd suspect that the script time peak when loading the array would be higher than I'd like too.
But, on the off chance that it's a useful start for someone to work from, here's what I came up with when testing (note that it also has a "give only once to each avatar" checker in there too):
2012-02-06
New desk
Since I put my new home out a few days back, I've been meaning to "upgrade" my office with a newer desk and chairs. I've had a rather nice and simple mesh set in my inventory for a while now and have been meaning to sort them out (you can find the set here on the marketplace). The chairs weren't scripted for sits so I had to sort that out. Today, I finally deleted my old desk, dragged a pose and a script into the chairs, and got it all out and working:
The set came with some extras to go on the desk, most of which I removed. I kept the phone (no, I don't know why either, other than it looks good), the books (when I get a moment I'll probably have them link to the LSL documentation when I click on them) and the laptop (for no other reason than what the hell else would I have on my desk?). The laptop had an empty screen though, I couldn't let that stand. Thankfully the screen was a face in its own right so, one quick screen grab, edit and upload to SL later...
In case you're wondering, it's this code that's on the screen.
I might look into tweaking the textures at some point in the future but, as it stands, I'm actually pretty pleased with how it all looks.
The set came with some extras to go on the desk, most of which I removed. I kept the phone (no, I don't know why either, other than it looks good), the books (when I get a moment I'll probably have them link to the LSL documentation when I click on them) and the laptop (for no other reason than what the hell else would I have on my desk?). The laptop had an empty screen though, I couldn't let that stand. Thankfully the screen was a face in its own right so, one quick screen grab, edit and upload to SL later...
In case you're wondering, it's this code that's on the screen.
I might look into tweaking the textures at some point in the future but, as it stands, I'm actually pretty pleased with how it all looks.
2012-02-04
Bad move
I saw them. I had to have them. Installing them in the workshop might not have been a good idea though...
Subscribe to:
Posts (Atom)