Toysoldier Thor

that is cool. I didnt know they added this feature to allow multi-item mod of many of the listing field. Also pretty obscure as I had to read your posting twice to actually find it. one of the best well hidding listing features in the merchant slm screens. It used to be a very small # of fields.

Kaid Hawker wrote: Hello all, I just have a quick question. Recently, I had to change the location of my main store. It did not dawn on me until a few days ago, that I will need to change the SLURL for my store on the Marketplace, as well. As I start into that task, I am finding myselft clicking on each individual product to edit the SLURL. At this rate, it will be spring before I'm finished! Is there a faster way to do this? Any suggestions? Thanks. Suggestion.... GET STARTED one product at a time. Sadly it was requested by me and other even back in the XSTREET days that this limitationbe fixed. The inworld Store SLURL should be modified at the store level not the product level. It should be a global changable parameter. BUT... this is one of countless unfixed SLM bugs and missing features that Brooke and her team continue to ignore while they work on their own pet projects of priorities that they set - not that Merchants tell them is important. Welcome to SLM and the LL Commerce Team's focus on Customer Service - NOT

Darrius Gothly wrote: I don't always see failures either, but I do see delays like Zanara documented every night. With that said, IMO any delivery that takes more than a few minutes is inherently a failure. We've demonstrated that the delivery slowdowns are related to a server lag issue on LL's end. It's not a fault of the Magic Boxes; they're sitting there idle waiting for commands for SLM. The Sims are not lagged, many first-person observations of their own magic boxes during the slowdown proves this. So we are receiving Direct Delivery as a solution to an overtasked server computer. /me scratches head ... Well, it's not the MOST expensive Server Upgrade I've ever seen, but it's damn close. LOL Darrius.... you posted exactly what was in my head ! So this set of testing from Zanara and others make it very clear the "ALL EVIL" Magicboxes are not so evil and are moreso the Scapegoats of delivery delays / failures that are being caused by LL servers. And since LL could not perform their own diagnostic set of tests on the root cause to these long standing delivery complaints, they decide instead to develop a high priced, LL resource intensive, and very likely Merchant disruptive DD solution. All they had to do was upgrade a server or change a backend system process. And if it is a Server / backend process problem, DD will likely be impacted by the same resource constraints. That is the LL that we know and love ! Chances are that LL wanted to play and experiment with DD and just used the delivery failures complaints as the excuse to PLAY. This is not the first time LL Commerce has devised a crazy development solution and blamed its need on a problem they promoted.... Remember the FREEBIES / CLUTTER REDUCTION TAXES and the system that was gonna be developed around that before they realized themselves it was technically impossible to build with XSTREET (what we all told them on day 1)?

Actually its not Moot since I hope the new DD Delivery will improve the sales & delivery notification reporting to state when a sale was initiated and when the order was completed with a successful delivery into the customer's inventory.

