Toysoldier Thor

Flea, you say in your posting that you dont think that LL is taking or keeping the money, but yo uhave read the same postings from your fellow merchants that have 100% proof that an MP customer received the merchants item and they PAID LL for purchase. So if the customer paid LL MP the full price for the item they received (their money is gone from their account) and the merchant not only did not receive the $ but wasnt even aware of the transaction.... who do you think has the $ that LL took? Did the $ float away to the ether? The money is in the control of LL still. They must have it. As fro your proof that MB's have experienced this same problem.... post all your proof to the JIRA that was just created and shows 100% prrof that the merchant WAS NOT PAID for the item a customer received and paid for. If your proof is in the hands of a friend merchant... get them to post this. Lets see this evidence that a MB has the same problem. As for Brooke and Dakota actually chiming on on this issue..... WHERE WHEN? How did I miss them actually speaking to us about any issue - much less this one? Provide me the URL to where Brooke & Dakota stated that LL MP has been stealing $ from hidden sales that kept the merchant out of the loop of the transaction? I would love to read that Brooke has been aware of LL's MP sales transactions not paying the merchant for sales for quite some time. And all this time we were not aware of this and LL has not done anything to address this ASAP??? WOW!

Rival Destiny wrote: Toysoldier Thor wrote: So this is a general comment and question moreso directed to Rodvik, LL Senior Management, and the LL Commerce Team as their DD deployment continues to be riddled with serious and sporadic problems that are calling into question the overall health, stability, and trustworthiness of the entire SL Marketplace. Since DD's deployment, many of the problems in MP related to DD have not been resolved, new reports of corrupted listings keep showing up in the forums, and now the most serious and scary issue of LL's new DD executing sales transactions where the product is delivered and LL has actually collected the $ from the sale and all without the Merchants being aware their product was given away to the customer by LL. THIS IS SERIOUS LL ! This latest problem goes to the heart of LL's MP not being a trustworthy ecommerce system. The fact that LL is aware of the problem and not even communicating anything nor taking any known action is akin to theft. So LL.... as Rome burns (aka MP is on flames in many places thanks to your poorly architected and poorly tested DD deployment) when will you feel it appropriate to provide the Merchants that your MP system is screwing some public announcement of what is going? When will you provide us some details of how you will stop these serious flaws or at least put in a Delivery Notification into the DD so that we can more easily detect when MP has executed a sale with the merchant being paid? Will LL push back the deadline for MB retirement until DD functionality has been proven to be 100% THE MERCHANTS & CUSTOMERS OF MARKETPLACE DESERVE TO BE TREATED BETTER THAN THIS! At least have the decency to communicating to your Merchants if you can't solve it. We at least deserve that. How do we find out if this has occured on our MP stores? And just to be clear ... you mean the product is delivered to the customer and LL collects their % (or the price of the item?) and the merchant receives no $$?? And on another note, I see quite a few 'delivery partially failed' in my store sales records. Now these notes are on individual products. How can the delivery of a single product partially fail? Does this mean the customer didn't recieve the goods and the goods are stuck in limbo somewhere??? Not exactly Rival.... what has been noticed by some merchants these past few days is that the customer makes a purchase on MP, they receive the product from the Merchant's store in MP, LL collects the entire price of the item, but LL does not give any of the purchase price to the merchant nor is the Merchant even aware the transaction has taken place. The only reason it has been detected is because some merchants have had customers go to them about a purchase that the merchant did not have recorded as a sale, OR some merchants have a Delivery Script in their MP items that emails them when the customer rezzed the item after purchase, or a friend was the customer and the transaction was mentioned and the merchant confirmed that there was no sale reported to them nor any $ from the sale provided to them from LL's MP.

AWESOME... that is a great jira - very clear and images for added evidence. Great job.

