Third Party Viewer Policy Changes Comments

[Dresden Ceriano]

---

Srilania Svoboda wrote:

the problem with that one is simple.  We had Avatar hysics and mutiple attachments for well over a year before Linden Labs realized it was a feature worth having.  Sometimes, in order for them to see there's a needed feature in the stock viewer, they have to see it out there first.  by adding this restriction, they stifle innovation, and make it so they won't know when there's a new idea that is wildly popular.

---

This is my thought exactly and it especially applies to the Mesh Deformer project, which is in the works right now.  The problems with this are twofold... 1) Qarl will be counting on people using the MD alpha in their viewers so that he can get feedback from a vast number of people in order to know how to move forward with it and 2) why move forward with it if, instead of having it implemented by TPVs and hoping, in the long run, that LL will adopt it, he'll have to go through the headache of submitting it to LL first so that they can introduce it as a feature (as if they'd developed it), only it would merely be half-baked, because of the lack of testing... meaning that, once again, the users would be left to have to help fix it.

And besides, LL is not paying Qarl to develop it, user donations are... I've never seen a company treat their users so poorly.  Not only do we have to pay to have mesh clothing done correctly, but now we can't even enjoy what we paid for until LL can make full use of it first.  I grow weary with this place.

...Dres

[WolfBaginski Bearsfoot]

It seems that the server functionality which allows this will vanish with the next roll-out of code.

No testing apparent. Polite words fail me.

And if the server code doesn't allow it, why the TPV change? 

[Dora Gustafson]

---

Cinnamon Lohner wrote:

Actually I only use the LL Viewer.  You can bitch about it if you want but just wanted other people to know that this thread was not intended as a gripe session but an information exchange about the latest policy changes.  I would ask that posters keep that in mind, but unlike some people, I'm not foolish enough to believe people won't hijack

my thread

.

--Cinn

---

(Since when did anyone own a thread? And since when could an OP writer decide the guidelines for other writers?):smileysurprised:

[Ossian1488303077]

---

Innula Zenovka wrote:

 

"Oz specifically said anything client side, UI, RLV etc. is not affected by 2.k.

 

"They don't want TPVs to introduce new in-world content and effects that the rest of the grid can't see. Weird custom attachment points, different region behavior, custom object types.

 

"They don't care about UI, building tools, RLV, etc. etc."

---

If that's what they meant to say in the new policy, that's what the policy should have said.

It would be difficult for the policy to be more vague, and that is a problem.

 

[Ciaran Laval]

---

Srilania Svoboda wrote:

the problem with that one is simple.  We had Avatar hysics and mutiple attachments for well over a year before Linden Labs realized it was a feature worth having.  Sometimes, in order for them to see there's a needed feature in the stock viewer, they have to see it out there first.  by adding this restriction, they stifle innovation, and make it so they won't know when there's a new idea that is wildly popular.

---

Extra attachment points I can see as an issue, parcel windlight settings and avatar physics not so much and if these features had never appeared in TPV's, would they have ever made it to the official client? This could seriously impact innovation.

[Taff Nouvelle]

The new policy means that my Mailman system will no longer work.

NOTE, Due to a bug in the SL delivery system, the mailman will send to all those who are online, and will then wait 30 minutes and retry any that are offline. Just leave the mailman running somewhere out of the way until it has finished. 

I am guessing that they will not be fixing that problem first, so items will still get lost if a delivery is made while the person is offline.

Thanks a bunch LL

[WhiteStar Magic]

Linden Labs is making the argument of going to OpenSimulator stronger & stronger as time goes on.....  SecondLife is "Their World" not anything like they used to promote as "Your World".   The poorly worded and potentially regressive policies need to be better thought out & presented.

 

[Kwakkelde Kwak]

---

Flip Idlemind wrote:

To everyone who's saying "RLV is safe", I hope you're right of course, but do you know that for sure?

---

 

As far as I know, unlike most TPVs, the original RLV by Marine Kelley, is open source. If it wasn't safe, people would have noticed for sure. Anyway, you can have a look yourself at the source code and if you see that code is clean and still not trust the viewer (which hypothetically could be different), you can compile your own viewer with the source code.

One little thing about RLV, as far as I know it has certain commands that rely on a viewer version message. Not sure if this is really that much different from Phoenix showing the viewer people use.

[Kwakkelde Kwak]

---

Wolfee Yaffle wrote:

I do find it funny that a LSL command that has been in SL since the beginning, is just now starting to make people uneasy. People don't seem to notice something unless it's shown to them in a GUI though, so it's isn't that surprising.

---

Are you talking about the online thingie? There's a big difference between the ll Function and the viewer showing it. the script function needs a avatar key and getting that key requires an action by the person. There's no such thing as llName2Key. There are databases and possibly other ways around it, but it was never intended to work witout the person being involved, unlike the viewer function.

 

 

[Qie Niangao]

I don't care at all about the TPV features.  They could disable all TPVs forever, for all I care, but I really, really object to using this as a backdoor excuse to break lots of scripted content that does nothing to sidestep anybody's "show offline" preference.