So lets Deduce it: CURRENT MODEL My personal inventory has a structure of selling product folders (for me generally 1 folder for every product I sell on inworld / SLM) that contains both my FINISHED BOXED SELLING ITEM as well as all the content in the box, photos, marketing content, demo items, older boxed versions, etc. related to this product). This folder structure in NO WAY resembles the content that is in my Magicbox nor my inworld vendors. NOT AT ALL. (as such, this cannot be considered my SLM Master Source) My SLM has a MAGICBOX which contains ONLY the content that is available to be sold by listings on SLM. NOTHING ELSE. In fact, if I verbatim change / update an item in this box, it IMMEDIATELY makes this updated item the version of content that the next sale seconds later will sell to a customer. (as such, this is TRULY my Master Source of SLM content) There is no other source of this content for SLM as the SLM only maintain record pointers to the content that was item-label synch'ed into SLM. SLM only knows of the object names in my magicbox. Nothing more. (As such, SLM current does not even have a copy or slave version of the master content in the Magicbox) So, this model has a VERY SHORT Data Path between my product builder storage locations in my inventory to the point where SLM uses it to distribute. 1 STEP. As such, to see what SLM can sell I can look in my magicbox. To update any SLM item sold by a listing is as simple and replacing the object with a newer version of the object with the same name. 1 STEP. To Delete the item... go into magicbox and delete the item and of course delete the listing in SLM or its orphaned. It also means that the content that is actually available for SLM to distribute is outside my inventory (unless I want a backup of the magicbox whereby 1 prim object gets placed in my personal inventory to backup my entire magicbox content. THE NEW DD METHOD (making guesses since me nor you know exactly how updating works): I STILL HAVE ... My personal inventory has a structure of selling product folders (for me generally 1 folder for every product I sell on inworld / SLM) that contains both my FINISHED BOXED SELLING ITEM as well as all the content in the box, photos, marketing content, demo items, older boxed versions, etc. related to this product). This folder structure in NO WAY resembles the content that would be uploaded via OUTBOX to SLM. NOT AT ALL. (as such, this cannot be considered my SLM Master Source) I now have an OUTBOX that - thanks to LL's incredible solution logic - does not contain ANY permanent SLM item content. Its simply a "fire and forget" transport of content that is dropped into it to the SLM Inventory. (As such, since it has no permanent data in it, it clearly cannot be a MASTER Source of the structure or content that is being maintained in the SLM) I now have a new SLM DD Store Inventory DB maintained by the central SLM system. Its outside of my access or control as a folder and can only be somehow viewed / possibly managed to some limited extent via the SLM Merchant website. Technically it would be the SLM Destination data repository since it received the content to sell from the OUTBOX "transport pipe". (As such, if I as a merchant am not creative, this will have to be my only MASTER Source of SLM content even though my management of it is limited) Since I am not a STUPID MERCHANT, and I realize the importance of maintaining a true MASTER source of the SLM content that is in full control by me... and because I see that in order to update my content in SLM in the future with reduced upload errors due to spelling mistakes or not realizing what content is or is not in the folders, I will have to now create a replacement of the MAGICBOX Master source folder in my Inventory to take on the function that the OUTBOX could have done. This new SLM MASTER MAGICBOX folder in my inventory will have all the SLM products in their folder structure that is being pushed up to SLM. (As Such, this will now be my TRUE Master Source of SLM content) Now with DD I will have to move my new or updated product from its builders folders to the appropriate MASTER MAGICBOX folder in my inventory. Then drag the updated folder or selling box, or item from this MASTER MAGICBOX folder into the OUTBOX SLM Transport pipe folder in my inventory. SLM will suck this content up into my SL Central store folder and delete the content in the outbox. Then - I hope - the updated content of that item will immediately be available then for distribution to the next customer that buys this product. I hope i dont have to go to the listing to inform the listing that this content has been updated. Additional Step. A lot more time to update. Still prone to potential errors since I could accidently drop content onto the outbox while I am doing unrelated inventory management. There Sassy. I Deduced. LL's model sucks and as you said, there is nothing we can do about it now since LL doesnt listen nor ever takes good advice and corrects a bad idea.

Sassy Romano wrote: Well as i've said before, the design is what it is, debate about it's design has limited value. If you spelt something wrong, you'll just end up with the same as you did if you uploaded a box called "sclpts" instead of "sculpts". It'll appear a product in your inventory that you re-associate with an existing listing. I'm not sure why that's seen as an issue? As to the re-association, it is out there and has been answered but you'll have to hunt for it LOL - see Sassy - there are answers to your "dilemmas" on how to create a better solution than what LL created. I was not debating or trying to convince you or LL that thier idea was poorly thought out and needs to be redone. We already know that 1) LL does not listen to its customers , 2) would never change their minds no matter how bad their idea was. It was just explaining yet another reason why the current OUTBOX Upload & Trash concept was bad. You just allowed me to give even more reasons us Merchants will have to deal with when using this model. As for your inability to provide me the link to the answers to my posed questions on how update works.... let me translate your response.... "actually LL didnt answer the questions but this is my inside knownledge as well as Wiser LL SCRIPTER skills providing educated guesses on how it works"

Zanara Zenovka wrote: The Magic Box scripts haven't been updated for years, and certainly not since the creation of SLM. You'd need LSL coders for that. Uhmmm I didnt think we could play around with the LL Magicbox Script. LSL coder or not, playing around with how the magicbox sends a "product has been delivered for order # xxx" would not be possible or I assume allowed. PS... I am not one of those "Smarter than the average Merchant LL SCRIPTERS" so even if tampering with the magicbox code were possible I surely would not be tinkering with this.

