Jump to content
Sign in to follow this  
Prokofy Neva

Oh, Is This Why They Changed the TOS?

Recommended Posts

No, it did not work correctly, it was only able to work right in limited circumstances, after all objects were loaded. That would be fine for a static environment, but it was utterly broken for a dynamic virtual world.

The problem is that the viewer would be rendering those 5 million polys much of the time, when it should have only been rendering half of them. That's an extremely common case where the software was utterly failing.

Share this post


Link to post
Share on other sites

Well, I don't want to argue about that for forever. Though, this viewer won't change a low end machine, into a machine with nice SL performance. The content out there is still the same, and it's still a lot of what you have to render, be it a few less under some circumstances or not.

Share this post


Link to post
Share on other sites

@prokofy:

the viewer downloads everythig it needs to create the 3d world that you see your avatar intereacting with on your monitor.
i am not sure what is saved to cache besides textures. i think sounds r also saved to the local cache.
considering that sculpties r images it is very likely they r also stored in the local cache.
i am not sure what will be saved to cache by the "interesting" viewer.
this can be a good subject for group meetings hosted by lindens:)

Share this post


Link to post
Share on other sites


Solar Legion wrote:

Nope. I've posted relevant information concerning an abusive user. Don't like it? Tough.

 


Incorrect.  Nothing you posted and ranted about is relavant to the OP's qustion or this thread.  Nor, are accusations of "abusive user", which is now you being the one to break post guidelines. 

Also, if if keep that chip on your should long enough, you might start walking funny.  ; )

 


Solar Legion wrote:

 

And I'd be more than happy if people ignorant of the most basic functions and workings never logged in again. They start and spread drama like wildfire whenever something even similar to this pops up.

Between you and OF, you've got the anti-people market cornered here.  (I know, you probably thougtht someone else had won that prize!)

 

 

Share this post


Link to post
Share on other sites

I don't know the entire reason why.

Reading the changes, helped to remind me that SL is a game for residents, and a business for the lab.

I was looking for an excuse to take things less seriously. The timing was pretty good.

I could continue to ridicule ridiculous policy, but doing so, is prohibited under my personal sleepiness policy.  


Share this post


Link to post
Share on other sites

There is already a program, or viewer that can copy other peoples content without permission called a Copy-Bot been out for years many of them on the internet for free download just have to google it although I will warn you lots of them are infected with Keyloggers, trojans etc.

I would like to see a new version of Second Life like this, but the problem is how do you keep users content/IP Rights from being illegally ripped I mean if people can just Control and Copy, sure Snap-Shots are fine I could careless about recording videos or snap-shots but I am talking about like people having the ability to Copy-Bot mesh, and other items or in other words in a new Second Life steal entire items from Merchants, like my friends who create animations in SL their entire AO's ripped off and posted for free downloading rights.

What is going to prevent this, I really don't like the new Second Life TOS when it comes to Merchants they get a really crappy end from when I last read the TOS.

My own TOS  which superceeds you're tos is anything that is download on my computer I have full rights to do whatever I please with it, this does not mean that I will try to ruin merchants, or anything but if it doesn't require the Second Life service or viewer to access information that has been cached on my pc then I will do whatever I please with it reguardless of TOS, unless I sign an agreement in real life with every single player in Second Life who has uploaded the content saying otherwise.


Take Steam for example, They have a TOS saying you cant install a game without steam and without consnt usually used for Piracy, but There is a russian program on the internet that emulates steam allows a user to install any steam encrypted program or game FREE bypassing their system if I can do this with Second Life, or hack anything on my own PC without causing others harm then I am going to do it.

Just like I support Jeorge Hotz who did the PS3 JailBreak and I hope to god someone JailBreak the PS4 just to undermine Sony although I think sony learn their lession from the millions they lost cuz of the jail break.

Don't get me wrong I support IP Rights, I support merchants in SL who have the right to freely run a business and sell their content, But I do not fully enforce IP Laws when it comes to recording a video, Snap-shots, or accessing content that is download to you're PC this is between you and the company but unless LL can come up with a secure encryption program in their new Second Life and get rid of Third Party Viewers, there will be encryption broken and content will be pirated all over again.

I support the new Second Life too if they can design it properly would be great.


I also support bypassing any type of games with no CD-Cracks each user at their own, Just like Sync-Tube, for example Pirating a movie is illegal but if I take a DVD I rented and stream it to a million users its not considered piracy so I am told LOL.

But whatever, Merchants do need ways to protect their content from actually being downloaded/hacked and re-uploaded to screw them over.

Share this post


Link to post
Share on other sites

You must come from a garage then.


