Tag: SL Issues

SL projects updates Week 16 (3): server, viewer, and Aditi summaries

Posted on by Inara Pey

Server Deployments week 16

  • On Tuesday April 16th, the SLS Main channel received Monty Linden’s HTTP updates, which were deployed to BlueSteel and LeTigre in week 15, after having previously been on Magnum for testing – release notes
  • On Wednesday April 17th, the three Release Candidate channels (BlueSteel, LeTigre and Magnum) all received the same package after a planned deployment to BlueSteel and LeTigre had to be abandoned due to scheduling issues. The package deployed included the new server-side LSL Animation Override capabilities, including a fix for BUG-2164 wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates. The Magnum release are linked to for reference.

Following the SLS Main channel deployment there were a number of reports of significantly higher ping rates with regions being reported on the deployment thread, which prompted Monty Linden to comment, “There was a significant networking event today that has cleared.  Back to normal at this point…” Other than this, and reports of animation issues, which again may have been the result of server-side work, the deployments appear to have rolled-out smoothly and without significant issue.

SL Viewer Summary

Materials processing: the project viewer gained a further update on April 17th, with the deployment of release 3.5.1.274082, which includes bug fixes and some work on alpha masks. The bug fixes are hard to relate to public MATBUG JIRA items, as they all reference NORSPEC issues, which is LL’s internal materials JIRA reference. A further update to the project viewer is anticipated on either Friday 19th April or Monday, April 22nd.

Materials porject viewer: second update now available, third update to follow soon.
Materials project viewer: second update now available, third update to follow soon.

Server-side Baking / Appearance: speaking at the OpenDev meeting on Wednesday 17th April, Oz Linden indicated that SSB will have at least “one more spin” in the beta viewer before appearing in the SL release viewer. A further update was made to the SL development viewer (3.5.2.274273) on Thursday April 18th, so the beta update is liable to be appearing very shortly.

Further viewer updates: once SSB moves to the release viewer, it is likely that the FMODex update will move into the beta viewer; this should also include a fix for the issue with the Mac version of the viewer wherein it crashes whenever headphones are unplugged (and which, incidentally, is the most widely reported crash issue with the Firestorm viewer).

Aditi Issues

While Aditi has received attention recently in order to overcome logging-in and inventory issues, it still as a way to go before everything is “fixed”. Commenting on this at the Beta Server meeting on April 18th, Monty Linden commented, “[The] beta grid is going to get some attention in the login/inv area. But [I] don’t have a date. The problems are (mostly) understood.”

The password-change-to-update-your-Aditi-inventory might be changing as things are looked at and further updated / corrected. Commenting on this at the Beta Server meeting as well, Simon Linden said, “That trigger was done as a quick-and-easy way to stop having to ask a Linden to import your account.”

In discussing the asset system and inventories, Simon re-iterated that while there is a central asset system, it is really one very large storage system, and that, “The real magic isn’t the asset system, it’s your inventory database. Your inventory is what says which assets are yours.” It is syncing the inventory databases between Aditi and Agni which had become an issue, and also somewhat labour-intensive for LL but for the password change trigger.

Monty, with tongue firmly in cheek, suggested an alternative as to how the inventory / asset system works: “Inventory is recorded onto Post-ItTM notes and optically scanned at rez time.” Which, on reflection, is likely to confirm suspicions many have had!

Other Items in brief

Monty Linden
Monty Linden

HTTP Work

The next round of HTTP work is still being defined within the Lab. When asked what this might comprise, Monty replied, “Mesh download is going to get attention. It currently shotguns our services without really performing well.”

He went on, “Might do an experiment or two with pipelining. – but no promises, still setting priorities.”

It is the last remark which is important: things are still being decided in terms of further work and priorities where HTTP work is concerned. This was further underlined again by Monty when he indicated that “phase 3” of the work (the immediate follow-on to the last block of work) may well be “all viewer-side”, given that the initial work (texture fetching) was primarily viewer-side work and the last batch of work was exclusively server-side. So this appears to be a case of wait and see which route he and the Lab opt to take.

