Gavin Hird

I have some orders in this status wich only involved my store. Some were actually delivered, others not. This started yesterday.

Replying to myself, this is also how they can fix it. As long as the delivered item to the Received Items has the same name as the folder uploaded for DD, all will work as before and nothing will break in the inventory. The Listed item name in SLM will simply be a label for display and for the search engine to index. It can also be localized without having any impact on items deliverd to inventory.

I couldn't. Whatever was loaded into the magic box was restricted to the ASCII character set. The difference was that Listing name on SLM did not have that restriction, which worked fine as long as it was only a display item in the web site. What was delivered to the customer was the item in the magic box that already had the restriction of the inventory imposed on it. What happens now is that you load a folder which is restricted to the Inventory character set, but on delivery it picks the Listing item from the website for the name of the folder delivered to received items. Therefore, if the listing name has characters not supported by Inventory, the name of the delivered item is truncated at the first occurence of a non-supported character. In addition something fails at the transaction backend matching this up. So as long as the delivered item picks the listing name, and not the original inventory folder name uploaded to SLM, in reality it becomes impossible to localize listing names in the marketplace.

I early on suspected there was a character set issue as soon as I started to make test deliveries on DD products as my brand name has been Boötes, and the delivered product had the name truncated after Bo. So I started to change the listing names both to eliminate the | character and changed Boötes to Bootes to make the delivered product in the received items folder look all right. It only occured to me this morning when listing names with em-dashes in them still failed, that the charcter set was the root problem of products stalling in the Being deliverd state. It is, however, a serious architectual flaw in the design of the DD system, if listed products on the marketplace cannot be localized because the product deliverd to the received items folder must have a name restricted to the ASCII character set. This restriction is due to the fact that the Inventory does not support names with non ASCII characters. HINT: Try creatre a notecard for instance with Boötes in it's name – Impossible. To me it looks like the chosen solution for DD simply no longer supports localization of listing names.

I early on suspected there was a character set issue as soon as I started to make test deliveries on DD products as my brand name has been Boötes, and the delivered product had the name truncated after Bo. So I started to change the listing names bott to eliminate the | character and changed Boötes to Bootes to make the delivered product in the received items folder look all right. It only occured to me this morning when listing names with em-dashes in them still failed, that the charcter set was the root problem of products stalling in the Being deliverd state. It is, however, a serious architectual flaw in the design of the DD system, if listed products on the marketplace cannot be localized because the product deliverd to the received items folder must have a name restricted to the ASCII character set. This restriction is due to the fact that the Inventory does not support names with non ASCII characters. HINT: Try creatre a notecard for instance with Boötes in it's name – Impossible. To me it looks like the chosen solution for DD simply no longer supports localization of listing names.

This is typically what you get when you have a limited or too conform user base to do your testing, or if your test data is not representative enough for your user base. All test data must have international / non US content, as the testers must represent the major languages your support.m

I have found that all the transactions that have failed for me has the characters ö | or – (em dash) in the listing name. Looks like a sensitivity to charachter set (ASCII only) might have been introduced. Do you guys see the same pattern in your nondeliveries?

You should still be able to edit the products i question. The maturity issue is easy to fix. Put it in a higher maturity (M or A) and relist. The rest has most likely to do with being in the wrong category. Check the guidelines and move the products to a more appropriate location and relist.

The short answer to your question is the need to force a purge of old and obsolete merchandise from the marketplace. Just my 2 L$

I have the same issue for items being sold on the 22 and 23. The items in question were at the time boxed DD items, they have been converted to folders yesterday and today. I have filed a ticket for it.

Yes, it is a bit of a problem. Either they must release the stale transactions so they run to completion, or they must be rolled back. I guess rollback is safer as the link to what shall be delivered is porbably broken. Will make a support ticket and see if they manage to fix it.

I have multiple sales orders from the last 2 days in status Being delivered. Also, every time I log on, my Received items are filled with contents of 2 test deliveries. Over and over again.... Looks like major fail!

Glad to see these steps. Should provide for a bit of a clean-up of old items in the marketplace.

Ciaran Laval wrote: Can you rez an item from the received items folder? I had no problem rezzing the bear directly from the received items folder.

Converted the first server, and the upload worked as described. Test deliveries did what it should do also. Deleting obsolete items was a bit of a pain as they could only be deleted one by one. Selecting more than one for deletion resulted in a oops message. I am sure the servers are getting hammered though. Will convert my next server in a day ot two if this one works as expected. Then comes the unpacking of the boxes for upload....