Since January 1st of this year - of all my order - I have only recorded 4 ABORTED orders. - Two of them were on January 16th and 19th. (obviously they were MB orders). - Then TODAY I had two of them from the same customer of the same product which was a DD product. The details from the Aborted Orders today (as well as those two back in January)say "NOT AVAILABLE FOR DELIVERY" and Not Delivered - not paid. Of the 4 aborted orders - 3 of the 4 were the same item - my Free Demo Pack (which is now a DD item). Before anyone asks, this item succeeded delivery 2 times after the 2 aborts today and it succeeded countless time before today's 2 aborts.

So this is a general comment and question moreso directed to Rodvik, LL Senior Management, and the LL Commerce Team as their DD deployment continues to be riddled with serious and sporadic problems that are calling into question the overall health, stability, and trustworthiness of the entire SL Marketplace. Since DD's deployment, many of the problems in MP related to DD have not been resolved, new reports of corrupted listings keep showing up in the forums, and now the most serious and scary issue of LL's new DD executing sales transactions where the product is delivered and LL has actually collected the $ from the sale and all without the Merchants being aware their product was given away to the customer by LL. THIS IS SERIOUS LL ! This latest problem goes to the heart of LL's MP not being a trustworthy ecommerce system. The fact that LL is aware of the problem and not even communicating anything nor taking any known action is akin to theft. So LL.... as Rome burns (aka MP is on flames in many places thanks to your poorly architected and poorly tested DD deployment) when will you feel it appropriate to provide the Merchants that your MP system is screwing some public announcement of what is going? When will you provide us some details of how you will stop these serious flaws or at least put in a Delivery Notification into the DD so that we can more easily detect when MP has executed a sale with the merchant being paid? Will LL push back the deadline for MB retirement until DD functionality has been proven to be 100% THE MERCHANTS & CUSTOMERS OF MARKETPLACE DESERVE TO BE TREATED BETTER THAN THIS! At least have the decency to communicating to your Merchants if you can't solve it. We at least deserve that.

Flea Yatsenko wrote: I have a few of these today as well. My guess is that it's a new thing that's trying to deal with all of the awful things that are happening with SLMP. My most pessimistic guess is that it's a new bug that's cropped up and "aborted" has existed for a while, but things have finally exploded to the point where we get to see an illusive new error message. My most optimistic guess is that it's a new way of handling transactions that would normally fail (like give your product away for free). Maybe, and just maybe, LL is realizing that it's important to verify and have all parts of the system acknowledge each other so things don't malfunction and do things like give products away for free. The fact that merchants are starting to realize that things have been getting given away for free and that Magic Boxes have been silently failing and delivering products probably has LL putting something like that as a top priority. If a Linden came out and admitted that was happening, the rage and anger that would take over on this forum and with content creators would be large enough to seriously cause issues. Of course, all of this is conjecture. Take it as you like. If it helps, a customer purchased an item and it failed and they gave up, and another went to order two builders kits, one worked, and the other was aborted twice. It only shows up as "aborted" in orders->transaction history, Order history just shows it as undelivered. Flea.... why do you keep saying that MB has been giving away free items without sales transactions silently? Do you have evidence of this? I do not believe your claim unless you have evidence. Merchant over the past week have been noticing DD sales transactions have been executing without the Merchant's knowledge or receipt of payment... NOT because DD was somehow hinting of this corruption... it was because of the Merchant's diligence in catching the DD flaw. The same flaw would have surely been caught by merchants long time ago regarding MB if it was happening. So unless you can prove otherwise, I dont think we should inject this theory as fact. I have both MB and DD items - my top sellers are all on MB and all my other items are on DD. The nice thing at least about MB that DD does not have is a Delivery email notice. DD has ZERO delivery notice built into the new system. So... I am very very confused why you believe that MB has secretly been failing sales transactions all these months / years without any merchants noticing? Did I miss something?

