Tag: Viewer-managed Marketplace

Second Life project updates 31/2: TPV Developer meeting

Posted on by Inara Pey

Up to U; Inara Pey, July 2015, on FlickrUp to U, July 2015 (Flickr) – blog post

The following notes are primarily taken from the TPV Developer (TPVD) meeting held on Friday, July 31st. A video of the meeting is included at the end of this report, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding.

Server Deployments Week #31 – Recap

As always, please refer to the server deployment thread for the latest updates / news.

  • Tuesday, July 28th, saw the Main (SLS) channel receive the server maintenance package previously deployed to the three RC channels, comprising internal server fixes related to Experience Keys, comprising null pointer checkers and a configuration option for the number of Experiences a Premium member can have.
  • On Wednesday, July 29th, the three RC channels will be updated with a new server maintenance package aimed at fixing recent group-related issues (BUG-9725 ,BUG-9735 and BUG-9695). Reports following the deployment seem to indicate the issues appear to have been addressed.

Viewer-Managed Marketplace

As I’ve reported elsewhere, the Lab has now announced the retirement of Magic Boxes and the final shut-down of XStreet. Merchants have until August 17th to manually migrate their Magic Box items to VMM if they wish to have sales continue uninterrupted. After that date, the Marketplace will cease delivering goods from Magic Boxes. However, XStreet will remain available through until August 27th.

Wednesday, July 29th saw an updated version of the VMM viewer released. Version 3.8.2.303891 does not contain any functional changes to the VMM code, but does include a number of fixes which will hopefully reverse the elevated crash rates the previous RC version had been suffering when compared to the release viewer.

Providing the stats confirm this after the weekend, and no other emergencies occur, the VMM RC viewer will be promoted to the de facto release viewer in week #32 (week commencing 3rd August).

[00:35] The automated migration of all Direct Delivery items has now completed, and appears to have gone smoothly. The Lab is working through what Brooke Linden describes as “minor problems” directly with the Merchants who have encountered them. In addition, feedback from Merchants is currently being used to update the VMM Knowledge Base documents.

There was also an apology for the sudden change in plans regarding the start of the migration process, and the lack of forewarning to TPVs (and Merchants) on the matter.

 Grid Status Page RSS Feed

[08:06] Back towards the start of the year, the Lab attempted to make changes to the Grid Status page; however, the attempt caused issues, and things were subsequently reverted.

During the Third-Party Developer meeting on Friday, July 31st, Oz and Steven Linden indicated that the Lab is going to make a further attempt to update things. The aim is to update the RSS feed from RSS version 1 to RSS version 2.

