Sassy Romano

We shouldn't because that's not where the root of the issue lies. The issue remains that LL should never present items which are already known to be a demo (based on it having a linked full product) in the search results, at all...ever! End of problem, it's just a matter of a search excluding items which have a related full item, how hard can that really be? Snickers, I suggest that you create a JIRA to highlight a fault in the JIRA process.

I still want the L$27,000,000 they owe me for my pose balls. They never did provide any proof whatsoever that the funds used to purchase were obtained fraudulently. No recourse, suck it up!

Henmations ceased to function some years ago

Also worth mentioning that the flagging team have demonstrable form in just unlisting things that are not in breach of the rules resulting in apologies from LL for this practice... And then doing it again even on a listing that carries the text of the apology from LL.

Not entirely true. MP reviews must be objective about the product, quality, features etc. Start ranting about how unfairly a merchant might have been will just be grounds for the merchant getting the review deleted. If you're not sure about an inworld purchase, try contacting the merchant prior to purchase.

Nutria, just be aware that no matter what effort you go to, the viewer very kindly undermines all your effort because as soon as your creation is rendered, a graphic file is placed in their SL cache with the filename being the UUID. Even without using an inventory cache viewer that are easy to find via Google, it's not difficult to resolve those UUID's. Security via obscurity and pretending things don't exist is just plain bad security.

There's no need whatsoever to scan inventory to find the item, plus that wouldn't work if the recipient had deleted the item. This is such a simple database task from day one, i'm somewhat amazed that this issue still exists. The ONLY test that has to be performed is that the currently logged in MP user (the person who is about to leave the review), is the recipient of the item. MP already has this recipient logged in the MP database. Here's the best part, the SAME trivial database comparison is all that's needed to allow someone to self redeliver an item with copy permissions. This really is database skills for beginners level.

I want a refund! You promised me that "Make Me What I'm Thinking Of" button and it never came. I always have to put in some effort!

Well... If it were just like a Maitreya Lara and all the vertex weighting matched perfectly, any clothing for that would work. Same for if it were like a Slink body or any of the others. My question though, if it's just going to take clothing from any of the others, why would people buy it and not the original? Generally, you would have to offer a creator kit to as many people as possible and hope that SL has the appetite for yet another mesh body. Avastar has nothing to do with it, there is no clothing for Avatar anything as such.

Klytyna wrote: So, if you want that dae file, better start 'Splatting' about your daily activities in excrutiating micro-detail now... I got the kit in the end and didn't have to splat all over Fartbook or any other social media but I accept your comment as probable for the norm.

R

If LL have refunded someone else but not transferred the L$ back to you then you should file a ticket. They are somewhat obliged to either return the money to you and if they do this, they should remove the item from the recipients inventory. In any case, if you are out of pocket and assuming that someone else has been refunded, they should still remove the item from the recipients inventory. I'm not sure it's what I'd call a scam, just very poor actions by LL, if it's exactly as you describe. Open a support case.

Um, if they create a custom piece for you, they're a "creator". Don't forget to tell them you don't like them when asking them to do the job for you!

OK, my mistake, when you mentioned textured buttons and UUID s, my brain immediately went to texture HUD usage What I understand you are doing is providing a PIN pad HUD. My question here though is where does your tthreat actor reside in this scenario?

No, I won't stop posting because it appears that you simply don't understand the problem that you need to solve. "The problem with textured letter prims (a,b,c,d) is that the texture uuid needs to be mapped to a buttonID which can be worked out if captured in transit. Also a sort of circular roller or object with indented mesh faces have the same problem." Assuming that your text above implies that you're trying to create a texture hud that sends a UUID to an object, then this is an exercise in futility for the reason I have already stated. That being that at each client that renders the texture, the UUID is the filename of the texture in the users texture cache. In otherwords, the trust fail isn't in your lack of trust in SSL but should be in the lack of trust over the client - because the client is absolutely 100% broken in this regard. What you appear to be trying to engineer is equivalent to a method of delivering a piece of information, locked in a secure box, put inside a tank, surrounded by armed guards, only for the delivery to be left hanging half way out of the receipients letter box. If you're not trying to create a texture hud then a little more context of what you're actually trying to do rather than playing on techno snippets that may in fact be irrelevant and pointless, that would help.

kimmy348 wrote: It would be good if someone can help figure out some kind of ingenious way of clicking on buttons without revealing to the clear which button was clicked. The problem with textured letter prims (a,b,c,d) is that the texture uuid needs to be mapped to a buttonID which can be worked out if captured in transit. Also a sort of circular roller or object with indented mesh faces have the same problem. So just encrypt the UUID while sending it via your chosen channel however, you do realise that this is UTTERLY pointless given that anyone who views the texture automatically has the texture appear in their cache with the filename being the UUID and that there are already cache viewers that will render the texture in a nice user friendly way?

Scripts always run on SL servers but what you describe does not need anything that cannot already be done with LSL

Don't overstate the feature set. It doesn't strip just any avatar, only the owner of the pose ball!

And another one for Steph...

Yes, I suspect Callum actually meant GCHQ so just like the rest of the post (in humour) was completely wrong! IF any government organisation says they have deleted your data, they're definitely lying.

Callum Meriman wrote: The GHSC keep them for 90 days, unless a keyword is triggered. Who are GHSC?

Your best assumption is that regardless of what you may read in a TOS, EULA or any other text, just assume that your data is never deleted. If Facebook says it's deleted when both parties do, assume that's not true. It may no longer be visible to you but you can bet that the data is retained. Same for any online data holder.

Correct! They only do it because they're forced to due to fragmentation of the platform around mesh implementation. Prior to mesh there was no need for appliers which are really nothing more than a bad crutch as a solution for a problem which doesn't need to exist.

Alwin Alcott wrote: Sassy Romano wrote: If I were to give him an applier, using the UUID, then how is he using something he didn't have a licence to use? If I don't use the texture but merely stick a number in a notecard, I'm not using it either. Now, if I were to reference textures via UUID and derive benefit from products I'm selling then that's not ethical but it is NOT copying either. As I said, get it legally tested. LL really should have a better method of securing assets but that's another discussion. yes you do use something you didn't pay for nor got the license to do so. OP bought the skin to use, not the uuid or any other use of the textures that are the base of that skin. The texture will be shown and used on something it's never made for by the creator, not did he ever give permission for it. You can keep saying the texture isn't used but it IS. OP should buy a new skin and new fitting applier if this one isn't available, or live with the fact it doesn't fit perfectly. Yes it's a thin line, but i keep to it as illegal and not allowed. You simply defend now it's allowed to use sl cach****er and rip all textures you see, and use them. He has paid for a licence to use the skin (which is represented by the UUID which is a result of the upload of the texture). He is referencing exactly the same asset that he has a licence to use. Here's the fun part, copyright covers damages for financial compensation. If there is no applier for sale, there can be no loss. I'm not defending the use of slcacheviewer.exe and no textures are being ripped at this point. Plus, there's no need to use such a tool, the UUID's are already in the clear in the cache of ANY user who has viewed the asset. Again, it's all up for legal test but it will never get there so it's all moot.

That's exactly what he would be doing. Using the asset, not the components I.e. texture from which it is made. If I were to give him an applier, using the UUID, then how is he using something he didn't have a licence to use? If I don't use the texture but merely stick a number in a notecard, I'm not using it either. Now, if I were to reference textures via UUID and derive benefit from products I'm selling then that's not ethical but it is NOT copying either. As I said, get it legally tested. LL really should have a better method of securing assets but that's another discussion.