That part is a dreadful precedent, a real slap in the face to anybody who has ever written a script -- or bought one, for that matter.

[Anaiya Arnold]

---

Selene Gregoire wrote:

I'm so angry right now I have no words to describe how angry I am.

 

What is LL's goal with breaking temp image uploads? Are they trying to push those of us who are on fixed, limited or low/no incomes out of SL and leave it only for those who have money?

---

They are not breaking temp image uploads.  Someone jumped to this conclusion and it's surprising how many are swallowing it.

The builder UI is not a shared experience.  Temp uploads are not a shared experience.

 

 

@kwakkelde: different or not, the script function is being changed server side.

[Ciaran Laval]

---

Anaiya Arnold wrote

They are not breaking temp image uploads.  Someone jumped to this conclusion and it's surprising how many are swallowing it.

The builder UI is not a shared experience.  Temp uploads are not a shared experience.

---

 

Oz clearly doesn't think they're a good idea though.

[Innula Zenovka]

---

Kwakkelde Kwak wrote:

One little thing about RLV, as far as I know it has certain commands that rely on a viewer version message. Not sure if this is really that much different from Phoenix showing the viewer people use.

---

 Not quite.  It has a couple of commands that will return the viewer version (@version and @versionnew) and @versionnum, which simply tells you what the rlv version number is (which is all you're interested in most of the time).   

All that's required is a simple and minor change to RLV/RLVa to make @version and @versionnew return the name (RLV or RLVa) and version number without reference to the actual viewer.  

I cannot think of any circumstances in which an RLV or RLVa item would rely on knowing what viewer you're using, as opposed to whether you're using RLV/RLVa in the first place (which I know because I get a reply to the query, regardless of what the reply is) and, sometimes, what the RLV/RLVa  version number is, so I know whether your viewer, whatever it is, understands newer commands.    And in that case, I'd be using @versionnum anyway, or should be unless I like making things more complicated than they need be.

[Triple Peccable]

---

Kwakkelde Kwak wrote:

---

Wolfee Yaffle wrote:

I do find it funny that a LSL command that has been in SL since the beginning, is just now starting to make people uneasy. People don't seem to notice something unless it's shown to them in a GUI though, so it's isn't that surprising.

---

Are you talking about the online thingie? There's a big difference between the ll Function and the viewer showing it. the script function needs a avatar key and getting that key requires an action by the person. There's no such thing as llName2Key. There are databases and possibly other ways around it, but it was never intended to work witout the person being involved, unlike the viewer function.

 

 

---

The problem is the LSL function will be broken also.

I listened part of audio, and the way it sounded to me is that it is not being contemplated, it is definite that the data server function that returns the online status of an avatar will be changed so that it *always* returns OFFLINE unless the script is owned by or created by that avatar.

The only thing that wasn't definite is when it will be implemented. But all online status indicators in-world will basically be broken.

[Kwakkelde Kwak]

Ok, I didn't read that particular function is going to be changed. But for the reasons I mentioned, owning or creating the item/script makes a lot of sense for privacy reasons, something I think is very important. I'm glad LL takes this route after some horrible plans in the past like demanding SS numbers or copies of drivers licenses. Broken content can be fixed, although I'm afraid the ones that are bought are mostly only copy.

The only thing I really can't appreciate about these changes, is the fact new functions from TPVs won't be adopted quite as quickly anymore, if ever. Avatar physics and multiple attachments per attachment point were mentioned.

I can understand LL though, rather than monitoring a whole range of viewers, they can now focus on what they think is important and put their resources into that instead.

About the RLV, I know it can't identify all viewers, but it can identify one viewer nonetheless. If no version number is returned, it isn't a RLviewer.

 

[Innula Zenovka]

---

Kwakkelde Kwak wrote:

About the RLV, I know it can't identify

all

viewers, but it can identify

one

viewer nonetheless. If no version number is returned, it isn't a RLviewer.

 

---

No, if you don't get a reply from any of the @version calls, all you know is -- depending on the circumstances -- that I'm not using an RLV relay or that I've not got RLV turned on.   You've no way of knowing what viewer I'm using that's not replying to you.

[Kwakkelde Kwak]

---

Innula Zenovka wrote:

No, if you don't get a reply from any of the @version calls, all you know is -- depending on the circumstances -- that I'm not using an RLV relay or that I've not got RLV turned on.   You've no way of knowing what viewer I'm using that's not replying to you.

---

I never said you could identify anything if the function doesn't get a response. I ment you could if it did get a response. I should have phrased it better maybe...

[Da Chrome]

---

Innula Zenovka wrote:

---

Kwakkelde Kwak wrote:

One little thing about RLV, as far as I know it has certain commands that rely on a viewer version message. Not sure if this is really that much different from Phoenix showing the viewer people use.

---

 Not quite.  It has a couple of commands that will return the viewer version (@version and @versionnew) and 

@versionnum, which simply tells you what the rlv version number is (which is all you're interested in most of the time).   

All that's required is a simple and minor change to RLV/RLVa to make @version and @versionnew return the name (RLV or RLVa) and version number without reference to the actual viewer.  

I cannot think of any circumstances in which an RLV or RLVa item would rely on knowing what viewer you're using, as opposed to whether you're using RLV/RLVa in the first place (which I know because I get a reply to the query, regardless of what the reply is) and, sometimes, what the RLV/RLVa  version number is, so I know whether your viewer, whatever it is, understands newer commands.    And in that case, I'd be using @versionnum anyway, or should be unless I like making things more complicated than they need be.

---

The @version and @versionnnew check is to see which RLV/RLVa version is installed. This is important, as it dictates what commands are available to use. This is different from getting the whole Viewer version, but might have to be modified to only give out the RLV or RLVa version implemented. A smart object will determine if a set of features should be relied on or not by using this information.

[Qie Niangao]

---

Kwakkelde Kwak wrote:

Ok, I didn't read that particular function is going to be changed. But for the reasons I mentioned, owning or creating the item/script makes a lot of sense for privacy reasons, something I think is very important. I'm glad LL takes this route after some horrible plans in the past like demanding SS numbers or copies of drivers licenses. Broken content can be fixed, although I'm afraid the ones that are bought are mostly only copy. [...] 

---

Okay, first of all, let's not confuse things by calling this a "privacy" issue.  It's nice to have, I'm glad people are getting it, but it's nothing to do with RL privacy.  It's a very narrow sort of make-believe "privacy" for the avatar character (s/he can hide from the least committed of stalkers, real or imagined), but confusing this with real online privacy issues only dilutes appreciation of matters that are actually life and death for some people.

Second: No, in this case, the broken content cannot be fixed. They're unnecessarily removing functionality that has existed for years and is baked in to countless scripts. This is a very bad precedent to set.  

Even ignoring the creator-hostility of this act, they're also hopelessly clueless about how things work in-world, suggesting workarounds laughable for their implications to landowner security.

It's looking more and more that the adults are all off working on text adventure games for the cell phone, leaving SL in the hands of those too weak and lame to make the cut.

[Rayne Keynes]

I agree, this is going to do absolutely nothing to enhance any sort of real privacy while at the same time breaking thousands of products across the grid. I also agree that in this instance, the broken items cannot be fixed and the removed functionality cannot be "worked around". I am having as much trouble getting my staff and some clients to understand this as you are.

LL is effectively rmeoving basic functionality from the scripting system that has existed for as long as SL scripting has existed, and upon which literally thousands of content items are based and even to some degree whole SL industries.

Not that they care,...

[Kwakkelde Kwak]

Privacy is privacy. Simple as that. Ofcourse it would bother me more if my personal records were out in the open for anyone to use a lot more than some dork trying to stalk me in a virtual environment. That doesn't mean they're not both privacy issues. All I said was they took a good decision here if you ask me. I'm not confusing or confused.

 

Broken content can be fixed as I understand it if the person on the sign owns the script. As I said that can be an issue since most of hose things are probably copy. What did you not understand about that?

[Rayne Keynes]

No the content CANNOT be fixed. Unless I start giving out the scripts that my business is based on full perm so they can copy it into their own so it will work,...

Try convincing ANY content maker that that's a good idea or an acceptable solution,... "oh, just give out copies of your product full perm so they can be copied and then they'll work,.." THAT is what you and other people are not understanding.

People build things like online indicators to be used in clubs, land rental etc so that the OWNER of that business can indicate whether certain employees, dancers, customer service etc, are online or not,... and as such available to answer questions, help with issues etc,... by forcing the people who design these things to give/sell the script full perm so it can be copied into a script owned by/ created by the recipient, your effectively killing that business.

Having employess rez there own prim is not acceptable either, because now you have multiple prims from multiple people some of whom you may or may not have edit rights for, so you cant move them if you need to, edit if you change visual design of your business and most importantly, since you dont own the script, you can no longer update it or make changes as your business needs change.

The bottom line is, this is BASIC functionality that many businesses are built on, it IS NOT a privacy violation in any sense of the word, and LL by removing it is flat out detroying businesses.

So much for being more content creator friendly,..

[Freya Mokusei]

---

Rayne Keynes wrote:

People build things like online indicators to be used in clubs, land rental etc so that the OWNER of that business can indicate whether certain employees, dancers, customer service etc, are online or not,... and as such available to answer questions, help with issues etc,... by forcing the people who design these things to give/sell the script full perm so it can be copied into a script owned by/ created by the recipient, your effectively killing that business.

---

Easy solution to this particular problem. Have a full perm script that is copied, which only includes the online/offline detection code. Enough of those are freebies that the bits given away in there won't hurt your IP. The small full-perm script then sends the online/offline detection to the limited permission, still secure, main script.

[Kwakkelde Kwak]

You beat me to that....there are very simple solutions to this issue and I really don't see why there's such an uproar....

 

@Rayne..I am a content creator and have been since 2006. When there's an issue with one of my products for whatever reason, I try to fix it the best I can. In this case that means a small script change...

[Rayne Keynes]

And this is why stuff like this still happens with as little opposition as it does,...

Double the scripts running for a product there by increasing lag or,... you know wut nvrmnd,.. some people refuse to get the point.