Advanced Creation Tools Permissions

July saw the launch of the first phase of the Advanced Creation Tools, also referred to as experience tools. Following problems with an initial deployment of the tools in June, which resulted them being exploited as a means of griefing, the “first phase” of the release saw the tools implemented with existing permissions system in place, with the intention of updating the permissions system to allow the tools to be more fully used “in the future”. Work on the new permissions system was stalled for a number of months, but has recently been getting more attention and work. The current situation appears to be that the permissions system may well be ready, but those working on the project are still, “sorting out how and when that’s going to be made available.”

Diagonal Region Rendering Issues

While fixes have been deployed to assist with issues with regions sometimes taking a long time to correctly handshake and cache with one another following a restart, this issue of regions which are diagonally opposite one another sometimes failing to render remains. Simon Linden had indicated that a potential fix for this issue was with QA as long ago as week 8; however it appears that the work may have hit problems or actually be stalled. In replying to a comment on the forum deployment thread relating to the issue, Maestro Linden replied with a simple, “Correct, that bug has not been fixed”.

No fix yet; status unclear
No fix yet; status unclear

 

SL projects update 16 (2): Server releases; region crossings

Posted on by Inara Pey

Second Life Server (Main) Channel Week 16 Deployment

On Tuesday April 16th, the SLS Main channel received Monty Linden’s HTTP updates, which were deployed to BlueSteel and LeTigre in week 15, after having previously been on Magnum for testing.  These updates can be briefly summarised as:

  • More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
  • Keepalive connections for some HTTP-based services

For more details on the project, please refer to both the deployment release notes and to my overview of Monty’s work.

 Second Life Release Candidate Week 16 Deployment

On Wednesday 17th April, all three RC channels should receive the same update package. This comprises the server-side LSL Animiation Override capabilities, this time complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates.  This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available

Originally, a separate package had been in preparation for deployment to BlueSteel  / LeTigre, but this has had to be postponed due to “last minute scheduling issues”, according to Simon Linden when speaking at the Simulator User Group meeting on Tuesday April 16th. While attempts were apparently being made to get an alternative project into RC, it was “down to the wire to complete testing” at the time of the Simulator UG meeting, and an announcement confirming BlueSteel and LeTigre would receive the same package as Magnum was posted to the deployment thread not long after the meeting finished.

Object Return from Region Edge

A further update which should reach all three RC channels on Wednesday April 17th is the fix for https://jira.secondlife.com/browse/BUG-313 (estate tools do not return objects between 255 and 256m ) / https://jira.secondlife.com/browse/BUG-2021 (Auto-return not affecting objects at 256m), which see objects right on the region edge sometimes slipping into a “limbo” which prevented them from being returned either under Auto-return or when using estate tools.

There is some concern that the fix, once deployed, may not correct all issues. However, until it is deployed, there’s no actual way of knowing – so further updates may well be following.

Region Crossings

Since the deployment of the fix for BUG-1814 making region crossings in vehicles has been seen as noticeably better by many people. However, some have noted problems which appeared to be linked to crossings between regions running on different simulator versions, and this was discussed at length at a recent Simulator User Group meeting.

Kitto Flora suggested the problem was not so much with different simulator versions, but due to network traffic, commenting, “It’s directly related to your Net traffic rate when you cross. If its 500k – fail maybe 20% of time … If its 50k it rarely fails.”

While I have been flying extensively over the past week, particularly over Blake Sea and the south-lying regions and over parts of Nautilus, I’ve not been monitoring net traffic during my flights – although I do reduce Draw Distance when flying and tend to shunt graphics quality down to medium-low – so cannot comment on Kitto’s observations. I can however state that when I did encounter problems beyond the expected temporary loss-of-control  / rubber-banding – such as my camera skewing off to once side of my aircraft as shown below – it always coincided with a move between one simulator version and another, and never between regions on the same simulator version. So I guess more test and observations are due on my part after this week’s deployments!