Sassy Romano wrote: Leaving aside the nirvana of what could be, I wonder what would happen if they had done this and then "forced" merchants to increase their inventory size by thousands of items. I seem to recall that most objected to such a method. Second and it's just a thought, I wonder how this might have worked had the Outbox with all it's subfolders and content failed to be displayed correctly locally and a merchant started making changes that no longer reflected the true folder hierarchy. At this point, what would have happened if the merchant chose "sync" or whatever process with a corrupt view of what the folder structure looked like? Given those situations, I can see why LL have done it like they have, at least the server side view in MP inventory page is what you have on MP and available in inventory. Figuring that the next step to replace something would be to just upload that item again where an item would be the whole folders worth and not just a component, then all you'd have to do would be the same action as the present state with a new item in a Magic Box. That is, re-associate the existing listing with the new uploaded item. This has been answered in one of the entries from CommerceTeamGroupMember Linden I wonder what would happen if they had done this and then "forced" merchants to increase their inventory size by thousands of items. Whaa? So Sassy, where do you think Merchant will get this content from that goes into the OUTBOX? From thin Air? The content of thousands of items are already in the inventory in some order (maybe in the similar or not similar structure as the magicbox is - for me its not). With the destruction of the Magicbox which is currently the absolute master source for SLM, I "WILL" be forced to create this new MASTER SOURCE within my inventory in an order that matches the folder structure that the SLM inventory knows it as. This solution will now be in addition to product content that is already in my inventory is an internal format (my product folders and all related marketing and build related objects for each product). So LL has not stopped anything on expanded inventory since this MASTER OUTBOX Source folder will pretty much be a mandatory in order to ensure it matches the folder structures used in SLM. But now I will have to keep it synched manually as opposed to the LL OUTBOX being the undeniable source of the SLM content in the SLM inventory. As Master source, I would know that whenever I changed content in the outbox, at some polling or trigger event the entire Master folder would be synched to my SLM. Please dont scare ppl by saying that synching a master to Destination will cause tons of traffic because you would be spreading FUD for something that is untrue. Modern Day synchs of even very large sources of data can take seconds if only a few items change. In our RL environment we master-destination synch 13,000+ folders with content every night and this normally take about 1 or 2 minutes if most of the content has not changed (i.e. a publishing model). You are right that the OUTBOX could possible look corrupted thanks to LL Asset Server screwups or some caching view on the viewer, but if you want to go into deeper solution design on this concept, I would have placed extra maintenance solution components in place on the SLM website for the Merchant... like... "VALIDATION CHECK OF MASTER TO SLM" to report to the Merchant a comparison report of whats in the Master OUTBOX to the SLM Inventory....or even another cool maintenance tool in the event that the Merchant accidently really did screw up the Master OUTBOX (i.e. deleting or polluting the Master by deleting things he didnt mean to delete or dropping content into the folder by accident) by allowing a REVERSE SYNCH of the SLM Store Inventory to the MASTER OUTBOX. Your argument on this can be used against you as well if the OUTBOX is corrupt and content that was already upload does not appear to be deleted and merchant takes action on what he thinks he sees. Now to go after your "its simple" and "its already been answered" on updates. So how simple is it if a Merchant wants to update a large or even simple folder structure and accidently spells the folder name wrong from what it was the first time it was load? SCULPTY MOUNTAINS PACK then accidently SCPY MOUNTAIN PAKC the second time. This folder structure has 100 items in it with subfolders. BOOM.... DD blindly uploads this incorrectly spelled content into SLM. The likelihood of this happening is MUCH GREATER than the fears you proposed with a master sych. Please provide a link to the FAQ or a clip of the LL answers to all my update question. I would like to read these answers. Seems I completely missed this.

