|
|
|
[
Permlink
| « Hide
]
Hypatia Callisto added a comment - 20/Jun/08 04:23 AM
meh, I meant to say receiving, its obvious they are getting sent around by the asset server to every client that requests them.
I thought that your own client gets all layers (skin and clothing) for yourself, bake them, delivers back to the server, and all other clients only get this baked texture. So for that reason I thought it would not be possible for any other client than my own to get the different layers for me.
Testing with the OpenGL interface also rips down only baked textures from other avatars. So actually I cannot imagine that something like: would work. Can anybody commit? If true, I agree, grabbing other avatars unbaked layer textures shouldn't be possible for a client. BTW: If that modified client offered from SLX works as described, this jira thread could be viral marketing. well, if i dont post a JIRA thread, I don't get the priority bumped up to be fixed.
The asset server should check if you have these textures in your inventory. Seems that there is some kind of security hole where the asset server can be spoofed. That's another issue related to this as well. Other clients should not be able to ever have access to the UUIDs of textures you are wearing. so damned if you do, and damned if you don't. I'd rather err on the side of information, because I really do want it to stop happening. That will happen when they design the avatar texture pipeline better. Also a case can be made for that modded client to either be banned or forced into handing over the source code per GPL. Selling it is just 18 shades of wrong. I'm voting for this.
Distributing ONLY the baked avatar texture would, very likely, VASTLY improve the bandwidth usage of SL. Just keep in mind, it won't stop content theft entirely, but it would stop a lot of "lazy content theives". If a theif owned the item in question, they could strip down to the skin, or wear a "solid texture" skin... and then wear the item they wanted to rip.. but that would still require an hour or more of detail photoshopping for anything that wasn't a skin Not everyone is going to have the skill, or the inclination to actually do much WORK to successfully rip clothes, tattoos, etc. Even then, subtle nuances like sheer fabrics, lace, etc.. would be lost.. And customers would quickly be able to discern the knock-offs from the originals. This proposal increases the amount of work needed to rip clothing/skin textures... and decreases the amount of bandwidth used by SL. [VOTED] http://wiki.secondlife.com/wiki/Agent_Domain
ideally, with the new architecture, all the baked textures should be uploaded on the agent domain, rather than the sim or region domain. But we don't have this model yet. (we need it badly, though!) proposal for checks for avatar textures:
is texture in inventory > server check if texture in inventory > send texture layers to client to bake and reupload to agent domain. Winter > yes. Actually, its supposed to work that way, but apparantly it's not working that way all the time. It NEEDS to work this way, though.
Wow. So are all layers being sent to everyone automatically, or is this modified client finding the UUIDs of the clothing that people are wearing and retrieving them separately? If the latter, I'm not even sure why those UUIDs are available...
Can someone who knows the SL client go get a copy of this client's source code? It ought to be available for free since this is a modified GPL'd codebase. Maybe we can get to the bottom of what exactly is happening here. it looks to me they are intercepting UUIDs, yes. From my tests as well, getting clothing in this way is next to impossible with a ripper, at least not with the Windlight clients. Only baked textures are coming through the line from Windlight, as far as I can tell.
Older clients > some are claiming they get all the layers, I haven't reinstalled 1.18.x yet to be sure, though. But this thing is working on all avatars regardless, which leads me to suspect UUIDs are being requested and intercepted from the asset server and applied to new clothing assets. Just from a creators' rights standpoint, this is quite a big deal. But when you factor in the effect it would have on sim performance, it is incredibly difficult to understand why this ever came about.
Think about it: if you are in a full mainland sim, say a popular store, with 40 avatars present, then if the client was in fact loading a baked, combined skin that showed everyone in the clothing they are wearing, that'd be 40 textures to load, plus however many are on the objects in the sim. If in fact all the individual layers are being loaded, that's six (6) per avatar: skin, undershirt, underwear, shirt, jacket and pants, plus possibly gloves, skirt, etc. So that goes from 40 textures to 240. I'm sure, in truth, it's worse than that. This desperately needs to be fixed. P2 I don't think it's quite like that, phoenix. I think MOST clients are just receiving the baked texture. However, I think the sim is transmitting the UUIDs of all of the layers even though they're not needed at all by anyone but the person wearing the clothing. The modified client is just retrieving these underlayers and displaying them on the client side.
http://wiki.secondlife.com/wiki/Texture_Pipeline_Improvements
just fyi for those who don't know what the http system is supposed to do. I suspect once SL moves to http this issue may resolve, but I don't know for sure. Looks to me that it will move to a capability based system, which should make things a lot more efficient. This is exactly why the scummy author of the 'NakedLife Registration Package' (currently being sold in the 'Mature' section of SLEXchange, to protect themselves from possible litigation, naturally) admits that the Purchaser of their product has to use the older 1.18 or 1.19 SL Viewer in order for the software to work. They know perfectly well that the newer RC Candidate SL Viewers do not have that vulnerabilty, though of course they will lie and say that they are busy 'working' on an update for the newer 1.2x SL Viewers to stave off any bad press with their customers who were already suckered into buying it,
Once the texture-bake patch and Client system is in place, the poorly written 'NakeLife' client will be so much wasted, non-working code, so the sooner this is ennacted as the Main SL Viewer the better for all concerned. Hang in there, gang. These idiots will be shut down soon. Time for LL to permaban anyone that creates such "open source" clients from SL. See what happens when you give away control over your product? The children show up. Nice going LL.
More episodes like this will be sure to kill the idea of open source. Make it hurt for people to behave this way LL. Texture baking has actually been a part of the older clients for some time, but its a trivial thing to mod a client to intercept and download the clothing UUIDs, sadly. This is a server side problem, not a client side problem. The server should not be sending the assets to just anybody > only the client who is actually wearing the assets. The simulator should not trust the client this much.
Actually, I suspect that the new texture pipeline may be what sidelines the old clients for good, but I dont know for sure. They're using UDP instead of http to fetch textures on current viewers, so unless someone makes a mod for them, its likely they may get sidelined. Expect a huge amount of people screaming over being forced to upgrade to the newest viewer, though. :/ I personally love the RC, and it really does run on a huge amount of platforms. LL deserves some credit there. Thafs too bad if anyone does not want to upgrade. When bad bugs are found and they have to make a new viewer to stop it, upgrading should be mandatory anyway.
a new viewer isnt going to make it better, the SIM has to stop working in a way that its easy to grab them.
still not fixed, updating affected versions.
The current reason for the client receiving the individual textures is, that if the client of the person-in-view fails or takes too long to bake or upload the texture, then your own client does the baking to accomodate for that, while showing the individual textures on the av in the meanwhile.
It's tricky to change this system, all in all. Currently, if the client does not send the individual textures, the avatar'd stay grey in grey after a clothing change, until finally it is ready to send the baked texture out. This can take up to a minute or two, so after each change of clothing or shape, this will happen anew. Grayness. A solution would be, of course, to keep a copy of the old bake while making the new one. Send out the old bake still, until the new one is done, at which point the new bake should be sent. While clothing changes would only be seen a minute or two after the fact, still, there would be no time in which the avatar is unrecognizable. updating affected versions.
By now many third party clients use a sort of 'clothing protection', that instead of sending the individual textures, replaces them with simple 8x8 gray textures before doing so.
The system has proven to be effective, the old bake is seen til the new one is finally being sent. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
SL clients are receiving *far too many avatar textures unnecessarily*
