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.
Inara Pey: Living in a Modemworld 