As existing web pages, etc., using the feed may need to be adjusted to use the new feed format, a, proxy URL is available (http://beta.status.secondlifegrid.net/feed) using the new feed format is available for testing purposes. This is already using live data, and the Lab’s plan is to allow it to run for a few months in order to ensure there are no issues, and then around November of December 2015, re-direct the existing Grid Status URL to point to the new feed, thus hopefully avoiding the upsets that came with February’s attempt to make changes.

Linden Parcel and Region Damage

[11:16] The Lab has put forward a proposal to improve how Damage can be managed at the region / parcel level. For detail, please refer to my separate report.

Unified Snapshot Floater

[19:16] As indicated in week #23 Niran V Dean has contributed his recent updates to the unified snapshot floater to the Lab, where they’ve been under review. The majority of these have now been approved, and are expected to appear in a Snowstorm contributions viewer in the near future.

Improvements to Prevent No Copy Item Losses

[20:14] As part of ongoing efforts to improve inventory handling, the Lab has been working on some simulator-side updates designed to fixes some issues related to content loss of No Copy objects – notably related to race conditions which can occur and result in rezzing failures and the subsequent loss of No Copy items.

These updates are again a result of the Lab’s continued investigation into inventory issues that started back in February, when they requested users complete an inventory loss survey. It is not anticipated that these changes will in any way affect the Return To Last Position capability, as used by some TPVs, nor do they involve any viewer updates. However, prior to their  deployment, a pile-on test will be held on Aditi, most likely on Friday, August 7th, which will involve TPVs and users putting the changes through a series of tests.

Assorted Notes

  • The Windows 10 detection fix, contributed to the Lab by Ansariel Hiller and referenced in part 1 of this report, will be incorporated in to a Snowstorm contributions viewer
  • There have been no recent code updates from Vivox for voice; Oz is hoping to have news  from them by the next TPV Developer meeting on Friday, August 21st
  • The inventory transform for fixed large “flat” inventories which are causing log-in issues (see my week 15 report) has been under testing, and is currently going through final QA internally at the Lab in preparation for deployment.

VMM: RC viewer updated, Magic Box / XStreet shut down dates

Posted on by Inara Pey

secondlifeUpdate: The Lab has confirmed automated migration of all Direct Delivery items has now been completed, and the current plan is for the new RC viewer mentioned in this article to be promoted to the de-facto release viewer in week #32 (week commencing Monday, August 3rd).

The auto-migration of Direct Delivery items to VMM has been proceeding for a week, and mostly seems to be going smoothly.

However, the VMM code for the viewer has yet to reach a release status, primarily due to the VMM viewer release candidate having suffered from an elevated crash rate when compared to the current release viewer.

As a result, on July 29th, the Lab to issued a new version of the release candidate, version 3.8.2.303891. This does not contain any changes to VMM functionality, but is intended to reduce the RC viewer’s crash rate. Assuming it achieves the aim, it should mean the VMM viewer is once again back in the running for promotion to release status alongside the other RC viewers currently in the release channel.

End of Magic Box Support

Also on July 29th, the Lab issued a blog post announcing the ending of Marketplace support for Magic Boxes and the final shut down of XStreet.

In the blog post, Merchants using Magic Boxes for item deliveries are advised that they have until Monday, August 17th, 2015 to manually migrate those items to use the viewer-Managed Marketplace. After that date, Magic Boxes will no longer be listed on the Marketplace.

Essentially, manual migration involves moving the item into the Marketplace Listing panel, where the required folder hierarchy will be created, and then associating that item with an existing listing on the Marketplace. This is done by copying / pasting the listing reference number (that’s the number at the end of the item’s URL displayed in a browser’s address bar) from the Marketplace and pasting it into the Associate Listing option of the Marketplace Listing panel.

VMM includes an option to manually associate existing MP listings with VMM items in your inventory, which will help ease part of the the migration process for those concerned over automated migration paths
Manual migration in VMM involves moving the item into the Marketplace Listing panel, where the required folder hierarchy will be created, and then associating that item with an existing listing on the Marketplace, by copying / pasting the listing reference number using the Associate Listing option in the Marketplace Listing panel.

Once items in the Marketplace Listing folder have been associated in this way, and a check for errors run, in-world Magic Boxes can be deleted (just make sure everything you want to manually migrate has in fact had its listing associated with a  VMM item first!).

You can also learn about manual migration in the fourth part of the Lab’s VMM video tutorial series, which I’ve also embedded at the end of this article.

XStreet Shut Down

Following the cessation of Magic Box support on the Marketplace, XStreet, (which I think may still be in part used with Magic Boxes), will remain available through until Thursday, August 27th, after which it will finally be shut down. Presumably, this is to give any merchants who missed the August 17th deadline time to complete any remaining manual migration of Magic Box items & re-list them on the Marketplace.

Summary and Migration Video

So, once again the dates:

  • Magic Boxes will stop working on August 17, 2015, and will no longer appear on the Marketplace
  • Xstreet will be finally shut down on August 27, 2015.

And the Lab’s tutorial video on manual migration of listings to VMM:

Lab VMM Resources

Second Life project updates 31/1: server, VMM, group issues, Windows 10 issues

Posted on by Inara Pey

Baby's Ear; Inara Pey, July 2015, on FlickrBaby’s Ear, July 2015 (Flickr) – blog post

Update, July 30th: The updated VMM release candidate viewer referred to in this update is now available: version 3.8.2.303891.

Server Deployments Week #31

As always, please refer to the server deployment thread for the latest updates / news.

  • Tuesday, July 28th, saw the Main (SLS) channel receive the server maintenance package previously deployed to the three RC channels, comprising internal server fixes related to Experience Keys, comprising null pointer checkers and a configuration option for the number of Experiences a Premium member can have.
  • On Wednesday, July 29th, the three RC channels will be updated with a new server maintenance package aimed at fixing recent group-related issues (see below for more details).

Commenting on the Experience changes in the Main channel release a the Simulator User Group meeting on Tuesday, July 28th, Simon Linden said:

That’s just under the hood, the one-per-account is not changing. Simon Linden: with configurations like that, we have a layered approach … there’s a set of defaults that is fixed with each server release. We also have a way to over-ride it grid wide … which is how we can turn on and off some things grid-wide, without a server update; that’s how we turned on the experience tools when we released it. Now that it’s released, we move it into the default settings and eventually out of the over-ride.

Group Issues

In my last update, I reported that people had started experiencing group-related issues, following the Main channel deployment in week #30. In particular:

  • BUG-9725 – Activating a group fails on first selection on Second Life Server 15.07.09.303393 & RC
  • BUG-9735 – Unable to Edit Group Parameters after being made OWNER of newly created group
  • BUG-9695 – [Project Notice] First attempt at joining a group fails (also happens with current release viewer)

Of these, BUG-9735 has been causing the most upset, as it affects anyone who has their role changed. While their role title will update, they will not gain the powers associated with the role, even after the requiredrelog. Commenting on the issues,Simon explained:

It’s due to some database race conditions that show up in the production servers. I was a bit over-aggressive about moving some queries from the master Db to the slave databases…. Normally our main and slave databases are pretty well in sync … with very tiny delay between them; but if you read from the slave database and do something back into the main one, there can be a window when the data isn’t right.

The curious aspect with BUG-9735 is that a relog is normally required for a person to get the updated abilities associated with a role change; so it is unclear why things are going wrong, as Simon went on to say:

I’m not exactly sure how 9735 would happen … I can imagine failures, but relogs should fix that. A bunch of your group info is fetched when you log in, [so] I’m not sure why that couldn’t be updated correctly.

As noted above, fixes for these issues are due to be deployed to the RC channels on Wednesday, July 29th. Once deployed, it would seem likely that anyone being promoted to a new role will have to be on a release candidate channel region when being promoted & relogging, in order for their group abilities to correctly update. However, it’s not clear if the individual promoting someone to a new role will also need to be on a release candidate channel region as well, so some experimentation might be required.

VMM Update

VMM auto-migration of Marketplace Direct Delivery items commenced on Thursday, July 23rd and is proceeding on weekdays between 21:00 SLT in the evening and 09:00 SLT the following morning. However, it is unlikely the VMM viewer will be promoted to the de facto release viewer in the short-term. The reason for this is that the current RC has an elevated crash rate. As a result, there will be a further update to the release candidate, which is due to appear in the next day or so and which will include a number of fixes to try to reduce the crash rate, including one for BUG-9748.

Windows 10 Issues

There have been some recent SL-related issues been noted against recent builds of Windows 10 which are worth reporting, although their potential for any impact may vary.

Font Detection

In the first, BUG-9759, Kyle Linden reports that CJK fonts (those containing a large range of Chinese/Japanese/Korean characters) are not visible in the viewer. This appears to be due to  moving the default location of the font store for Windows 10. As a result, the viewer requires an update so it can look at the revised location.

Windows 10 / AMD Graphics Driver Issue

The second issue appears to be the return of a problem specific to Windows 10 and AMD graphics drivers first reported in March 2015.  This causes the graphics card name to be saved as garbled text into the Windows registry, with the result that any program explicitly requiring the name of the graphics card in order to run correctly can encounter problems (although those which don’t will continue to run OK). As v3-style viewers are designed to explicitly save the GPU name at log-out (it is stored in the settings.xml file), those using Windows 10 / AMD systems may be affected. This is because the garbled card name gets written to the settings.xml file, along with other global settings applied to the viewer by the user, when logging out. This makes settings.xml unreadable by the viewer at the next log-in, so the viewer fails to obtain information, and so reverts all global settings (including graphics) to their defaults. The issue was first reported in April 2015 (see BUG-9054), but seemed to be resolved with later Windows 10 builds. However, it now appears to have regressed with Windows 10 Build 10240 and  the AMD 15.7 driver (see BUG-9740 and particularly FIRE-16528).

An issue with at least one recent build of Windows 10 is that the name of any AMD graphics cards is being incorrectly saved at garbled text in the Windows registry (shown on the left, using the DxDiag tool). As V3 viewers expressly try to save the graphics card name between log-in sessions, this garbled text gets saved instead, with the result that the viewer's graphics are reset to default settings at the next log-in
Left: and AMD graphics driver recorded as garbled text in the Windows 10 registry, and (right) an AMD card name similarly garbled in the viewer’s settings.xml file as a result. The latter prevents settings.xml, which contains all global settings applied to the viewer by the user, from being read by the viewer when next launched, with the result that it reverts to default settings

Quite how widespread this problem might be as Windows 10 starts shipping is unclear, so the above should be read as an advisory of possible issues. However, if it does prove to be widespread, note that a fix will be required from Microsoft / AMD; this is not something the Lab and affected TPVs can address. In an effort to pre-emptively avoid at least some of the possible headaches the issue might pose for their users, the Firestorm team have developed a workaround, which is to be included in the upcoming 4.7.2 release. This workaround allows the viewer to load the settings.xml file so a user won’t lose all their global settings. But because the graphics card name remains garbled within the Windows registry (from which it is read by the viewer), it will still be saved as garbled text in settings.xml, and the viewer will continue reset all graphics options to their defaults when next launched until such time as a fix is forthcoming from Microsoft / AMD to correct the registry issue.

 Version Number

A third, and in terms of functionality, trivial issue is that Windows 10 will show as Windows 8 running in compatibility mode in the viewer’s system info. This won’t impact the viewer’s performance, and a fix from the Firestorm team has been contributed to the Lab (STORM-2105), and should be appearing in due course.

Reminder: Second Life VMM migration set to commence

Posted on by Inara Pey

secondlifeUpdate, July 30th: The lab has issued a new version of the VMM viewer, and the links to the download in this article have been updated accordingly.

A reminder that as recently announced by Linden Lab (and as I reported here), automated migration of Direct Delivery items on the Marketplace to the Viewer- Managed Marketplace capability commences on Thursday, July 23rd, 2015.

All Marketplace merchants will receive an e-mail at the start of the migration process, and another when it has completed. In addition, those with 5,000+ listings will receive an e-mail related to the scheduling of their store migration.

Operations will run from 21:00 SLT through to 09:00 SLT on weekdays, starting on Thursday July 23rd, and will continue in this manner until all stores on the Marketplace have been migrated. Merchants will not be able to modify their stores while their items are being migrated, but sales of items that are not in the process of being migrated will continue.

Note that Magic Box items will not be migrated during this process; they will require a manual migration, and no date has yet been given as to when support for Magic Boxes will discontinue.

The Viewer-Managed Marketplace ideally requires a viewer updated to support VMM in order to make managing items easier. At the time of writing, viewers supporting VMM are:

Non-VMM viewers will display VMM items in a Merchant Listings folder - do not delete this folder or its contents! folder
Non-VMM viewers will display VMM items in a Merchant Listings folder – do not delete this folder or its contents! (Shown in Singularity.)

Note that if you are a Merchant using a viewer that does not have VMM support, once your store has been migrated, you will have an additional folder in your inventory display called Marketplace Listings.

This is the controlling folder for VMM, and should not be deleted, or have contents deleted or moved (it will be hidden in the majority of viewer with VMM support).

While it is possible to use this folder to continue to add new VMM items to your Marketplace store (providing you create the required folder structure, etc.), as Whirly Fizzle notes on the VMM migration forum thread, this is not a recommended approach given that it might lead to mistakes or confusion.

It had been indicated that VMM migration would not commence until after the viewer code had been promoted to release status. As such, the sudden announcement of the start of migration ahead of such a promotion has caused understandable consternation with TPV developers and merchants, prompting the Commerce Team to comment:

As many of you noticed, we did shorten the time line to get Merchants migrated to VMM. This is due primarily to the need to get Merchants off of Xstreet, as it was down for a weekend in early July, forcing us to accelerate our dates.

Those who are concerned about the migration process should refer to the migration forum thread, linked-to above. I also have a high-level overview of VMM (written when the project viewer first appeared), including a look at manual migration.

The Lab’s own resources on VMM can be found here:

Viewer-Managed Marketplace migration commences July 23rd

Posted on by Inara Pey

secondlifeUpdate, July 30th: The lab has issued a new version of the VMM viewer, and the links to the download in this article have been updated accordingly.

Update, July 20th: Linden Lab have given the following explanation for the acceleration with VMM migration: “As many of you noticed, we did shorten the time line to get Merchants migrated to VMM. This is due primarily to the need to get Merchants off of Xstreet, as it was down for a weekend in early July, forcing us to accelerate our dates.” (With thanks to Whirly Fizzle for the pointer to the comment.)

Coming by way of the Commerce blog, Linden Lab has announced that the Viewer-Managed Marketplace (VMM) capabilities are now released, and that automated migrations of SL Marketplace items is to commence on Thursday, July 23rd.

Migration will commence at 21:00 on July 23rd, and each weekday thereafter until all all stores on the Marketplace have been migrated.

The blog post lays out the core aspects of the migration process, which I’ve summarised below – but do still please read the official post:

  • All merchants will receive e-mail at the beginning of the migration process, and another once it has completed
  • Merchants with around 5K or more of listings will have their migration scheduled, and will receive an additional e-mail for the Lab providing them with advanced notice – see additional notes below
  • Migration will occur weekdays between 21:00 SLT in the evening and 09:00 SLT the following morning
  • A Merchant will not be able to modify their store while items are being migrated, but sales of items that are not in the process of being migrated will continue
  • Merchants who have had their stores migrated to VMM  should use the  Second Life VMM Viewer (or a TPV which offers VMM support) in order to manage their Marketplace inventory.
If you have the viewer configured to use its internal browser (the SL viewer allows you it set it for *just* links to SL websites), you can
Viewer-Managed Marketplace allows items sold through the Marketplace to be managed directly from the Merchant’s viewer using the Marketplace Listings panel – there is no need to upload items to the Marketplace servers. Listings can then be created and amended from within the viewer using the built-in browser or, if preferred, can still be edited directly from a Merchant’s Marketplace pages via a web browser

It’s also worth pointing out that the automatic migration process will not run against Magic Box items; these must be manually migrated, and no date has yet been given as to when support for Magic Boxes will discontinue. However, this notice from the Lab should perhaps be taken by those who do still have items in Magic Boxes as indicative that they should start planning to migrate them to VMM.

Both the automated and manual migration process have been undergoing beta testing for some time now, and most reports on both have been positive.

VMM has been moving in this direction for that last couple of months. However, it had been thought that actual migration wouldn’t commence until after the VMM viewer code had been promoted to the release viewer. Given that the Lab tends to prefer promoted a viewer every other week, and this week (week #29) has already seen the attachment fixes viewer to release status, it would appear that migration might be starting prior to the VMM viewer being similarly promoted.

To help people get to grips with the Viewer-Managed Marketplace, the Lab have produced a number of resources, and those unfamiliar with VMM are referred to them for further information.

SL project updates week 24/1: server; VMM; group list changes

Posted on by Inara Pey

Goatswood; Inara Pey, June 2015, on Flickr Goatswood (Flickr) – blog post – visit soon, closes June 19th, 2015

Server Deployments Week 24

As always, please refer to the server deployment thread for the latest updates / news.

  • On Tuesday, June 9th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels, comprising:
    • Change logic on accessing group member lists for large groups – please see more below
    • Internal server logging changes
  • On Wednesday, June 10th, the three RC channels should all receive a new server maintenance package comprising further Internal server logging changes.

Group Member List Changes

The “Change logic on accessing group member lists for large groups” refers to how the members list for groups with more than 5,000 members are now handled. A full explanation of the change and the reasons behind it can be found in my blog post on the matter. however, in short:

  • Groups with 5,000 or more members will no longer display the list of members unless:
    • You are assigned the Owner or Officer role within the group
    • You are assigned an ability within the group which requires the members list to be displayed (e.g. you are able to assign members to assigners roles, or are able to eject / ban people from the group, etc.)
  • Instead, and until corresponding changes are made to the viewer, all you will see on opening the members list as a message stating “Retrieving member list (0 / XXXXX)” – where XXXXX is the total number in the group,

The has already caused concern over how the change may be perceived as a functional breakage – see BUG-9393. In addition, two further issues resulting from the change have been reported:

  • BUG-9404: “Group members of large groups in a role which has “Invite people to this group” ability are not able to send group invites” (initially filed against the RC regions when the change was deployed in week #23, and now applicable to the grid as a whole)
  • BUG-9428: “Users using older viewers are unable to leave groups with >5k members on regions running 15.05.28.302161”

Scripting Memory Limits

A request was made for the Lab to consider allowing llSetMemoryLimit to request up to 128kb or 256kb of memory (whichever is more feasible), with a performance penalty for scripts using less than 50% of the memory requested – see BUG-9382.

The arguments for such an increase are not new; many coders run into problems with utilising memory for both code storage and code operation, resulting in having to write inefficient scripts and additional operations to communicate between scripts. A similar request has also been put forward (see BUG-8761), but which limits the additional memory allocation purely to Experiences on the ground that offering increased memory to all could lead to performance and other issues.

Commenting on the request at the simulator User Group meeting on Tuesday, June 9th, Simon Linden said:

I don’t think we’d want to limit performance … that seems like it would get into odd rules and conditions. Plus that’s likely to be in a place where we don’t want to add more code. FWIW, when you have lots and lots of scripts in a region, the time spent rotating through all the scripts becomes significant, so your script time isn’t just running scripts.

Oz Linden then added:

One of our frequent themes this year has been to look at various limits and consider making them better … perhaps we can look at the memory limit at some point too. One of the things I hope will happen as Experiences are adopted is that some of the code that’s being used to manage saving state and communicating can be replaced by simpler code to use the key/value store.

This drew agreement from Simon, who then continued:

I suspect larger script size has been limited by not having script memory limits. But at a smaller scale, it’s easy to add more scripts, so perhaps doubling or a bit more won’t really make it any easier to hog memory.

This doesn’t automatically mean that script limits will change in the future; as Simon also pointed out, script memory is the largest part of each avatar load, and can have an impact on things like physical region crossings and teleporting, which would likely have to be be considered. However, script memory is likely to get added to “The List” of things the Lab is looking at.

Viewer-Managed Marketplace

Some confusion has been evidenced over the use of the term “archived” in recent communications from the Commerce Team regarding what will happen during the auto migration process, and particularly with reference to items that have not seen sales in over a year.

  • The first point to remember is that any “archiving” will only occur for those merchants who have more than 5,000 items on the Marketplace when the auto-migration process reaches them. As noted in my last VMM update, all such affected merchants have already been notified
  • From information made available by those merchants so affected, it would appear that “archived” means “items will be returned to the merchant’s Received Items folder”. Firstly, any items the Merchant has stored on the Marketplace without any associated listing will be returned. If this fails to reduce their total count to below 5,000, then those items which have not seen sales for over a year will be unlisted and the items again returned to the merchant’s Received items folder.  From this it would seem that there will not be any actual “archiving” of listing information or items on the part of the Lab.