Most people in the United States are not required to "learn the chemistry of internal combustion" to get a driver's license and drive a car.

You aren't required to understand computer technology to operate your person computer.


And so on.

All of life is constructed this way. You don't have to be a garage mechanic because their exists the profession "garage mechanic" so that not everyone has to become one. That's how a complex modern society works. This shouldn't have to be explained.

Share this post


Link to post
Share on other sites

So then you're confirming what I said at the outset: that the data for the items in SL is no longer thrown out of the browser after each session, but is now stored on the hard drive.

Share this post


Link to post
Share on other sites

Nonsense.

BTW, I know how the browsers work, and knew about them before you were born in SL, and have gone to many, many Linden office hours discussing this.

Lexbot confirmed what I had thought -- that this  data used to be held temporarily, and is now held more permanently. The end. That was helpful. Thank you.

95% or more of the people logging on to Second Life do not know how the browser works, and it's enough even to get them to use "search" inside Second Life, let alone Google outside it. I know because I have actual customers. Quite a few of you don't and life in a bubble with your fellow geeks.

And frankly, it's okay if Linden Lab's customers don't know a browser from third base. They don't need to. In fact, the less they "have" to know, the better.

Indeed it is creator-fascism or technocommunism or whatever you want to call it to insist that people be forced to "learn" things like this. It's like that idiot former Facebook developer who insists that the entire world has to learn to code. Nonsense.

Society doesn't work that way.

As for Solar Legion's banning from my blog, his alibis get more colourful each time he tells it. Now it's "someone using my IP address." Mkay.

 

Share this post


Link to post
Share on other sites


Prokofy Neva wrote:

So then you're confirming what I said at the outset: that the data for the items in SL is no longer thrown out of the browser after each session, but is now stored on the hard drive.

Lexbot is not confirming that at all. Cache data was never thrown out at the end of a session. Your understanding of how the viewer worked in the past is simply wrong. The methodology for loading of the cache is changing to improve the experience upon arriving at a new destination (and perhaps the size will increase as well), but the persistence of the cache upon logout will not change.

Share this post


Link to post
Share on other sites

I'm puzzled why you'd support the Sony hack, which cost them millions -- and when they suffered the tsunami, too! -- but not hacking of SL merchants.

I think long ago Linden Lab decided they would not go the route of trying to encrypt or DRM their entire world, but just put the permissions on objects to signal "intent" more than anything, even with imperfect engineered deterrence of theft, and then tell people to use the DMCA system. IOW, the California Business Model.

Share this post


Link to post
Share on other sites

Well, wait. If something is held "temporarily," that suggests then that it is "thrown out". That may not be a technical term or term of art, but it does describe it for laymen.


Indeed it does sound from the Lindens' description that they now have cache held longer, on the hard drive, where before they didn't.

Share this post


Link to post
Share on other sites


Prokofy Neva wrote:

Well, wait. If something is held "temporarily," that suggests then that it is "thrown out". That may not be a technical term or term of art, but it does describe it for laymen.

 

Indeed it does sound from the Lindens' description that they now have cache held longer, on the hard drive, where before they didn't.

Give up, Prok... you're just never going to get it.

...Dres

Share this post


Link to post
Share on other sites

Of course keep it  on! Everything that helps in reducing geometry to render is a good thing. There is still plenty to render, though, which is why it can't do wonders to a low end computer.

 

Share this post


Link to post
Share on other sites


Prokofy Neva wrote:

Well, wait. If something is held "temporarily," that suggests then that it is "thrown out". That may not be a technical term or term of art, but it does describe it for laymen.

 

Indeed it does sound from the Lindens' description that they now have cache held longer, on the hard drive, where before they didn't.

The cache has always (at least since early 2008, when I joined) been on the hard drive. You've always been able to control its size via Preferences->Network and Cache.

I don't believe increasing the size of the cache will have any bearing on copybotting. People who rip content are probably not doing it from the cache. I don't keep up on the technology but, as I've mentioned before, there are tools that can be unstalled under the viewer that will pull textures and perhaps some geometry (what you refer to as prims, scultpties and mesh) directly from the 3D drawing engines on which things like SL reside. A quick Googling of "opengl model ripper" or "directx model ripper" will reveal a thriving world of content rippers who probably have no interest in the changes being made to caching by LL. They have tools that work regardless of what LL does.

And it is the independence of the ripping tools from any particular game that makes them so popular. Once you've learned to rip content from DirectX, the world is your oyster. Building a tool that only works on Second Life is like crafting a screwdriver that only removes screws in Paducah, KY. If those screws can also be removed with the Philips screwdriver available free at Home Depot with the coupon from Sunday's newspaper, why bother making your own?