Flight testing region crossings: when moving between regions running on different simulator versions, I invariably encountered greater issues (such as the camera being shunt, as shown above) than when crossing between regions on the same simulator (note the chat console reports, lower left and notifications. top right).
Flight testing region crossings: when moving between regions running on different simulator versions, I invariably encountered greater issues (such as the camera being shunt, as shown above) than when crossing between regions on the same simulator (note the chat console reports, lower left and notifications. top right).

The discussion on region crossings raised additional questions. One of these was whether or not the speed one crosses between regions made any difference. Simon Linden replied:

Your speed in-world shouldn’t have any effect on actually making it or not, but faster crossings will show the errors in predicting where objects will be more. Such as the rubber band effect when crossing … your viewer sees you going a certain speed, and keeps moving you that way, while you hit the crossing, get some lag as the data is transferred to the new region, and you’re stuck into the world, then sling-shot back to the new position. 

Questions / comments were also raised around the subject of region crossings and idle regions: specifically whether crossing into an idle region was subject to additional delay as the region “woke up” and that some have experienced issues with regions which are apparently idling being unresponsive to new child avies, and people “bounce” off the border prior to being able to cross. Responding to both the question and the comments, Simon said:

You actually shouldn’t ever be able to do that. It won’t be idling if you can see into it … Also, remember idle regions are not dead, they [are] just are running at a slower frame rate, just like loaded down regions do.

Missing Prims

There are currently no updates on the “missing prims” situation which has been previously reported in this blog, and which has grown markedly more apparent since the last set of interest list updates.

Andrew Linden was not at the Simulator User Group meeting on Tuesday April 16th to discuss either, but is almost certain to be asked at the Beta Server meeting on Thursday 18th April, if he attends.

Related Links

SL project updates week 15 (2): Materials, AO capabilities and group bans

Posted on by Inara Pey

Server Deployments Week 15

  • As reported in the first part of this week’s update, there was no Main channel deployment on Tuesday April 9th, the result of issues arising with the previous week’s RC deployments, which LL wanted to fix rather than having them propagate across the grid
  • Magnum retained the same package as week 14 (Monty Linden’s next batch of HTTP updates) and a fix for a crash mode
  • Continuing issues in getting the anticipated updates for the BlueSteel and LeTigre deployment packages ready meant that on Wednesdays April 10th meant that these two channels received the same package as the Magnum RC channel.

The switch-out with the Magnum code being deployed to BlueSteel and LeTigre meant that those regions “lost” the new LSL Animation Override capabilities – existing scripts using the capabilities will still run, but new scripts using the functions cannot be compiled.

Materials Processing

Viewer Update and Documentation

Discussing the materials project at the Open-source Development meeting on Wednesday, April 10th, Oz Linden indicated that an updated version of the project viewer should be available shortly – possibly by the end of the week, as  “lots of fixes are accumulating”. In the meantime, a mixture of Linden Moles and volunteer users are working on materials-focused updates to go into the Good Building Practices guide to help other users get to grips with materials processing and optimising things for SL use. In the meantime, the Materials Data information on the SL wiki continues to be updated.

As pointed out by Mona Eberhardt in the comments relating to materials in this blog, Laverne Donat has produced a very tidy and short demonstration of materials in SL, which I’m including here.

Alphas, Transparency and Costs

Laverne also asked, via Plurk, if and how a specular map can have transparency with the materials processing, before going on to comment (via my blog) that, “After some testing, it seems that you can get specularity with diffuse maps with alpha masking, but not with diffuse maps with alpha blending. I don’t know what the intended behaviour is, but that’s how it works at present.”

This prompted Geenz Spad to reply, “The intended behavior (eventually) is that alpha blended objects will be able to support both normal mapping and specular mapping. Currently this is a work in progress, and due to its current state, it hasn’t been added to the viewer just yet.”

As Alpha Blending is currently the Alpha Mode which is unaffected by the materials / LI accounting situation which has been reported by Qie Niangao, I asked Geenz if Alpha Blending was liable to “trip over” into the LI accounting system, rather than being “grandfathered” (as currently appears to be the case). He further clarified the situation by replying, “Only if you use other material parameters (such as specular mapping, normal mapping, etc.). The only reason why we didn’t add support for shiny on all semi-transparent surfaces, is because it would break content.”