Sassy Romano wrote: Magnet Homewood wrote: Different stuff in different boxes, good point, perhaps we will be allowed to have different folders within the main DD folder to replicate that? Who knows Why would you want this? on the Marketplace inventory view, you see all items and can search for product. Items are REMOVED from the DD outbox as explained in the FAQ. There will be no folders in the outbox to "manage". Sadly it seems this design limitation is true. LL did not think it was of any value to use a MASTER SOURCE model for the OUTBOX so all the folders you create to upload into the SLM Inventory DB gets deleted after upload, forcing you now to create yet another new OUTBOX in your inventory that will have to mimic what the OUTBOX would have looked like if it didnt delete all its content after upload. You will be forced to do this supposedly as a way to update your content on SLM. THIS has not been confirmed in the FAQs yet since LL keeps ignoring this question on exactly how do Merchants update their content of listed items. - How does a boxed or folder of content get updated if there is no need for versioning of the product? - How would 1 item in a folder structure of an item get updated if there is not need for versioning? - How would contents be updated if there is Versioning required? - If a new Version of the Product gets upload as I assume new content with a new name (Prod1 v1, Prod1 v2), then how does a merchant clean up the old content that is not needed anymore? Asked several times. Not answered. These answers would indicate how important it is for all merchants to now have to create their own DUPLICATE OUTBOX as a Master source to the SLM OUTBOX. Manual synchronisation which is prone to errors vs an automated synch that LL could have easily incorporated into the solution design. Ohh well.... I guess LL knows best how about our needs. No need to ask us Merchants.

A couple things to note on all these orders to my magicbox all night: ONE: With all these orders to my box entering and throughout the period that is supposed to be so bad that as the OP mentioned they get constant delivery failures every night, Zanara did not get ONE delivery failure to my magicbox the entire time. Yes there was a clearly noticed lag from ORder start to delivery but they all delivered. 100% TWO: An annoying observation which I never really took notice of until Zanara did all these test, LL could not be bothered to put a basic piece of information in the email Delivery Confirmations sent out..... THE ORDER # that was successfully delivered to the customer! Look at my emailed order delivery confirmation below. See something missing? BTW, this is the only place in LL SLM where the delivery details are provided since the SLM transation & order logs do not report the time the order was actually delivered to the customer. The object 'Xstreet SL Magic Box v3.0.11' has sent you a message from Second Life:Xstreet SL - Delivered item Heart-Overhead-Gusher. = Xstreet SL Magic Box v3.0.11 is owned by Toysoldier Thor = http://slurl.com/secondlife/Grojnowski/64/3/91

I saw your TX from my offline IM notification : Date: Tue, 15 Nov 2011 11:15 AM Sales ConfirmationDear Toysoldier Thor,Order ID: 1284235836Purchased By: Zanara ZenovkaLine Item 1: Heart Love accessory - Overhead Gusher VALENTINE SPECIALDelivered to: Zanara ZenovkaListing URL: Delivered Quantity: 1 of 1Purchased on: November 15, 2011 11:15 am PSTBuyer's Price (for delivered items): L$10Distributions Total (for delivered items): L$0Marketplace Commission (for delivered items): L$1Your Earnings (for delivered items): L$9Your Total Earnings (for delivered items): L$9 Delivery Confirmation: Date: Tue, 15 Nov 2011 11:15 AM The object 'Xstreet SL Magic Box v3.0.11' has sent you a message from Second Life:Xstreet SL - Delivered item Heart-Overhead-Gusher.

I saw a few purchases in the past hour from my store. The 3 that I saw processed were 1 minute, 22 minutes, 2 minutes respectively. The 22 minute TX was my one free Demo Pack. My exepensive items were the 1 and 2 minute TXs. So not consistent by far but also and more importantly... NOT FAILED. I was not the one buying the items but I can say that the 1 and 22 minute TXs were from the same customer who first bought my Demo pack and while it took 22 minutes for it to be delivered she bought one of my products from the demo pack which was delivered in 1 minute. So the delay had to be from the system side and not because she logged out. It would be nice if all transactions were instant from SLM but in my opinion most seasoned SLM Customers have got used to the fact that buying on SLM always runs the risk of a very slow delivery. What I dont like is the FAILED delivery.

All that being said... I still Luv ya

