ab Vanmoer

Strange, I didn't receive any reply - but they have been restored for which I am pleased. Thanks, ab

I submitted my list of missing items 7 days ago, and have been checking my Markteplace store on a daily basis waiting for the items to reappear where I assumed they would, back in my Marketplace Store. After reading the above, despite not having received a reply to my Ticket letting me know that the items have been restored, I found them in Inventory-Manage Listings all are flagged as " (no version folder)" presumably I will now be able to re-list them via the Viewer. So even if you have not heard from Dakota, check your Inventory-Manage Listings they may be there.

@Linnrenate Crosby Thank you very much for the URL. It turned out to be a relatively simple change and now my Shoutcast display board supports all Shoutcast server versions up to and including V2.5 which is the latest version. I have sent you one of my boards as a gift - which you may, or may not find it useful Thanks, Ab

It is more than a little disappointing that the Linden's didn't find a way to maintain compatibility with existing scripts. I only learned of this problem yesterday for the first time when a tipjar script customer reported that the script was generating the "URL passed to llHTTPRequest contains a control character" error. Needless to say as soon as I was made aware of it I applied the fix to my script. However over the last few years I have sold hundreds of copies of that particular script, many to customers who were making and selling tipjars based on the script. It is highly probable that many of these creators have long since left SL leaving who knows how many customers with devices that not only will no longer function, but highly likely are still being sold on the Marketplace. I was not aware of the problem until now because my shoutcast display boards continued to operate flawlessly irrespective of the sim. Unfortunately however as needing more information than is available from 7.html I use a web page scraping technique which has been affected by changes in the various V2 Shoutcast server releases. V2.0 removed the 7.html and displayed a different server status page to the V1.9 status page. V2.2 restored the 7.html but also maintained compatibility with the V2.0 status page V2.4 kept the 7.html but changed the status page again. V2.5 is the current Shoutcast release, I am not aware of any stations that use it so am unable to check for changes to the status page or whether 7.html is still functional - presumably they have kept it. If anyone is aware of a station currently running V2.5 the URL would be greatly appreciated. Thanks, ab

LL has "sortof" fixed vwrsearch by redirecting it to search.secondlife.com - a completely pointless exercise because of the different behaviour between vwrsearch and search. vwrsearch required that new names include the "Resident" last name, whereas search.secondlife.com seems to return better results without the Resident last name, and more importantly the resultant pages are different enough that the screen scraping code has to be completely rewritten.

vwrsearch has been working for years now, but periodically LL breaks it and then one has to file a Jira to have it fixed. After breaking it on what seems to be an annual basis, they then take ages to fix it. Which is a pity, because for the rest of the time it is the most reliable, up to date and easiest way of getting name2key functionality. Unfortunately w-hat.com is not really a viable alternative, it is a third party web site that could disappear at anytime without warning (although despite earlier expectations, it has stayed up for years) but it is often out of date, whereas vwrsearch finds new avatars within hours if not minutes of them registering. As an alternative to using vwrsearch.secondlife.com one could use search.secondlife.com but the resultant web page does not seem to be consistent, so scraping it is a bit of a moving target.