Future Development

In terms of future development, it is unlikely that anything will be happening soon, other than enhancements / fixes for what is currently in the project viewer. While there is a roadmap for future features and additions to the materials system, the Lab is wisely not commenting on plans and direction at this time. Rather, they prefer to see what the overall take-up with the new system is over time and how people start using it (which may in turn affect how and what the Lab decides to do with regards to a “materials round 2”). However, one thing which does appear to be clear is that there are no plans within the current roadmap to extend materials processing to include avatar skins and clothing layers.

AO Capabilities Update

New server-side AO capabilities: udpates delayed until week 16
New server-side AO capabilities: updates delayed until week 16

Although it did not get deployed in week 15 (but should see the light of day in week 16, commencing Monday, April 15th), the update to the new AO capabilities which should have reached BlueSteel and LeTigre is intended improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). The update was developed as a result of Code Violet raising a JIRA (BUG-2164) pointing out that the new capabilities did not “play nicely” with things like sit animations in poseballs / furniture.

Maestro Linden, speaking at the Best Server meeting on Thursday, April 11th, described the situation thus:

If a user had a custom ‘sit’ animation set, the seat wouldn’t be able to stop the animation properly because if the seat called llGetAnimationOverride(“Sitting”), it would get an empty string unless the exact animation also happened to be in the seat’s inventory. Kelly has a nice solution to this problem, which is to make ‘llStopAnimation(“sit”)’ stop your custom animation, if you had overridden your sit animation. Conveniently, this change means that existing poseballs won’t need any updates to play nicely with the new AO system.

The Beta Server meeting saw some discussion on the new AO capabilities, which enabled Maestro and Kelly Linden to offer further clarifications.

Continue reading “SL project updates week 15 (2): Materials, AO capabilities and group bans” →

SL projects update week 15 (1): Server and viewer; materials and land impact

Posted on by Inara Pey

Upate April 10th: The BlueSteel / LeTigre package did not deploy as planned due to problems getting the updates completed in time. The Magnum package therefore deployed to all three RC channels.

Server Deployments Week 15

Second Life Server (Main) Channel

There was no planned deployment to the Main channel on Tuesday April 9th. The next scheduled deployment will be in week 16 (week commencing Monday April 15th). This was because there were bugs found in both of the RC releases from week 14 which the Lab wanted to resolve rather than having them propagate across the grid.

Release Candidate Channels

All three Release Candidate channels remain on the same releases as week 14, the only updates to be deployed on Wednesday April 10th being:

  • BlueSteel and LeTigre (currently running the new server-side AO capabilities) – should receive  a design change to improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). This may be in response to a JIRA – BUG-2164 – being raised in relation to conflicts between the new AO capabilities and poseball systems
  • Magnum (currently running Monty Linden’s HTTP updates) – should receive a fix to correct a crash mode.

As always, there is a forum discussion thread for the week’s deployments.

SL Viewer Updates

CHUI – Communications Hub User Interface – Flickering Issue

The CHUI merge with the SL release viewer has brought with it an increase in the ATI/AMD issue of clickable links in the viewer’s UI flickering when anti-aliasing is enabled (BUG-1560, relating specifically to cards running the 12.10 (or later) Catalyst). This tends to happen with links in the chat window, but may also affect the selection box surrounding items in the inventory floater.

Those encountering the problem should consider raising a bug report.

Materials Processing – Land Impact

The most notable update to the SL viewer has been the release of a project viewer for materials processing. The viewer is available on the SL wiki Alternate Viewer page, and the code is available on Bitbucket. However, due to the work still going into the project, both come with caveats:

  • It is still very fragile
  • It is still subject to change in various ways
  • It should not be used on content you care about – particularly if said content is MODIFY / NO COPY
  • It is not recommended that TPVs integrate the code into their release viewer at the moment due to the fact the code will be changing (and there is not SSB merge as yet).

The release of the viewer has also brought with it something of a concern.