That's not a perfect analogy. There may be intermediate representations of model geometry stored in the cache that are more attractive than the information gleaned from DirectX or OpenGL, but they'd have to be attractive enough to draw interest from the ripping community to invest in their decoding. Since the viewers are open source, it will always be possible, if not easy, to understand the data being sent to the viewer. But this is the peril of open source. It's open!

Share this post


Link to post
Share on other sites

@Solar Legion:
although i am no shrink. i strongly believe u should seek medical help ASAP. your obsession with prokofy seems to have passed the pissed off stage a while back. maybe u ain't crazy yet but it doesn't look like u have much until u get there. for your own good i would really suggest that u at least talk to a therapist.

Share this post


Link to post
Share on other sites

Apparently you don't know a single thing - a browser (Internet Explorer) and a client program (Second Life) are two very distinct things.

 

Keep spinning your lies there.

Share this post


Link to post
Share on other sites


Madelaine McMasters wrote:


Prokofy Neva wrote:

So then you're confirming what I said at the outset: that the data for the items in SL is no longer thrown out of the browser after each session, but is now stored on the hard drive.

Lexbot is not confirming that at all. Cache data was never thrown out at the end of a session. Your understanding of how the viewer worked in the past is simply wrong. The methodology for loading of the cache is changing to improve the experience upon arriving at a new destination (and perhaps the size will increase as well), but the persistence of the cache upon logout will not change.

Madelaine, You are absolutely correct, and Porkofy is utterly wrong. (Again)

Please READ what is written and try to UNDERSTAND, Porkofy.

The cache was NEVER CLEARED after each session, who told you that? You made it up? So stop misquoting me! It's extremely foul of you to do.

 

 

The only thing that has changed now, is what order things are streamed to the cache, otherwise everything is exactly as it used to be. There has ALWAYS been a cache, it was NEVER cleared after each session, on the user end NOTHING has changed, except we will rez things faster.

 

 

 

 

 

Share this post


Link to post
Share on other sites

Hi, Lexbot!

What you said was

The only difference now, is that the data stays on your computer a little longer so it can be re-used next time you log in. Thats all. There is no data there that hasn't passed your computer already.

 

Can you expand on this, please?   

While I agree that the data have always been stored, in the hidden folder  C:\Users\<your windows username>\AppData\Local\SecondLife if you use Windows 7, I don't really understand the bit about the data staying on your computer a little longer (I thought, unless I clear cache manually, it stayed there permanently until it got overwritten because I'd run over the limit of the cache size I'd set).