Today Brooke Linden updated BUG-2104 (Changes to vwrsearch url breaks name to key functionality) as follows: We recently deprecated support for vwrsearch, a web page service that allowed getting the resident key from a web page. We recommend updating any products which used this service with a service that can provide this information. There are several options, some of which are listed here: Hosted services, such as w-hat ( http://w-hat.com/name2key) HUDs available on the Marketplace ( https://marketplace.secondlife.com/products/search?utf8=%E2%9C%93&search%5Bcategory_id%5D=&search%5Bkeywords%5D=name2key) We apologize for any inconvenience this has caused you. I responded: The alternatives you offer to vwrsearch are completely unacceptable, and indicate a complete misunderstanding of the requirements as well as the magnitude of the problem. Firstly, how exactly do you propose that I integrate the marketplace HUDS you link to into my vendors? Even if it was possible are you suggesting I buy a few thousand HUDS to distribute to my customers? Secondly, I know for a fact that many if not all the HUDS you link to actually use vwrsearch for their name2key lookup. Thirdly w-hat is a 3rd party service that offers no obligations, is often out of date, and may be withdrawn at any time on the whim of the owner. It is not an acceptable alternative where long term reliability is a concern, although ironically it now appears that it is probably far more reliable than Linden Labs. Although MartinRJ's workaround has been a welcome temporary workaround, it is unfortunately not a long term solution, firstly due to the already mentioned inability to find users hidden from search, and also because historically the search web page format is more likely to change than the vwrsearch pages that have remained static for years. I can not believe that it has taken nearly TWO months of uncertainty and the best that you can come up with are a few completely unworkable suggestions!. These suggestions did come as a bit of shock, not only because of their impracticality, but also because I thought that vwrsearch had been fixed as it has been working reliably once again for at least the past week! Yet another indicatior that LL doesn't have a clue as to what they are doing!! ab

Dahlia, Unfortunately LL in their wisdom (or rather complete lack thereof), decided that their paying customers are not mature enough to understand why LL simply can't be bothered to fix bugs or to even keep their paying customers updated as to the status of these bugs. So, at some point LL changed the JIra system; now only the person who opens a Jira is able to see it., that way they don't have to bother fixing bugs because they can pretend that each bug only affects one person. Older Jiras however are still visible though. It may be helpful if every one affected by this bug opens a new Jira, it might just kick LL into some action, to save effort when creating a new Jira, just copy and paste from the old - WEB-2362 It is really unusual to find a company that has managed to stay in business while treating its customer with the kind of contempt that LL reserves for its customers. This is a huge bug that affects thousands of people and LL can't even be bothered to let us know if they have any intention of ever fixing it. The last time it broke three years ago, LL took it seriously enough to have it fixed in one day. Current staff JUST DON'T CARE!

Innula Zenovka wrote: In the past, when LL have broken scripts that scrape LL webpages, it's always turned out to be by accident and they've normally fixed it in a few days. Similarly, when they've intended to break stuff -- e.g. posjump or the llVolumeDetect hack to phantom child prims -- they've given us some warning. Hi Innula, I noticed this was down on March 27th and filed a Jira, it's the first Jira I have filed in ages, so I was unpleasantly surprised to find that Jiras are now only visible to the person who files them. Any way in response I received this message from Alexa Linden the next day: Alexa Linden commented on BUG-2104:Hi ab, can you tell me the last time you knew this was working properly? I'm trying to narrow down the cause. Thanks! Which would support your supposition that it was broken accidentally. Unfortunately I have heard nothing since Although as suggested earlier in this thread, it should be possible to use search.secondlife.com, one can not rely on the format of the web page being stable, so scraping code would have to be updated as the page changes. LL gave us vwrsearch.secondlife.com in August 2009 as a supposedly stable alternative after changes to search.secondlife.com broke scraping code. ab

Pamela Galli wrote: The emails have changed back to "service" again. I missed the memo. Again. Only the 4th and they have completed a WHOLE month's work I hope that they aren't completely shattered when they have to roll it ALL back again weeks from now!

Wow, that must be so disheartening for the commerce team, a whole months worth of work rolled back

Thanks Pamela

It's official - the sales notification from email address has changed - http://wiki.secondlife.com/wiki/Release_Notes/Marketplace_Current#Release_Notes_for_Current_Marketplace_Release All the important marketplace functionality that is still missing or broken and the best that LL could come up with is a stupid change that only serves to mess up merchant's email filters :matte-motes-angry:

Sassy Romano wrote: Well... the architecture is broken because there are non transactional operations and by transaction here, i'm using the term "transaction" in the atomic defintion of it either completing in full or rolling back. The issue with MP is that a MB could send an item and THEN FAIL to communicate back to the back end just as easily as there be a forward failure of the back end to communicate with the MB to send an item. Once that return failure exists, the back end now is potentially in a holding state waiting for a retry of a timeout and in the case of a timeout, the MP back end could refund the customer. I have on more than one occasion seen a payment appear in my transaction history long before receiving the magic box delivery message. This would indicate that the MP is not waiting for a notification from the box before completing the transaction. There may of course be other reasons for things being reported out of sequence .... but as you so rightly said, as mushrooms all we can do is speculate.

Zanara Zenovka wrote: Welcome back Ab! Just wouldn't be a decent migration nightmare without you! Thanks Zanara, Arwen, WADE1 and everyone else Not really back just sticking my head above the parapets :smileywink: I took the last migration far too personally, putting far too much unproductive time and effort into trying to browbeat the commerce team into behaving professionally. And in the end it was all for naught, the Marketplace went ahead bugs and all while the merchants were left scrambling, trying to correct failed migrations and redoing listings to comply with the reduced functionality. To this day a large percentage of the bugs and the majority of feature requests languish in the Jira, completely ignored by the Lab. And considering that the majority of feature requests were requests for important functionality that had previously existed in xstreet, which LL have chosen to completely ignore, many of which a half competent programmer could have implemented in a few hours, seems to me to be a clear indication of the low regard the commerce team has for the merchants.

Flea Yatsenko wrote: DD was designed to avoid this problem. I don't mean to be a LL apologist, but Magic Boxes rely on a lot of very awful communications methods (like llEmail) which leads to long script delays and events falling off of the event queue and being forgotten forever by the simulator. This is a known bug with magic boxes and it's probably giving your product away for free. Actually that is completely back to front. It is not a bug with the magic boxes but with the marketplace software. The magic boxes are instructed to deliver a product and they deliver it, the magic boxes are not involved in processing the payment. Irrespective of the mechanism (DD or magic box), delivery is initiated by the marketplace software, so moving to DD will make no difference to this particular bug, the only difference is that while we have the magic boxes merchants are notified of deliveries by the box allowing us to reconcile deliveries and payments. Once magic boxes disappear this ability to track deliveries also disappears. The only alternative will be to include an on-rez notification script such as the one Zanara has so kindly provided in each product.

So it seems that it has been another weekend of Marketplace hiccoughs (a euphemism for terminally broken pile of junk). Looking at the orders page, I see transactions with the status "Being Delivered". Clicking on "View Order" the status is shown as "Undelivered" (so much for consistency), payment status is shown as "Not Paid", Yet, as in the past I have received a delivery notification from the magic box. So either the customer has received the item and not paid for it - which I can live with. Or the customer has received the item and LL has pocketed the payment - which is completely unacceptable. The bottom line is that once the magic boxes are switched off, we have no way of corroborating what has actually been delivered. The magic boxes are the last vestige of a system that worked far more reliably than the Marketplace ever has or ever will, and that is what LL wants to kill, to replace with a system developed by a team that appears to be lack even the most rudimentary development skills . And if anyone has any doubt as to the commerce teams complete lack of competence they need only look at https://jira.secondlife.com/browse/WEB-4587 a nightmare that affects hundreds if not thousands of merchants, yet the commerce team refuses to fix it or even comment on it, clearly something they are completely incapable of!

As far as I know this is an eBay change, not a Paypal change. From an email I received from eBay a few weeks ago : Update to the way sellers below eBay's minimum performance standards are paid through PayPal Starting May 31, sellers who fall below eBay's minimum performance standards may have their buyer payments show as pending in their PayPal account for a period of time to help ensure successful fulfillment. If you're subject to this update, you'll be notified when you list and you'll receive an email notification from PayPal when your funds are pending. You'll also find information in My eBay showing the estimated date funds will be available and steps you can take to help get your funds faster. Either its a not so subtle way of eBay trying to push sellers to sell more or else its a genuine attempt to reduce seller fraud. So it really should have no impact on cashing out from SL.

For a single prim scrolling vendor - https://marketplace.secondlife.com/p/Vendor-gift-purchases-gifting-payment-sharing-split-pay-very-low-lag-multi-vendor/272656 These are very low lag, copyable and only L$49 including the ability to "buy gift". They also offer near instantaneous scrolling. Chelsea Malibu wrote: I am not sure how a single prim vendor could allow you to scroll through objects but it could be done, I'm just not sure how you would do the graphics as it would need a macros done that sets the selection points on the prim you need to touch.

It takes just one item to throw the whole thing off. Just one tiny script or notecard in one little insignificant prim is enough. Check every single prim, check the contents of each and check all the textures. Agrona Longfall wrote: ETA: I am unable to change the permissions of these items in my own inventory Permissions as show in the inventory can be confusing, that is because the perms displayed are the most restrictive combination of all the perms of all parts of an object. For example a prim with full rights which contains a no-mod script will be shown as mod when rezzed, but no-mod in the inventory. As a result, viewing or changing permissions on items in your inventory is only really useful for items that are not a combination eg. a script, notecard, or texture.

Paladin Pinion wrote: I haven't received a single review since the new marketplace opened, though I do get compliments in IM. I see competing products with hundreds of reviews that were transferred from XStreet. Their reviews are largely static too now, but they always look better because they are displaying the old totals. One of the many arguments that I had with Brodesky was about importing star ratings and reviews from xstreet, thus giving established products an unfair advantage over newer products that would be unable to garner reviews via the convoluted marketplace system. Although many merchants seem to think that ratings are meaningless as they can be gamed, yet from a customer perspective, psychologically, a bevy of red stars does promote a feeling of confidence in a product. @Ashtyn The poor implementation of ratings and reviews was raised over 5 months ago https://jira.secondlife.com/browse/WEB-2650 unfortunately this has now been assigned to Grant Linden who has long since moved on to greener (or should that be other) pastures. Somehow I doubt that Brooke and her team have actually taken the trouble to go through the Jiras that so many merchants wasted countless hours compiling and commenting on. Actually I wonder if the current commerce team have even taken the trouble to do a proper appraisal of xstreet which functionality wise, is still streets ahead of the marketplace.

Madeliefste Oh wrote: Advertise your product, Linden Lab... more residents will boost sales overall. Haha, so obvious, yet so true

Darrius Gothly wrote: I did a screencap and found that the ideal dimensions for an image are 480w x 33h. And by "ideal" I mean the dimensions they either crop or resize images into. I'm not exactly sure where those numbers came from, but "non-standard" is clearly the goal. Oh I got it as 480 x 48 pixels. Would it be too much trouble for the Lindens to actually specify what the necessary dimensions are instead of everyone wasting tons of time having to experiment? On a related note, it seems that the only way to make badges work is by using a tile-able texture because the texture is clipped or tiled to encompass the containing text which may differ in size by browser and/or OS eg Firefox on Windows and Linux notice what happens when the "Registered" text wraps:

Afer a closer look, I realised that what is happening, is that the badge image is clipped or repeated in order to encompass the text. So different browsers and/or operating systems will give a different effect. Here are two screenshots, one from my Windows laptop, the other from a Linux computer both running Firefox. Notice the slightly difference font sizes, causing the "Registered" text to split over two lines, causing a partial repetition of the background image. It seems that the only way to handle this smoothly would be to use a "tile-able" image for the badge. Also I just noticed a major spelling error, there is no such word as "Honored" . Actually on a more serious note, as a company that plays to the international market, one would hope that LL would make more of an effort to actually realise that the rest of the world is not just another US state.

Earlier, before redoing my badge, I saw that your badge had the problem of the top repeating on the bottom. But as both our badges looked right the next time I came to this page, I assumed that you had fixed yours and that mine was fine. Coming back to this page after logging out, I find that once again both our badges display the problem. An inconstancy that needs to be fixed, and no amount of wasting time fiddling with images will get it right until the bug is fixed.