Qie Niangao has been carrying out further tests with the Materials Processing project viewer, and has come up with evidence that aspects of the material system can result in objects experiencing sudden (and potentially large) Land Impact value changes. Specifically use of the Alpha Masking and Emissive Mask options when working with alphas can have unexpected results – which is not to say that the result are not unexpected behaviour from LL’s perspective.

Qie describes his discovery in MATBUG-13, is which he offers the following exercise:

  1. Create a sphere. Hollow it 95%. Add a simple rotation script.
  2. Set the Alpha Mode to Alpha masking. Note that the land impact is now 43. “More info” shows the extra weight attributed to Physics.
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) into the "new" LI accounting system
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) can lead to a inflation of LI for an object

Qie goes on to note that cutting or squashing such an object can have an even more dramatic impact (path cutting the sphere in half, for example, can push LI to 1348, while squashing it almost flat can lead to an LI of 154).

Commenting on the JIRA, Maestro Linden notes:

This is expected behavior. When a material is added to an object, it is enrolled in new prim accounting. A 50cm, 95% hollow sphere has 43.5 physics cost when using a ‘prim’ physics representation. This high cost is caused by the high complexity physics shape. See https://wiki.secondlife.com/wiki/Physics_Optimization for a guide about how to reduce physics cost.

It is interesting to note, however that the same prim using Alpha Blending retains the same physic cost, but only generates a LI of 1. As Alpha Blending is essentially the way alpha layers are currently handled by the system at the moment, Qie’s theory – which I agree with – is that the existing system as been somehow “grandfathered-in” to the LI accounting system.

Continue reading “SL projects update week 15 (1): Server and viewer; materials and land impact” →

“Missing” prims: collaboration confirms viewer issue

Posted on by Inara Pey

As noted in my week 14 (2) update, prims missing from linksets  / builds is not a new issue, it’s been going on for some months now. In my own case, I’ve found that on teleporting to my home, an internal wall I’ve added to the build is routinely missing from my view. Right-clicking on the area of the wall has caused it to immediately render. As the wall in question tends to rez OK when I log-in to SL, I’ve tended to look on the matter as a viewer issue.

However, following the week 14 deployments, the incidences of missing linksets seems to have both risen in both numbers and size of “missing” prims. There have been numerous reports on the deployment discussion thread, including questions as to whether it is a viewer issue or server issue, and things seem to have become a lot more visible.

My Linden Home and "missing" prims on Wednesday 2nd April
My Linden Home and “missing” prims on Wednesday 3rd April. House is located on the SLS (Main) channel

My personal experience has been that things are worse – as shown in the image above. Prior to the April 2nd, The wall on the far side of the house, with the two pictures and turning to run under the bedroom balcony rails, would fail to render following a teleport. Since the Main channel deployment on Tuesday April 2nd, that wall now renders flawlessly – but a huge section of the linkset for the house itself is almost constantly missing following a teleport home. Camming around my home region reveals other houses in the same condition.

Such has been the level of discussion on the thread about the matter, lead by Wolfbaginski Bearsfoot and others, that Maestro Linden stepped-in and posted some pointers to help people determine if they have a viewer or a server-side issue, stating:

Hi Wolfbaginski, I would do the following to determine whether objects are missing due to a server bug or viewer bug:

1) Note whether the missing objects are whole linksets or only certain prims in linksets.  Interest list issues would generally affect whole linksets.  A viewer rendering issue or maybe a message-packing/decoding issue would seem more likley if only certain prims in linksets are affected.  It sounds like you’re seeing at least part of the linkset, since you’re able to select it.

2) While the prims are missing, enable Develop -> Render Metadata -> Bounding Boxes, and see what bounding boxes appear.  You should see a prim-aligned bounding box for each prim, as well as a world-aligned bounding box that covers the linkset.  If you see a bounding box where a missing prim is located, or if the linkset bounding box extends to include the missing prims, then it’s almost certainly the viewer’s fault.  

3) While the prims are missing, enable Develop -> Show Info -> Show Updates to Objects.  With this setting enabled the viewer will render a particle from each linkset/prim that it got an update for:

  • Red means a full update was received from the server (which has a full description of the object’s visual parameters)
  • Blue means a terse update was received (which only includes information about a few properties, such as position and velocity)
  • Green means that an ‘objectdelete’ update was received (meaning that the object was either derezzed or is out of range for the viewer)