Toysoldier Thor wrote: Like I said to you and the others that are looking for legal loopholes to violate a Creator's IP intent and rights. This has nothing to do with looking for loopholes, but everything to do with clearing up the landscape for what the actual legal picture looks like. Lulling people into thinking they will get legal protection by declaring a "licence" that has no root in the law serves nobody any purpose. It only creates noise, misunderstandings and frustration, and will at the end of the day hurt the issuer's own business.

You still don't seem to understand or accept that a SecondLife account can't breach IP – only persons can. ...and the person already obtained a licence to the material with the initial purchase. So the court could only evaluate the case based on financial loss by the merchant. A loss that for most full perm items traded in SecondLife amounts to a few dollars at most. You would be hard pressed to find any creator that operates with so many alts that the loss adds up to something. Such a case would be thrown out of court immediately. Even the petty court would not bother. Technically, it is impossible not to breach IP accoring to your twisted logic, unless main and alts operated on completely different computers. The minute you view the item in question on your computer, it is stored in your viewer's cache. So already there you have technically shared it with your alts on the same computer. Further, most creators at some stage store full perm textures on their machines to be able to modify them in a graphics application one way or the other before they are applied to a product. How is that not sharing with your alts? – They see the same file system as your primary. Or they use an alt to test their final product with end-user permissions before the product is put to the market. Which is nothing but fair use of the full perm material by any legal standard. Do you really suggest the tester should have to purchase another full perm set and apply to the product being tested? In my view a "licence" such as this is completely absurd, both because it is in violation of all established IP and fair use legislation, but also because it is virtually impossible to implement from a technical standpoint unless you have one computer per SecondLife account.

My only advice is for merchants "NOT to declare a license that is not rooted in legal realities". ;-)

LOL - you keep making insinuations that has no base in fact! :-)) What I say is this: To declare a license that is not based in legal realities don't give you any protection whatsoever, but only hurt your business. The same goes for TOS. Ask Microsoft if they enjoyed paying 1.8 billion Euro in fines.

The reason is, at the bottom of it, rooted in technical limitations that can't be mended without major re-engineering of the asset system.

Large sections of LL's TOS does not hold water meeting European legilsation when it comes to privacy and consumer legislation. This is fairly common for US companies. Both Facebook and Google are in for it right now with the EU. The same is most likely the case for IP rights.

Toysoldier Thor wrote: Gavin... you are right that you all agreements between you and LL are to YOU and not your Avatar accounts with LL, then why did EACH of your LL ALTS have to register for and agree to the terms LL set out for you before you logged in? Why Did LL not register YOU the human and allow you to simple add more accounts related to you? Simply because the permission system in SecondLife is derived from the Unix permission system. I have previously posted to the extent how this could be reorganized to have a common asset store for a main account and alts. It takes a bit of system re-eenigneering to do it.

Toysoldier Thor wrote: So stop trying to find loopholes in an attempt to violate a IP creator's rights. First of all I am not looking for loopholes to violate an IP creator's rights. It is a completely baseless insinuation! I also don't have any assets in my inventory created by you. They were deleted months ago. So you can stop that discussion right now! Just because there is a TOS does not mean it holds water when tested with the legal system. Both Microsoft and Apple has to warying degree found this out the hard way. To declare a licence that is not based in legal realities, is nothing but disengenious and only hurts the issuers own business.

That has to do with the interest they pay for the money in your account, but I can assure you they could not deny you, the owner, to withdraw your assets at any time. There might be a penalty on doing so (on the interest paid), but they could not deny it. So your example is compensation and cost for someone managing your assets. The ownership still is yours, the legal you.

As anything else that belongs to you, from a legal standpoint you are the owner (holder) of any licence that you have acquired via a proxy in the form of an account whether it is a bank account, a gmail account or an alt account in SecondLife. It is impossible to grant a license to you bank account. If anyone did, the licence would automatically have been granted to you, the owner of the account. If you purchase a license from Microsoft to use Office, the license is not granted to the paypal account you may have paid it with, but it is granted to you. The inventory of an alt account in SecondLife is just assets belonging to you, like money in your bank account is an asset beloning to you. You, the legal person, have the ownership of the assets, as you also have the full responsibility. You must not let the legal aspect be muddled by the fact that we in SecondLife tie virtual personas to accounts that you own.