Jump to content

Sassy Romano

  • Content Count

  • Joined

  • Last visited

Everything posted by Sassy Romano

  1. Yes, all products that meet the criteria for adult need to be set as such, otherwise they wouldn't be adult rated.
  2. Regarding the above, demos can easily be removed at source by the query. Every demo has a parent product thus it's easily identifiable as a demo to code. There's no need for an additional attribute like "IsMesh" or "Permissions", the fact that it has a parent product means that the database field is not null! Therefore, just as people can do a search on attributes such as permissions and mesh, the search merely has to exclude demos. There's never a reason to show demos, ever. Aged content, this IS a problem and it's exacerbated by Marketplace and inventory based selling. Now, merchants can drop off SL and never return and their old, stale content isn't even removed by any cleanup process. Long long ago, I proposed two things:- Last logon date of the merchant against each listing (below their name for example). This lets people see that a merchant is still active (within reason). This isn't a privacy issue, that information is already readily available via various methods. A requirement to include a refresh against each listing. It could be as simple as a function where the merchant just had to visit the Marketplace website or require a little more but i'm not in favour of seeing an ever increasing amount of completely stale content as there's often no way to determine what's fresh and what's not. Display the creation date of the listing perhaps? This fails though with the migrations that have taken place to a certain extent. I can understand why the second bullet above wouldn't be implemented but there's no reason that the first shouldn't. Trivial effort involved and has value for customers. Dakota, as for creating JIRA's, I believe that I may have already created those but to be honest, i'm not going to check. I have completely lost faith in the JIRA process as far as Marketplace is concerned as there are still so many high value, low hanging fruit items that remain utterly ignored... Customer self redelivery of copy permission items for example - again, absolutely trivial effort for this one really, a button that instigates the same delivery process that was used to deliver the item in the first place to the same person who was the initial recipient. Massive benefit to customers and merchants alike and definitely JIRA'd. I know you're not responsible for setting priority and your input here is always super welcome but we can only say the same stuff over and over so many times in so many ways.
  3. Dakota knows this very well. Specifically:- "At this point, there is only so much updating that can be done to the existing Second Life Marketplace because of the integration of the old XstreetSL system. The only way to address some of the issues would be with an entire rewrite of the code. This would mean 3+ years of new development, along with a loss of ALL of the current listings, sales history, ratings, etc" We are where we are since the lab chose spree shopping card on Ruby on Rails.
  4. Yep, I know, wrong platform chosen for the task in hand. We can blame Pink and/or Brodesky (because they're not around anymore anyway!) Time for a new platform (or someone to be allocated some project love time so that they can fix up the search such that it doesn't return demo's at least.) The chosen platform has created an exponentially growing problem though.
  5. Dakota, you forgot the other TOP issue, that being that DEMO products are returned in search. They should not be. They should be reachable only from the main listing. Same for colour variants. Colour variants within the same listing were an intended feature that Pink Linden wanted to introduce though it never came but, address those and the second of your sentences above automatically gets reduced. Right now, for a single mesh item that has say ten colour choices and a demo, that item REQUIRES ELEVEN marketplace listings. This clutters search hugely and is not efficient for merchants or customers. Otherwise, I agree with the rest of your post which disappointingly, means no naughty step for you today
  6. Nope, i'm confident that LL will accept a signed email signed with a qualified signing certificate. 2009, not 1980 https://www.engadget.com/2009/10/31/how-to-email-a-second-life-dmca-notice/
  7. Dog...bone...SASSY!!! Hi Dakota, you just waved that red rag there and in the case of the above, i'll refer you to Case: 01707000 That case number indicates that the first sentence above is NOT always true, staff/agents have in the past delisted items which are wholly compliant with the listing policy. The second sentence has so far proved to be true. Next time, it's the cane for you ok?! (or a bird cage)
  8. I know why people state it but it's based on a false belief. The "masses" do not ask for refunds, they just don't! Rather if anything it would be the minority, a tiny minority that do. I've always operated openly with a published refund policy and never has it been an issue. It's my belief that many merchants copy dysfunctional parts of other merchants policies because some are just laughable. E.g. "no photography in the store" Anyway, I digress!
  9. Just to comment specifically on one of your posts Kenny, the first two sentences above just do not correlate. You say you don't refund and go on to question other creators who are shaking for every linden dollar? Surely it's YOU who are grasping at every L$ by refusing to refund even when someone isn't happy and most likely won't use the item? You have their money, they have nothing of use and that's ok with you? Really? Please do explain why someone who made a mistake and can't use something should lead to you being better off... A lot of creators left SL over bad reviews? a) GOOD - special snowflakes don't need to waste their time here. b) How many can you name, the list will be short. There's no evidence, if you have it, present it. Finally, given that there is no opportunity for someone to review a merchant, there should be no opportunity to review the client. The review feature is about the PRODUCT not the merchant, maybe this isn't clear? If it's not, leave LL a bad review for poor documentation and tell everyone about it.
  10. "Caveat Venditor" Kenny... Thanks Qa Boa for writing just about exactly what I was going to write. I can't get my head around the "NO REFUNDS - IT'S A POLICY!" idea. We can do what the hell we like, it's NOT a policy, it's a fragile belief that because someone else wrote it that others should too. Sometimes when someone has looked at something of mine and popped a question, will it fit? etc. I might just send them the item and just ask them to go back and pay for it if they like it. I don't check, well big deal. *shrugs* There are already too may dysfunctional merchants and while there are customers who make mistakes, don't seek to punish them, just settle the issue, it's really not difficult and I wouldn't want a review system for customers, don't have time for that at all and it would just end up being used for spite. The only reason you'd have for doing it would be to complain about someone. Would you go and leave a 5 star "excellent customer" every time someone bought and you never heard from them? Of course you wouldn't. Besides, they might have then looked at the item, called it crap and told all their friends that it's crap, is that a good customer just because you had their money but none of their opinion in person? The comments section is just fine as it is, learn to be a better merchant.
  11. I can't think of a reason to do it, it's just another duplicate layer of mesh immediately above the others already on the body, onto which an applier would slap a texture. The only reason that I can think of making yet another mesh layer, is to have greater flexibility over the UV layout but that's about it. Maybe materials? I don't know if the Maitreya body supports materials. Of course, the other reason why they might not exist is that a person who really wants to create them hasn't been granted a Maitreya dev kit.
  12. Clothing creators don't make people swap bodies, mesh body creators do that! Here's a conversation from this morning that I had in IM:- Customer: "I was looking through MP and found <dress>. I love it but I wear Belleza Isis, is there any way you can update it to include Belleza?" Me: "Hi, yes, as soon as the creator who makes the Belleza bodies stops being an idiot and starts freely giving out the dev kit so that people can make things for their mesh bodies. This is the same story for all the top mesh body creators. If you want products for the body that you have bought, you and all the other customers should be giving them grief about the way they restrict access to developer kits!" Customer: "Well guess I do not want it that bad, I am sorry that you feel that way." See the problem? WE...people who want to create for these bodies can't do it effectively without the dev kit and the pressure really should come from the customers who have bought into these closed systems, there's little that creators can do other than fill in the application form. I've done that, usually with the result of just getting ignored so there's really no point people asking me "if I can just create a <insert favourite mesh body> version". People buy into closed systems and then complain about lack of options for it. Can you see the problem there?
  13. As far as I can see, you're comparing apples and oranges. Avastar is a tool for creating clothes, avatars (if you wish), rigging them specifically for Second Life, creating animations...for Second Life. Unless i'm mistaken, Bastioni is a plug in for creating humanoid characters which then need to be rigged for Second Life and the best tool for that is...Avastar! So, to specifically answer the question, the free plug in doesn't do the job, on its own...at all.
  14. While I appreciate that not every country has the same income level, we still find people can buy the computer, pay for internet access, magically have Photoshop, 3DS, zbrush etc. Then complain about a plug in that costs a burger. Gaia also provides avatar workbench which is free but doesn't support Bento bones. Avastar is not a requirement though, feel free to use other tools.
  15. There is an upgrade price. I'll be blunt here but the sense of entitlement by special snowflakes is truly astounding! Avastar should be much more expensive than it is, it's already a ridiculously cheap price and don't forget that what has changed is a feature within SL that required a change to Avastar. Get off expecting free updates to everything when the underlying technology changes, it's not always reasonable to expect creators to keep chasing LL's updates and providing free updates for life. There is no requirement to make content for bento bones, but if you do, there's a delta update cost for around the price of a burger. Gaia and the team have to eat too!
  16. Ah ok, yes i'll take step 1, just exclude from search. Step 2 would be a different proposition but it's pretty easy, it just needs a demo folder and a migration would be straightforward too since the demo behind a listing is already identifiable. Basically, drop demo content into demo folder. Migrate by associating existing demo content with the demo folder (it's all just database content and references after all ). That's what it should look like to us, what actual work is of no interest to me because that's the job of the software engineer to just "make it work". Nobody ever says "look at that swan paddling furiously with it's feet underwater", we rather tend to say "look at that swan gliding gracefully across the pond". Program like a swan.
  17. Oh come on, that's not even a challenge! There just doesn't need to be a function to exclude demos because that should be the default, showing a demo just makes no sense whatsoever. The only reason it hasn't been done is lack of a project cost centre against which to bill the work. i.e. It just needs developer effort throwing at it. It's exactly the same degree of challenge as to why there's no facility for customers to self redeliver items with copy permissions. That's so darned trivial, it's a basic expectation and yet we don't have that and haven't since years of MP evolution. Actually, if Charles Darwin were studying MP evolution, he'd probably have to rewrite his theories. (Additional reasons, the Linden's don't show inworld, don't understand the problem). It's worth winding back history a little because demo products largely came about with the introduction of mesh clothing. At the time, MP didn't have direct delivery, so each item listed, had to be a boxed item in a "Magic Box" with no options to create folders. However, there was still no need to ever return a demo because the sheer act of creating a link from a main product to a demo, immediately creates a relationship that makes it known that the item is a demo. What inventory based direct delivery brings though, is the option of just having a demo folder within the product content folder, which reduces the workload on listing items as there's no requirement for a separate demo dummy product listing. Before anyone speaks up saying "oh but I want to be able to search for demos", you really don't! You just search for the thing you want and then pick up the demo from it. Including only items with a demo as Chellynne suggested makes perfect sense too but not to look for only demos and then find the full product, that's just backward. You don't use a web search engine to find a demo of the actual web site you want do you? If you're after music, I bet you don't search for a demo of the album first but rather find the album then play the demos.
  18. But Alwin, the "demo problem" only exists because LL have created the problem. Don't return demo's in search - end of problem. There's no getting around it. Patching up the problem by trying to introduce better handling of boolean operators is completely the wrong solution. To the back end Marketplace engine, a demo is completely identifiable because it's linked to a parent product. Just don't return the demo item of a main listing. THAT'S IT! As for why some don't have delistings for the reasons mentioned, sometimes it's because LL agents haven't got around to it or never will because some are blatantly flouting the rules. How about "why some DO have delistings for incorrect flagging?" well that's because the people who do the flagging, don't understand the rules and worse, the LL agents just remove the item without checking. Anyway, we're digressing. Demo's...never need to be presented in search results - EVER! (Where "demo's" are explicit listings that have been created as a sub listing of a main product) Thing is, with the current Marketplace system for merchants, now that it's inventory based Direct Delivery, it should be as simple as selecting an inventory item which is the demo object, NOT a completely separate listing. It's just bonkers now having to create a complete duplicate listing for a demo item and then having to link that to the main item which is essentially the same listing.
  19. I'm sure some do but given that there's no specified or required naming convention for products, it's not the merchants that are at fault. Anyone can name anything and allowing others to have malicious intent (sometimes incorrectly upheld by LL) is just plain wrong. It's the same with keyword spamming, some is blatant, some is someone else's opinion of it while to another it's promotion. Fix the system once, problem goes away and the "demo issue" is stunningly simple to fix. (If random fires kept starting in your house, you wouldn't keep buying more fire extinguishers to put in each room. You'd remove the ignition source.)
  20. It's very different, because returning a demo as a separate item, even having to create a demo listing as a separate item, is utterly pointless. In one single action, LL could address the source of the demo problem by never returning them in search. That is a far preferable action for everyone than trying to slap random merchants for unproven actions. We already have people flagging items for unjust reasons and LL agents removing compliant listings erroneously, we don't need more faulty activity. FIX THE RIGHT PROBLEM.
  21. No, there's no proof that anyone's choice of naming convention is a deliberate anything, even if it were, it's not the merchants fault that LL fail to address it properly. Fact remains, it's LL's job to not return items already known as demos. We should not subscribe to made up rules that dance around system problems!
  22. Please no. Penalising merchants for their personal choice of naming convention isn't appropriate. Not when the correct and most appropriate solution is better served by a system change to never present demo's in search results. This is trivial for LL to action but doesn't happen, further clobbering merchants due to inaction on LL's part is not the way to go. We already have to dance around LL's special oh so secret silly word list, lets not add more special pretend made up cases.
  23. 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.
  • Create New...