Seleena Pherala wrote: Well, I had the same problem: some of my items were sold, but I was not payed. And it is a completely different problem then the one discribed in the "related thread" (where some items were delivered to the customers, but the merchant received a "undelivered"-message and was not payed). In my case the following happend: a girl bought one of my items, and was charged for it. She received and reviewed (!) the product. When reading the review, I became suspicious, because I knew exactly, that this customer did not appear in my transaction history (it was a friend of mine, who was visiting me a couple of times when I was building the item). So I contacted my friend and she gave me the (8-digits-) order-number she found in her order history!! As you all know, order-numbers normaly have 10 digits now. This specific order definitely didnt appear in my transaction history (not as a delivered, and not as an undelivered item) and I didnt receive the money for this transaction either. Then I checked the reports of the "orders"... and there I found this transaction!! Im not sure at all, but I think, that merchants are not payed for delivered items with a 8-digit-order-number. I have no idea, why such order-numbers occur, or why merchants are not payed for these transactions. If you want to know, if you are affected by this problem aswell, then you should probably search the orders-report (and not the transaction-history) for 8-digits-order-numbers. P.S.: I hope my message is understandable, and Im sorry for any mistakes, but Im not a native english speaker... Did you submit all this information into the JIRA or create a new JIRA? This is 100% evidence of the MP sales handling system failing and a possible root cause. If you havent yet - please do this and provide all the details on the transaction number to them.

Arwen Serpente wrote: Very very interesting development: All, and I mean all the orders that were stuck in "Queued" are now marked "Aborted". Somebody's reading what we are writing. So now, I have no idea if these customers got the items, and the money went to LL not me, or if the transactions were truly cancelled. Does anyone know how an order becomes "Aborted"? LL could be secretly reading these posts and / or it could be my Twitter posts this morning to @secondlife and @rodvik slamming their handling of all these issues with a link to the thread might also perked their attention. a lot of LL staff and SL residents have @secondlife on their twitter follow.

we dont have any stats from LL but I suspect that the massive surge of migrations happened in the first week after LL released the DD mess. In fact the surge was so great that it was suspected this was part of the initial corruptions of the DB and the huge MP lag. I dont think the MB deadline - whenever this will be - will be that big an onslaught like the first week was. I am still hoping that LL will come forward and admit they dont have the DD mess under control and that MB will not be retired for another several months as they work out the bugs.

its an option. The script that actually does this is very simple and was posted. I wrote my own that adds a few more bells and whistles - like it does an inventory check and sends that to me as part of the delivery email - that way not only do i see where it was rezzed, by whomm, who was the creator of the item... but also the inventory of content so that if a customer says there was something missing in the pack i can see if this was true. BUT... i am nervous about deploying it for all my packs because once these scripted packs sell... i cant stop them from notifying me in the months / years to come since I sell full-perms builders boxes.

Note in the other thread that the ON REZ scripts that was offered are good to help you notice that a MP customer bought and rezzed your item without MP notifying or paying you.... but there are some limits to this check. If you have items that are COPY or Full Perm... then even if the script deletes itself from the box - the next rez of the item from inventory will have the script again. So... you could start getting a larger and larger problem of email notifications from 10s or 100's of customers every time they rez your time for use. Its all talked about in the other thread.

this latest disasterous problem has already been talked about in another recent thread.... Related Thread In this thread we were all talking about how to place ONREZ scripts in all your listings to know that a sale was made in MP without the merchant being notified. LL is collecting the sale but MP at times decides not to notify or pay the merchant for the sale. Since LL in their wisdom believed their DD solution was so good - they refused to place a DELIVERY NOTIFICATION into the new DD (unlike MB where we were told of the sale and the delivery). MP is messed up in so many ways thanks to LL's DD deployment - this is just another one and a SERIOUS one. Now MP is unstable and unreliable.

PS - I am glad that I have not moved my 6 highest selling MP listings to DD yet. My concern is that LL has all these problems and as of yet - they still have not announced that MB retirement has been pushed back until further notice.