Sassy Romano wrote: Well for starters I never used the word "fear" in any part of my post. Reasons why inactive merchants still have boxes inworld include "they're dead but paid a year in advance". Or, they have a box on a friends parcel. Friend pops in once every 6 months and says "Hi" so they're assumed to be "active" and hey, it's only 1 prim. Here's an alternate suggestion then, any merchant that fails to respond to a notecard/IM within 3 days has their items delisted . If there are so few really inactive merchants, how come there are so many reports of merchants that never respond to either IM AND notecard? All i'm suggesting is that listings be automatically active for only a set time1 month, 3 months whatever and after that they're auto delisted. Any true active merchant would have no issue with logging in, choosing "reactivate listings" and log out. If it was as easy as this, i'd propose once a week. Maybe because there are a lot of customers that run into Merchants that are Active SLM merchants but poor customer service Merchants. So you are basing your count of inactive merchants by how many people on the forums complain that a Merchant doesnt get back to them?? lol Is your next objective to filter out all Merchants that are active neglectful merchants? If there are Merchants inworld or on SLM that are in scenarios that keeps their SL business alive by heartbeat keep-alive triggers and events (like only coming in to pay tiers) then you are really not going to stop them in SLM by putting in SLM based quarterly manditory keep-alive checkpoints. They clearly are taking actions to stay alive now - why would they not make a point of keeping their SLM items alive the same way? You are trying to solve a problem that the NEGLECTFUL Merchant will simply abide by. The Merchants that truly are gone and have never come back are not an issue like I have already explained. Al you are trying to promote is to get LL Commerce to put their efforts into a function / feature that serves little value and only increases the risk that LL will screw up SLM for all the active GOOD merchants. You know as well as I do - if there is a way that LL can screw up coding and functionality to hurt us... THEY WILL FIND A WAY. Best solution for this issue... DO NOTHING!

ok zanara and darrius, do me a fave.... perform 3 buys within the mext 6 hours - during business hours - including at about 5pm to 10pm SLT as I suspect that is when the largest population of SL residents are active (North American evening). That will be telling.

But Sassy, your missing the point regarding your proposed options... Since when the DD goes live the current MagicBox will not be disabled (i.e. for ACTIVE merchants like me that will avoid DD until LL Commerce decides to technically shut magicbox functionality off) for several months after, there is NO MIGRATIONS TO DD at this time. DD's deployment will not change my functionality one bit. I do not have to even migrate. So now Fast Forward to June 2012 when LL Commerce decides to shut off Magicbox functionality. Assuming the worst case scenario that LL will not be synching current SLM Magicbox items into this new DD SLM inventory DB, when LL shuts off the magicbox distribution, those merchants that are not active and dont cut over will still have active listings in SLM but these listings will be broken when a customer tries to buy an item from it. So based on your fear that SLM is loaded with massive piles of inactive merchants and their items, they will still be in the SLM but simply broken. They will still show up in search - which is another one of your fears that this is somehow hurting your SLM business (not my fear). BUTTTTTTTT... I will say it again, if your fear is that there are so many inactive merchants (those that have left / abandoned SL long time ago) with their unsupported rogue SLM listings, how is that possible if in most cases these departed Merchants likely have magicboxes that have long since been derezzed as well? Please explain to me how you and others are so concerned about SLM items from abandoned Merchants. Their magicboxes should have also POOFED along with them since they were not around to pay the tier or rent of the land that their magicbox was on. The reason I am making this point is this and I know you read my capped phrases more clearly ... LETS NOT GIVE LL COMMERCE ANY IDEAS THAT REQUIRE MORE SOLUTION LOGISTICS CODING INTO SLM !! We all know how horrid LL Commerce is with developing solutions and making a simply idea turn into a screwed up mess of poorly thought out bug-ridden solution coding. Your proposed LL-developed cure for inactive SLM listings will likely be more painful than the little impact that these listings currently have on SLM. LEAVE SLEEPING DOGS LAY.