If you enable this feature, and observe that the missing prims appear without a full object update being sent, then it’s probably a viewer bug (in that the viewer knew about the missing prims the whole time, but initially failed to render them).

 4) If you leave a region, then return to it, the viewer will load cacheable objects from the local cache, instead of getting the object details from the simulator.  If the object was loaded from cache and the appearance has been either fixed or broken since the last time you saw it, this would indicate a viewer bug.  You can verify that an object was loaded from viewer cache by enabling Develop->Rendering Metadata->Update Type; objects loaded from cache are shaded blue, with this mode enabled.

Continue reading ““Missing” prims: collaboration confirms viewer issue” →

SL project updates week 14 (2): Server releases; deformer

Posted on by Inara Pey

Deployments for Week 14

SLS Main Channel

On Tuesday April 2nd, the Second Life Server (SLS or Main) channel received the interest list update which has been running on the Magnum RC channel for weeks 12-13. This includes:

  • More correct sorting when streaming objects to viewer
  • More objects are categorised as cacheable by the server (improves scene loading speed when revisiting regions)
  • Packed full ObjectUpdate data recycled for multiple viewers (optimisation of how UDP packets are built)

Additionally, the package includes fixes for the following issues:

  • BUG-1779 – Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent
  • BUG-1795 – “Agent appears in incorrect position to other agents after being moved by a sim teleporter”
  • BUG-1814 – “No object updates from vehicles after some region crossings” – yes, the vehicle region crossing bug fix reaches the Main channel (and should be on BlueSteel and LeTigre following the RC deployments on Wednesday 3rd April).

As always, there are release notes for the deployment.

Following deployment, there have been assorted reports that:

  • Region crossings in vehicles are generally a lot better – although the BUG-1814 fix will not reach the entire grid until after the RC deployments for Wednesday 3rd April (see below). However, feedback is pretty much in line with my own Magnum tests in my Mark XI Spitfire
  • There are reports that the fix for BUG-1779 is not working in all cases – Whirly Fizzle reports that her Meeroos are still suffering the same update issue as prior to the roll-out
  • There are also reports of increased issues with prims / parts of linksets failing to rez until right-clicked upon – although there is some speculation that this might be worse for some TPVs as they may not have recent code updates from the Lab.
Prims failing to rez until right-clicked: issue more prevalent?
Prims failing to rez until right-clicked: issue more prevalent?

Release Candidate Channels

On Wednesday April 3rd, the Release Candidate (RC) channels should receive the following updates:

  • BlueSteel and LeTigre should receive the same package as week 13, which includes the new Animation Override LSL capabilities. In addition they also should receive:
    • The changes deployed to the Main channel on Tuesday April 2nd
    • A fix for BUG-2134 – “Avatar pre-jump is sporadic”
    • Release notes are available (BlueSteel link)
  • Magnum should receive Monty Linden’s new server-side HTTP updates (see below) – release notes.

SL Viewer

The Mesh Deformer project viewer was finally updated on Tuesday March 2nd with the release of version 3.5.1.273384. There are no changes to the deformer with the release – which does see the deformer code now merged with the CHUI codebase.

HTTP Updates

Monty Linden's HTTP updates should arrive on the Magnum RC on Wednesday 3rd April, assuming no last-minute hitches
Monty Linden’s HTTP updates should arrive on the Magnum RC on Wednesday 3rd April, assuming no last-minute hitches

The next stage in Monty Linden’s HTTP project should reach the Magnum RC channel on Wednesday April 2nd. these updates can be briefly summarised as:

  • More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
  • Keepalive connections for some HTTP-based services

Notes on the latter point explain that:

