Server Deployments Week 18
As always, please refer to the server deployment thread for the latest news.
- There was no Main (SLS) deployment on Tuesday, April 28th.
- On Wednesday, April 29th the three RC channels all received the same sever maintenance package. This comprises Internal server logging changes and a new flag for llGetObjectDetails() – OBJECT_LAST_OWNER_ID; plus new data which can be requested via llGetEnv(). These are:
- “agent_limit”- get the maximum number of avatars normally allowed on the region (teleport home, and login to last location, are allowed to exceed this).
- “estate_name”- returns the name of the estate (e,g, “mainland”, “Linden Homes”, “My Happy Estate”, etc. )
- “region_cpu_ratio”- returns the number of regions per CPU for this region type (i.e. “1” or “4”)
- “region_product_name” – returns the type of region this is: “Estate / Full Region”, “Mainland / Homestead”, “Estate / Openspace”, “Estate / Full Region – Skill Gaming” etc.
- “region_product_sku” – returns the region’s product number as a string
- “region_start_time” – returns the time the region was last (re)started, in llGetUnixTime format
- “simulator_hostname” – returns the simhost running this region. Same as llGetSimulatorHostname but without the script delay.
Commenting on the llGetEnv() updates at the simulator User Group meeting on Tuesday, April 28th, Simon Linden, who made the updates, said, “these are all pretty simple ones … I went for the easy pickings. Basically, information we already sent to the viewer, or was readily available, and thus not a privacy issue.”
He continued, “There was one [further option] for the max number of agents that was in the original list but that one got skipped … not part of a sinister plot but I overloooked it. want to do some other things with that limit sometime soon as well 🙂 … I’d like to see how the region and viewer performs with bigger numbers. Things go bad with many AVs for a variety of reasons … the server has more updates to send to more people, all wearing more scripts and AOs and HUDS [and] the viewer gets overwhelmed with too many complex avatars and too many textures in the download and graphics pipeline.”
The Avatar Layer Limits RC viewer updated to version 188.8.131.521305 on April 28th, bringing it to code parity with the current release viewer. This RC allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination – so you can wear 60 tattoo layers with it an nothing else, if you want – rather than being restricted to wearing a maximum of 5 of each type of layer.
Online / Offline Indicators
People are noticing that the group chat list (the list of group members in the Group panel), is now much slower to update as people’s status changes (i.e. whether they are on-line or off-line). This is intentional, and comes as a result of the recent improvements made to group chat.
In particular, and as I reported in these pages as work on group chat commenced in 2014, the volume of people logging-in to and out of SL can generate a huge amount of updates for the group chat service (given your status has to be sent to every group of which you’re a member, and to over member of that group who is online to update the group list in their viewer with your new status), meant that more time was being consumed by the group chat servers in handling these update messages than in handling actual messages. The fix for this problem means there is a natural delay in group list updates, as they are now processed differently to reduce the impact they have on message handling.
However, some people have started noticing that some group chat lists with 20+ members seem to take a very long time to update – times of 5-10 minutes have been mentioned, and this is causing some confusion when seeking things like assistance from group owners / moderators (as they can appear to be logged-in long after they have logged-off). It’s also bee reported that at times the list seems to get stuck with no updates until the group chat itself is closed and re-opened, although this appears to be somewhat intermittent.