Magnet Homewood wrote: I agree, there must be some kind of system in place to check whether a merchant is still active. Sometimes I have seen something on the marketplace and wanted to know more, so I contacted the merchant selling it in-world to find out. Some of these IMs have gone unanswered, although the listing is there forever. I really don't think making a merchant log into SL, let's say every 3 months or so, hell, make it every 6 months, would be a problem, and it would clear the marketplace of listing that simply are not backed by merchant support. I think with DD as was the case with Xstreet to SLM last year, the issue again will be how to get a notice out to the ~70,000 that are on SLM but do not spend ANY time on the forums to keep aware of LL's upcoming changes. I have even talked to a couple SLM Merchants and one of them had no clue what Direct Delivery was much less that it is only a couple months from going live. Heck, if even us Forum Rats cant get LL Commerce to talk about Direct Delivery except for the rare obscure blog posting or WIKI, how will the vast majority of ACTIVE LIVE Merchants of SLM keep in the know? As for dead items being filtered out during the migration to DD, I think a lot of you might be wishful thinking again if you believe that DD will clense SLM of inactive Merchant items. It pretty much didnt happen when LL converted us over from one entire system to another (xstreet to SLM). Why would any of you believe that a cutover from Magicbox to DD will accomplish this? IF (this is a big IF) LL does a good job of making the transition smooth for all us SLM Merchants, then when DD goes live, it should not impact ANY LISTINGS on SLM. So those SL Merchants that have become inactive and left SL - their listings will still be up and their items in theory should still be delivered from the Magicbox. IF in the summer of 2012 LL decides to disable magicbox functionality, then YES the delivery will break but the listin in SLM will still be running. So now we got even a bigger mess since in theory we have these so-called countless listings from inactive merchants that that are still live but their delivery is broken. The reason I say IN THEORY is because contrary to all your fears that SLM is selling items from Merchants that may have abandoned Secondlife, ask yourself this question... for the most part, if you were one of these Merchants that left SecondLife and you HAD TO HAVE A MAGICBOX rezzed somewhere (likely you rented or owned land), do you think that the MagicBox would not have already been De-Rezzed for failed payment on the land? Yeah I know some of you will say that some merchants place their magicbox on lands they do not own and the box might have gone rogue / forgotten, but this would be an uncommon scenario. I truly think many of you are making a mountain out of a molehill on the number of abandoned SLM listings from inactive Merchants. If you want to lose sleep about something regarding SLM, the amount of cluttered abandoned listings should not be one of them. Be more afraid of LL Commerce's ability to properly deliver DD without any serious impacts to ALL OUR SLM BUSINESS OPERATIONS. That is what you all should be much more fearful of.

Well then here is a theory on why sales deliveries are slowest between 1am and 5am every day.... With LL's revenue base receding faster than the bay of fundy's tide, maybe LL Sr. Management instituted major cost saving measures, including turning half their Data Center off along with all the lights in the unused offices and bathrooms. Or for efficiency sake they got their clustered servers on one of those manual timers and it shuts them off at 1am and turns them back on at 5am. Its a thought

hmm then I guess I am just always very lucky. Unfortunately when problem solving - I dont believe in conicidence or luck. So the question then is, what is different for merchants like me that experience near-zero delivery delays and many of you that are noticing tons of daily cyclical failures - specially between 1am and 5am? So Darrius, do you see a major spike of SLM delivery failures between 1am and 5am? If your theory is correct and its not the magicbox / sim related lag at this time each day but rather something moreso related to how the "outdated communications protocol" is being lagged into the LL systems, then You and Me should be seeing this same issue. I dont. Do you?

Sybil Hallison wrote: As a customer and as a merchant I have noticed a problem with deliveries around 1am-5am (SL time). Since I m on an entirely different timezone I make most of my purchases during that time and also I can watch the activity of my deliveries live. So I noticed that during prime time (around 6-10pm SL time) while my orders go up, as expected, the deliveries are instant. But after midnight, till morning and while the order count goes down, the average delivery time gets to 1-2 hours! And during that period I have multiple failed deliveries. Recently I have placed a second magic box in case it was a region / lag problem, but nothing changed. Anyone else has this problem? I m thinking that maybe its not just me and it has to do with some maintenance or some internal problem during these hours. Any ideas? I would suspect its not a central SLM DB Maintenance related issue or one that might involve a degrade of performance within the LL SLM server environment. If that were the case all Merchants would be seeing this consistent cycle of failed deliveries each day at that time window. I rarely get any failed deliveries regardless of time. In any given month I might get 1 or 2 failed deliveries, unless its a month when LL is playing with production code without tellinig us and I will see a few days of spiked delivery failures. This has not happened since August for me. To add to your confusion, my ONE magicbox is located in my store on what is commonly known to be a laggy mainland sim parcel of land. Yet my deliveries are nearly 100%. The consistent timing might be more related to activities happening on the sim/parcel of land where you locate the magicbox. What you might think is unrelated events may actually not be. Example: Are your magicboxes on a mainland sim where another land renter / parcel owner is a major rock club that has major nightly events every night at this time? Is there a timed script or some other activities on your land or the sim that is lagging out the sim at only this time? Are both your magicboxes on the same parcel of land? Another factor to look at which has been well known to cause delivery failures and delays is Shopping Cart purchases where your product is being bought with other merchant products. The problem with this theory is that this root cause would not be timeboxed to a certain part of every day only. So I would dismiss this theory. Try moving your magicbox to a completely different sim. Do you have a friend with a quiet private sim that you could land your box on for a month to see how it behaves? Again, if it was a LL central maintenance related issue then we all would have noticed this heavy delay/failure rate in this specific window. I know I havent.

