Jump to content

Sassy Romano

Advisor
  • Posts

    5,115
  • Joined

  • Last visited

Posts posted by Sassy Romano

  1. 41 minutes ago, ChinRey said:

    Can we do that?

    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.

    • Like 1
  2. 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.

    • Like 1
  3. 1 hour ago, Jaidera said:

    That's not what I'm interested in. I don't have a dispute with the merchant in question, simply a very negative experience. I don't need a resolution, I'm just interested in protecting others from the same trouble.

    It's too bad you can leave public ratings on Marketplace transactions, but in-world transactions are 'wild-west' and completely unsafe.

    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.

    • Like 2
  4. 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.

    • Like 2
  5. 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.

    • Like 1
  6. 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.

  7. 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.

  8. 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.


  9. 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?

     

  10. 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.


  11. 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. :)

  12. 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.

×
×
  • Create New...