That is terrible to see the long list of troubles. And Arwen, when you list and mention them in the forums and how unstable and frustrating it has been for you, then that means a lot since you are always known to be a level-headed poster in the forums. So Brooke and company still have no resolution to the DD Fiasco. The great magical new DD that her and LL promoted all of 2011 and into this year as the SAVIOR to all those MP delivery woes that LL loved to dump on on MB (and brain washed so many Merchants to join the bandwagon on how evil MB's were that it had to be a priority to get rid of MB at all cost). In addition to that, Brooke Linden last August at the annual SLCC conference stood up and stated very clearly at one of the sessions how DD was so important and that LL will not rush the migration to DD until DD had been completely tested. I wish I could remember her exact statement but it was basically to paraphrase she said "because DD involves the handling of financial transaction, we must get this right before we release it". And yet here we are.... over a month since LL released DD. All the problems that you mentioned Arwen are still running rampent within DD and its clear that LL's development staff have opened up pandora's box since they cant UNDO DD and they cant FIX DD. So MP is now left as as un unstable , unreliable, listing & money-stealing system that LL cant seem to fix. And as the MP Rome burns.... how much have we heard from Brooke and the Commerce Team on ANY status of their ability to fix these serious problems and what their action plan is? NOTHING! In fact, you would think the least LL would do after causing all this damage and lost trust in MP is to have Brooke or someone with LL authority make a statement that says: "in light of all the on-going unresolvable issues with DD, we have decided that MB will not be retired until at least end of year. We will review this retirement of MB deadline again as we approach this deadline. We will ONLY retire MB when we are 100% sure that we have finally fixed all the bugs in DD that are plaguing MP". But in the common immature and irresponsible ways that LL and the Commerce Team always handles their operations and customer relationship management..... all we have heard from LL regarding this serious on-going issue is... CRICKETS! No one from Rodvik down clearly cares that the Commerce Team continues to destroy MP's reputation and usability.

So ANS is as blind to flaws and bugs within the triggered sales transaction as any thing else we could potentially use to validate if LL's MP is honest and working properly or gone rogue and arbitrarily stealing sales from us merchants? Since ANS is not triggered until after payment is received by the Merchant... the situations we are seeing here where the sale happened, the customer got his content... LL collect the $L for the sale... and LL does not pay the 95% to the Merchant would could still happen in DD without ANS's knowledge. The benefit with MB over DD is that at least with MB (which my top listings are still using) LL had a Product Delivery Notication component within the sales transaction. I believe this notification whas spawned by the script in the MB (independent from the backend sales proecessing). As such, when someone buys one of my landscape packs, i still get both a SALE TRANSACTION email and a PRODUCT WAS DELIVERED email. With DD, LL in their wisdom decided us Merchants didnt need this Delivery Notice. Now this may not have been any value anyway for DD (unlike MB) since the DD function is part of the backend LL systems and as such the delivery notice would be of limited value when LL screws up the sales transaction. GAWD.... i wish LL would simple leave both DD and MB in place permanently (like Brooke promised the TPV developer las year).

I should clarify by "better alternative". I mean an alternative where we can tap in closer to the initiation of a purchase and where we could control the monitoring. A scripted prim that emails me is a brute force method with a bunch of flaws - as mentioned in previous posts. Something more elegant, relevent, and flexible (ability to deploy, enable and disable).

Sassy, you are in tune with LL's flawed sales transaction system and how DD works in MP. AND you are a smart programmer too. As such, is there a better alternative to a scripted on a REZZED prim for us to consider where we Merchants can tap into and place a triggered control point? Remembering that the alternative would have to take into account that it should be independant to LL's flawed disjointed MP sales transaction / delivery architecture as well as their screw-ups in development that would make this weak architecture impact us. What ideas might you have?

PeterCanessa Oh wrote: In case anyone does not know how to do this, here is a script that will send you an email the first time an object is rezzed and then delete itself. There are loopholes - notably, if you send something with copy perms its a copy that will be rezzed, every time, so a new copy of the script will be rezzed too and you'll be told about every single time something is rezzed. Could be a LOT of messages! default{ on_rez(integer StartParam){ llEmail("***your email address here***", "Object Rezzed Report", "Your object '" + llGetObjectName() + "' has been rezzed by " + llKey2Name(llGetOwner())); llRemoveInventory(llGetScriptName()); }} LOL Too funny. So I havent written a LSL script in about 1.5 years so last night I was rusty but after about 3 - 4 hours of figuring out some basics of what I wanted the script to do and coding different ways of doing it and debugging the syntax, I finally got it working! and although mine is a little bit more structured and does a couple more things (like get the details of the ITEM's owner and Creator and how many invoentory items are in the boxs that was rezzed), Peter's few lines does pretty much EXACTLY what mine does - even used the same concepts and functions. It works great. I guess I should have just waited 24hrs to let Peter tell me how to do it. But now the next bit of an issue as Peter mentioned. Since the fully perms builders prim box is basically pulled out of inventory whenever my customer wants to build with my landscape sculpties.... deleting the script has no value since the next rezzed builders box will have the script again. It wont be a one-timer. This may not be a HUGE problem as this script could become a EULA monitoring tool as I can see if the owner of the rezzed pack has ever bought my pack. If not - it has been given to him outside of EULA agreement by a customer of mine - directly or indirectly. BUT the related problem is that once the several of my items with this script gets out there - there is no easy way to stop them. I would have to hunt them all down and ask the customer to use a new nonn-script box. The other issue which we all knew already but it a limitation to this only sales validation script is that it only triggers when the customer actually rezzes the box. He might buy my builders box and not rez it for days or weeks. Unfortunately - there is no time closer to the actual untrusted LL MP sale transaction where a Merchant can insert monitoring / trigger of the execution of a sale that happened in MP. Unlike an inworld sale where we could place a script in the vendor and we are actually in full control of the initiation of the sale, in MP we have no direct TRUSTED control. When LL's MP sales transaction system screws up and we seem to be getting screwed by flawed MP sales systems, we simply have to use limited methods like ONREZ to show evidence that a sale has happened. The worst part of this is that LL closed a related JIRA to this very serious problem and LL is not saynig a word how their MP sales transaction system is proving to be stealing sales $ from us merrchants. This is serious LL.