The behavioral change for HTTP connections marks the beginning of support for persistent (keepalive) connections. Services transiting the capabilities router, at ports 12043 and 12046, may honour a request for keepalives and keep a connection open after request completion. These services may include such activities as texture and mesh fetching, event delivery to viewer, HTTP-In for LSL scripts, asset uploads and inventory operations. Benefits from keepalives include immediate and future throughput increases and less TCP connection churn (which often disrupts consumer-grade networking equipment). The exact set of services that will see this is expected to change over time.

In other words, connectivity between the viewer and the server should be somewhat more robust and, in the case of older router models, less taxing.

Server-side Baking Avatar Z-offset

I missed the Monday Content Creation meeting on April 1st due to family commitments. However, I understand from information received that the question of avatar height offsets. The solution, as currently offered by LL, is considered to be less than optimal for all situations. In replying to the question, Nyx Linden apparently indicated that the Lab do not consider the matter fix in light of further examples having been given, and that further work in correcting matters is in-hand. Whether these further fixes address all concerns remains to be seen.

Other Items

Griefing

Griefing was once again a subject of discussion at the Simulator User Group meeting on the 2nd April. As with the last time the recent increase in mainland griefing was raised, LL are not willing to discuss specifics in terms of what they’re aiming to do. However, Simon Linden did provide more general feedback in response to questions.

Nothing new to report about griefing tools … but it is on our radar and definitely a concern … When looking at griefing problems the most serious issues and the ones that get the fastest attention is anything that can crash a region or viewer. After that there’s a broad spectrum mostly based on the level of pain and if there are things that can or can’t be done about it already. The fight has been going on since long before I joined the Lab.

During the discussion, Simon was at pains to again point out that those Lindens attending the User Group meetings are not responsible for dealing directly with griefing accounts – that is the role of the Governance team. However, he also made it clear that there are internal LL meetings where griefing is discussed, saying:

The Lindens that come here like Andrew, Kelly and myself are server developers, so we focus on features there that can help. Dealing with accounts is outside our area and the Governance people handle that … We do regularly meet and discuss what’s going on … everyone is aware of the recent increase in griefing … It’s gotten a lot worse recently. Not due to technical failures and it becoming easier, but from more griefers.

Simon also indicated that the bug which allowed objects to get stuck in limbo at the edge of a region, where they could be exploited by griefers, now has a fix in the BlueSteel and LeTigre RC channels, and that measures to help combat particle spamming are “in the pipeline”, with the hope that a project viewer will be featuring these will be available soon.

SCR-19 – Script function to return objects remains a popular choice of handling griefing objects, and Simon – purely as a brainstorming exercise asked for feedback on region controls which could be turned off / options which could help make land more “griefer-proof”. Some of the responses included:

  • Having particles require group permissions
  • Banning individuals based on their group membership. This raised questions over privacy and usefulness / effectiveness. The former as it would require a means to discover someone’s groups, even if hidden; the latter points because it would only otherwise work on a person’s active group, it would be relatively easy to circumvent (by leaving the group, if necessary)
  • Blocking object rezzing based on the creator’s name
  • Turning off public script operation over explicit banned/no access parcels, making the return time for public rezzed objects over explicit banned/no access parcels 1 minute.

Again, none of this should be taken as an indication that any of the above will be explicitly developed by LL; rather they are likely to be added to the melting-pot at the Lab and help LL better understand where user concerns lay and what directions they should consider for further technical responses to griefing issues.

Mesh Object Physics Shape

There has been a (possibly long-standing) problem with the physics shape for some mesh objects being changed unexpectedly. Lares Carter, speaking at the Simulator User Group, described it thus:

The physics shape type for mesh objects gets changed from Prim to Convex and doesn’t change back until the object is right-clicked. This only happens for linksets that contain a prim with a target omega property. Things that can trigger the change: movement changes and rezzing the object. There also seem to be other factors as it can happen for static objects too.

The issue has been reported in BUG-2147, and differs from the problem wherein some objects / parts of builds (such as floors, walls, etc.) fail to rez until clicked upon (but can be walked on, etc.), in that the mesh object can be seen and can collided with – but the physics shape is incorrect. There are reports that analysing the physics model in the mesh uploader can be used by content creators to mitigate the issue. However, this issue is now on the Lab’s radar in terms of further investigation.