I think I remember reading that, before the changes, the viewer had to redraw the sim each time you tp there rather (as will now happen, at least if I've got it right) telling the sim which objects it has and letting the sim send it any extra ones needed, rather than downloading the lot again.   Is that what you meant?    

I agree, though, that, both before and after the change, when you log out, your cache contains (and always has) the most up-to-date list of all the objects you've seen.

As I recall it, though, the earliest versions of the "copybot" programme, at least the ones I saw when first I heard about them and wondered how they worked, intercepted the commands your computer received from SL and made their own cache of whatever the graphics card and CPU were being told to render, regardless of where the viewer was storing stuff and for how long.

Share this post


Link to post
Share on other sites


Innula Zenovka wrote:

Hi, Lexbot!

The only difference now, is that the data stays on your computer a little longer so it can be re-used next time you log in. Thats all. There is no data there that hasn't passed your computer already.

 

Can you expand on this, please?   

While I agree that the data have always been stored, in the hidden folder  C:\Users\<your windows username>\AppData\Local\SecondLife if you use Windows 7, I don't really understand the bit about the data staying on your computer a little longer (I thought, unless I clear cache manually, it stayed there permanently until it got overwritten because I'd run over the limit of the cache size I'd set).

I think I remember reading that, before the changes, the viewer had to redraw the sim each time you tp there rather (as will now happen, at least if I've got it right) telling the sim which objects it has and letting the sim send it any extra ones needed, rather than downloading the lot again.   Is that what you meant?    

I agree, though, that, both before and after the change, when you log out, your cache contains (and always has) the most up-to-date list of all the objects you've seen.

As I recall it, though, the earliest versions of the "copybot" programme, at least the ones I saw when first I heard about them and wondered how they worked, intercepted the commands your computer received from SL and made their own cache of whatever the graphics card and CPU were being told to render, regardless of where the viewer was storing stuff and for how long.

I think this is relevant to what you said bolded above:

 

"What has changed is that the server is now treating much more content as "cacheable".  The server's definition of cacheable used to be something like:  "is static and does not have a script".  The new definition of cacheable is: "has not changed position or appearance in the last couple minutes".

The viewer bug must exist inside the code that retrieves object data from cache and is more noticeable now because the viewer-side object cache tends to be bigger.  I've brought the problem to the attention of one of the developers who is working on some viewer-side changes that will compliment the next server-side interestlist changes (*), so we hope to figure it out soon.

(*) The server will soon support two hints from the viewer:

(1) "I don't have an object cache file for this region at all" --> the server will then be able to bypass some of the initial "cache probe" messages of the protocol which looks something like this:

Viewer: Hello, I would like to connect.

Server:  You are connected.

Server: Do you have cache for object 123 whose version is 456?

Viewer: No, I do not have cache for object 123.

Server: Here is the data for object 123.

Under the new system: when visiting a region for the first time the conversation will look more like this:

Viewer: Hello, I would like to connect, and BTW I can tell you right now that I have no cache.

Server: You are connected.

Server: Here is the data for object 123.

 

(2) "I'm willing to cache ALL object data in the region, including stuff that is too far away or too small to see" --> the server will eventually stream all cacheable data to the viewer, including sky boxes far above.  It sends the non-visible data with a delay so that if you're flying through the region on a jetpack and leave soon after arriving you won't get the extra data, and once it starts sending the non-visible objects it will be in a lazy fashion -- lower bandwidth than when sending what is in front of you."

Andrew Linden

http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2013-04-01/td-p/1954059/page/2

Share this post


Link to post
Share on other sites

Thanks.   That looks like the passage I thought I remembered reading.

I'm not sure, though, whether  "[t]he server's definition of cacheable used to be something like:  "is static and does not have a script".   The server has never, as far as I know, sent any details to the viewer about whether the object is scripted, so I don't see why being scripted or not should affect whether or not its cached.

The viewer doesn't need to know if my hair contains a colour changer script or not.  All it needs to know is what colour my hair is and what texture to use when drawing the picture.   How my hair got to be that colour (script vs manual editing) is completely irrelevant.    

That's why scripts don't get stolen in the same way objects do.   The viewer doesn't know anything about the contents of any scripts the objects may contain.   I think people's confusion about this is based partly on the fact the visual shorthand the viewer uses makes a script seem to be inside an object, in the way a piece of paper might be inside a plywood box in RL.   That's not what happens in SL, though.   The icon just means the object has a script associated with it on the server.   The script itself never gets anywhere near the viewer.   Only the results of the commands issued by the script matter, as far as the viewer is concerned (use this texture for the hair; now move the door through 90 degrees on its Z axis; and so on).

Share this post


Link to post
Share on other sites


Innula Zenovka wrote:

Thanks.   That looks like the passage I thought I remembered reading.

I'm not sure, though, whether 
 "[t]he server's definition of cacheable used to be something like:  "is static and does not have a script".   The server has never, as far as I know, sent any details to the viewer about whether the object is scripted, so I don't see why being scripted or not should affect whether or not its cached.

The viewer doesn't need to know if my hair contains a colour changer script or not.  All it needs to know is what colour my hair is and what texture to use when drawing the picture.   How my hair got to be that colour (script vs manual editing) is completely irrelevant.    

That's why scripts don't get stolen in the same way objects do.   The viewer doesn't know anything about the contents of any scripts the objects may contain.   I think people's confusion about this is based partly on the fact the visual shorthand the viewer uses makes a script seem to be inside an object, in the way a piece of paper might be inside a plywood box in RL.   That's not what happens in SL, though.   The icon just means the object has a script associated with it on the server.   The script itself never gets anywhere near the viewer.   Only the results of the commands issued by the script matter, as far as the viewer is concerned (use this texture for the hair; now move the door through 90 degrees on its Z axis; and so on).

I know we are getting off on a tangent here.  I guess we'd need to ask Andrew to clarify.  Perhaps he did mean "a script associated with."  The viewer would need to know what the current state of the object is supposed to be when you log in.

It's interesting to me because I've been having trouble with one attachment  that I use llSetLinkAlpha in a hide/show script that everytime I relog with Firestorm I have to re-hide.  Doesn't happen with the official viewer or with other attachments I use the particular script in.

 

Share this post


Link to post
Share on other sites

So what?


The difference between "automatically clearing" or "being clearable because it is temporary" is not so important.

The point is, it was temporary.

The point is, people often clear their SL caches to fix all kinds of problem, particularly inventory not showing up.

So it was not put on the hard drive.

That's the important aspect of what is different. SL has not always loaded on the hard drive, like other games that didn't have dynamic user-generated content. Now it seems to. Except, some people are saying it always did.


Would like to hear this from a Linden, and not the know-it-all user base.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...