Pamela Galli wrote: I have started using rez scripts -- not in the box but in the item inside the box. And guess what I discovered? Quite often people who say they did not receive something -- have already rezzed it! And then when they claim, Oh I meant I just received an empty box! I tell them the rez notice was for the box contents not the box. And then I ban and mute. Hmmm thanks for this posting. That gives me more ideas for my new script. Considering some might even say that. The new in-box script can actually post a message to the new customer of my landscape pack "Welcome to xxx! Delivery of your new pack has been confirmed with the Merchant. I hope you enjoy the pack. If you have any further questions on this pack please contact me immediately". That way they know I was notified of their successful product delivery and it gives me a chance to offer them any assistance if they so need some.

Darrius Gothly wrote: Thank you Griffin. I went and smeared my blazing intelligents all over that thread. *snickers* When I looked at your initial post and the screen shot, I do not know anything about ANS or how it operates, but the frist thing I noticed is that the URL listed had no top level domain. I just assumed that ANS has some way of working with internal host names only (i.e. you are somehow connecting into LL's internal nework and can avoid a top level domain). So I didnt post anything.

Kylie Jaxxon wrote: mtwtfss71 wrote: I found a couple of on rez scripts on the marketplace that will alert you either through IM or email. The only problem is that in order to use them, I need to go back in and rebox everything I put in folders to port over to DD. [insert rant here.] Can you just do it for a couple of your big selling items... Sadly for this confirmed delivery to work, the script will have to be in each MP selling item's content. But if you have 100's of these items then just place it into your hottest sellers. Since these sell with enough volume, they could be your "canary in a coal mine" If you are seeing deliveries with no respective sale transaction from MP then you can safely suspect the problem is happening to your other items. As for the ease of placing this script into MP items .... I guess MB has proven to be yet another advantage over the new DD... since my top sellers are still on MB - I can insert this new script into them much more easily than DD. just update the item inworld and delete the old item of the same name from my MB and add the new one. This is done safely - knowing that no LL / MP / DD backend system had to get involved. I suspect there are Confirmed Delivery Receipt scripts already available for purchase... but I still might build my own so i can get it to do exactly what I want (record and send to me the owner that 1st rezzed the item, when, where AND heck I could even record the first owner onto a config file and if the owner changes on a subsequent rez - i could even post a message to the person rezzing that "this pack is being rezzed by someone other than the original owner of the pack which is in violation of the EULA" (I sell full perm landscape packs to landscapers and builders). Just some thoughts.

This is a real scary situation for MP/DD if transactions are happening on MP with LL's system receving payment from a customer for our content and giving the customer our content but keeping the Merchant completely out of the transaction loop. Since with all the technical glitches that have been proven to exist with DD and the MP internal systems... I am now seriously considering the insertion of this PRODUCT RECEIVED script into all my products (at least my high value products I sell on MP). Even if this problem being reported here ends up not directly impacting me now - it could in the future. AND, with DD removing the ITEM DELIEVERED merchant notification that the MB system had, putting a "PRODUCT RECEIVED" script into my MP products would be a way to return this valuable function that MB has/had. I think I am going to write this script this week and test it and put it into place. My thinking is that it would be a script that would trigger on-rez... send me a notecard or IM or email ... and then disable itself somehow after first rez. Me has to think this through but it sure seems to be needed. thankfully I have not yet migrated my 6 most valuable MP items/listing to DD from MB.

Hi Annie, A few thoughts on your OP.... As has already been questioned as potentially yoru bigger issue which you now seem to have confirmed it will be the bigger issue.... the existing script in the vendor that you are using - you said is NO MOD. Even though you own the vendor - I am guessing you are not the creator of the vendor and its script logic inside. As such, any changes to the function of the vending script that you desire to integrate into the vending service (including its knowledge of what price to charge the customer) is not possible by you nor any custom scripter. Getting a new scripter to develop your additional promo function will not provide much value as he/she cant modify the main vending functions - which he/she would need to do to adjust pricing based on promo code logic. So, the only solution would likely be a new vending system that has your promo system built into it. The only thing you could do now by using your existing code is to go back to the creator of the current vending code and ask him/her to customize what you want. . . Assuming you COULD integrate this promo code and listening to what your primary objective is - if I understood you correctly that you want "to reward customers that go to your blog or follow your tweets" - I would take a different approach to reward visitors to your twitter/blog AND to increase traffic to these sites.... What I would ask for is a PROMO system that when the purchase is being made, the promo system / vendor prompts the customer "please tell me the code that is currently on our website right now - to find the current code go to the following URL link and look for XXX". If they have already done so, before buying then they will simply type it in. If they had not actually visited your website and/or were not even aware of your website, this prompt will encourage them to go to your web page immediately to get the code. Many of them may just go there to get the code and then close the page. BUT... since your objective is to get your page/site known, a percent of them will actually become interested in what they see and may become a follower - WHAT YOU ULTIMATELY WANT. With this system, you can change the code as often as you want - daily or even less. If you make the change you will either need to manually change the code in your vendors OR a smart scripter will be able to automatically poll and retrieve the code from your website each time a customer makes a purchase. In this cool model you will be able to change the code ANY TIME and as frequently as you like. . . I know you ultimately want to reward those you are targetting and no one more... BUT.... you should not be too strict on this limit or even strict at all on this limit because ultimately you want to make a sale and you do not want to deny a purchase from your store from a customer that took the time to come to your store (even if the code was given to her) to buy your clothing at discount and would walk away from making the purchase at all simply because you blocked her attempt with an invalid promo code. Just some thoughts - but your biggest issue is point #1 ADDED COMMENT : With the proposed new promo system - if you wanted to cease the promo for a period of time - you could simply post a comment on the web "No Promos Currently Available" or you could put a special code on the web that if the Vendor sees the code (i.e. 9999) then the vendor system does not prompt the customer for any promo code since it knows with a 9999 there is no promo at this time.

Off topic - I just noticed that the SL Forum Spell checker caught Sassy as much as it caught me with its inability to spell ROADMAP... look at the title of the thread. I wasnt the only one that trust this silly spell checker. ON TOPIC... Regarding a Merchant Union.... The word "Union" is not really the right type of organization that would fit what merchants are believing we all wished we had to represent Merchant's interests and voice against LL. A Union is typically a structure of a group of employees or a category of employees - its organized labor used primarily to protect the interests of the group against their respective Employers. The Merchants of of LL are not Employees of LL. LL is not our Employer. We are more wishing we had a well structured ASSOCIATION. As such, this topic has been brought up throughout the history of LL and Xstreet and MP by the Merchants. There has be a couple attempts to even start this Association. In fact, back in 2009 as a result of the Pink / Colosus Linden regime and the Freebie/Clutter Tax Roadmap that Colosus released on us in November 2008 (Yes... LL Commerce Group actually at one time created and released for all to read .. a ROADMAP!) I spearheaded the creation of one of these SL Merchants Group associations. The backlash and anger by the Merchants from Colosus's horribly mis-guided roadmap and Pink's refusal to back off from the stupidity of the roadmap was sooooo huge that countless merchants moved their listings to competing web ecommerce systems, several delisted and left Xstreet all together, and during the monthly LL/Merchant inworld meetings, I devised a "silent protest" concept with a couple others for the event referred to as the POPCORN PROTEST - where many of us merchants brought custom made protest popcorn buckets to the meeting and just sat back and observed silently. I also created a group and private MERCHANT MEMBERS ONLY group as a "GOOGLE GROUP" with 3 public visible threads and 7 private threads that allowed Merchant members the ability to speak frankly on all topics impacting Merchants without LL's peering eyes nor they forum governing control. I quickly got over 110 members to join the Merchant group and the thread's activities were very strong. Things were looking good and we even had LL Commerce team members wondering what was being said in our private group. But then as the anger and fury of Colosus's horrible Roadmap subsided, the activity of new topics and participation subsided as well and by about April of 2010... the activity died out. (lasted 5 months). So... if you all want to know what it would look like to see an actual association of Merchants... that is what happens. Funny enough the old group forum structure (it was moved away from Google to another provider) with all the threads and topics are all still there as a legacy in time. I went into the group a couple months ago just to look around. It was pretty sad to see how a good idea faded away.

Dartagan Shepherd wrote: Pamela Galli wrote: Oh it was already game over when Darrius and Dartagan hugged. ..... I should apologize to Toy too, for dropping the F bomb on him a ways back. Not sure if I'd want to meet Darrius or Toy or a few others in a dark alley! Not a problem. Its ancient history (in SL Dog years). It was just good to see a Dart shift more to the center - which brought me more to the center. HECK!! Now adays its not even fun anymore to be SL Commerce Forum Group's "LL Contrarian" - to many of you all agree with me now. Maybe I should become the Commerce Group's newest cheerleader as they have very few left to defend them. With all the fiasco of the DD failings - the old Toy would have been the #1 poster to say "I told you so" and "this is rediculous".... but as you have seen... I have just sat back for the most part and let those most affected to the ranting and venting of anger against LL. *** sigh ***