Madeliefste Oh wrote: ... What do Second Life businesses earn per month? 2007 2010 Less then 10 usd 54,37 % 56,7 % 10 – 50 usd 27,1% 26,81 % 50 – 100 usd 6,33 % 12,43 % 100 – 200 usd 4,79 % 3,97 % 200 – 500 usd 3,96 % 3,63 % 500 - 1000 usd 1,51 % 1,61 % 1000 – 2000 usd 0,99 % 0,84 % 2000 – 5000 usd 0,64 % 0,54 % More then 5000 usd 0,31 % 0,3% 2007: total 42.597 businesses 2010: total 64.651 businesses Made, I wanted to know what percentage my lil SLM / inworld business was in as part of the 2010 figures you provided (I am in the $200 - $500 US/month) range. The problem is that when you add up the percents on your 2010, the result is 106.83% - not 100%. One of the figures in the chart must be wrong. I saw a version of this 2010 chart about 8 months ago and even then I was shocked that my really small SLM store (ie. 6 primary selling products and about 40 smaller odds and ends products) with very low annual new products coming to market from me (I havent added a new product in my store in over a year) still puts my monthly sales in SL's top ~ 7% of monthly earnings among merchants. Earnings = Profits and not Revenue = Raw Sales. Seems a bit shocking when I know a lot of other merchants slave away on their store/SLM every week putting out tons of new products each month with FAR LARGER product inventory on the market than me. Seems weird.

and who do you think ... or how many of the 100's of thousands of SL residents came onto SL AFTER reading SL forums? Let me guess a percent for you.... 0%

Darrius Gothly wrote: ROFL!! Seriously Poenald .. put down the Jolt Cola and step away from the keyboard. A couple guys with a nice new white coat will be over to help you shortly. LOL!! whew.... and here I thought I just did not have enough coffee while I was reading her post this morning. As I read the posting the words blurred into oblivion in my mind (like when you watch Television and start nodding off and the content fades to white noise in your mind). /ME goes back to the love triangle and sucking my thumb rocking back and forth perpetually. PS: When I tried to post this message the LL forum filter engine blocked the posting for using the phrase "Watch T.V." in the body (without the periods) which it said is not permitted. WHAA???

Rya Nitely wrote: Sassy Romano wrote: Toysoldier Thor wrote: sure hope you are right. You know it, my little Toyboy love machine *winks* :matte-motes-sick: vomits Sassy... I am getting a strong indication our love triangle (or square) is one that is to be shunned, rejected and denied by the community.

What I want to know from a Linden with knowledge of the background of this half-baked solution are the details as to WHY a LL Developer thought using the Display Name was a great idea? What was the logic behind this terrible idea that was deployed? Was it truly an unexpected side-effect of fixing another bug? How did fixing this other big impact the way the transaction history data changed to capture another field of data? What was the background how DISPLAY NAME was even a factor at all? Brooke, please dont treat us as sheltered children. WHY was LL Commerce & Development fiddling around with DISPLAY NAME at all when working with any systems that track transaction, history, tracking, ecommerce at all ?? What worries all us Merchants is the UNKNOWN BACKGROUND from this utterly stupid change that caused LL to respond to this JIRA so quickly. What worries us Brooke is that you and your team actually have thoughts of using Display Name as part of up-coming systems changes - like DD. Please speak up clearly and openly about the background of DISPLAY NAME and confirm with the Merchant Community that you and your team have NO INTENTION TO USE DISPLAY NAME ANYWHERE INVOLVING CRITICAL FINANCIAL ACCOUNTNG SYSTEMS. I cannot believe if LL's Commerce and Development Team is this junior and out of touch on how financial systems work to consider using a NickName as part of anything involving financial tracking. Make us feel better by explaining how this was a purely unexpected human error and Display Name was not supposed to be anywhere involved in the root cause fix to this recent bug.