Tag: Server Updates

SL projects update week 26 (2): server, pathfinding bug, viewer updates

Posted on by Inara Pey

Server Deployments – Week 26

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds the new pathfinding property CHARACTER_STAY_WITHIN_PARCEL to llCreateCharacter() and llUpdateCharacter() – see my week 19 report for details – and the object return functions I reported on in week 23.

While not intended to fix issues of diagonally adjacent regions not being visible to one another (SVC-8130), there are reports that at least some of the regions which have suffered from this issue for a considerable time can be seen from one another once more – although Maestro Linden isn’t entirely convinced the underlying cause of the problem has been corrected.

Release Candidate (RC) Channels

On Wednesday 26th June, all three RC channels (Magnum, BlueSteel and LeTigre) received a new server maintenance package, comprising:

  • A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
  • Crash mode fixes
  • New LSL function: string llXorBase64(string str1, string str2)
    • Returns a string that is a Base64 XOR of Base64-formatted input strings, str1 and str2.
    • Fixes a ‘bad’ behaviour when the 2nd string contains nulls (“A” in base64) – SCR-35
    • Aside from those cases, this function behaves identically to llXorBase64StringsCorrect()
    •  added to avoid changing the behaviour of existing scripts which may rely on llXorBase64StringsCorrect()’s current output
  • Added max_materials_per_transaction flag to /simulator/features cap
    • This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.

MAX_MATERIALS_PER_TRANSACTION

Speaking at the Server Beta meeting on Thursday 27th June, Maestro Linden described the max_materials_per_transaction flag thus:

It limits how many materials the viewer can request details for or set (POST, PUT methods) in a single message. By default, the limit is 50. The reason for the limit is that we don’t want the simulator to hang if a malicious viewer requests the details of 2 billion materials at once.

So, the capability for materials is called RenderMaterials [and] it has 3 HTTP access methods:

  • GET: get the full list of details of all materials in the region
  • POST: get the materials details for a list of material_ids (the server will only parse the first max_materials_per_transaction in the post data)
  • PUT: set the materials properties of up to max_materials_per_transaction object faces

GET is used when you first connect to a region and want to get the materials of everything [in the region, not just within draw distance]; POST is used if, for example, a new object is rezzed with a new materials type, and the viewer needs to resolve what the normal map is, etc; and PUT is used for object editing.

[So] if the viewer needs to edit 80 faces at once, for example, it will know that the server limit is 50, and POST in 2 messages (one for the first 50, the other for the other 30).  [The] ‘max_materials_per_transaction’ flag in the features cap will be a way for the viewer to know if the server limit changes from 50 per message. I’m not aware of any plans to change that limit in the near future, though.

Deployments for Week 27

There will be no server-side deployments in Week 27 (commencing Monday July 1st), as US Independence Day is on Thursday July 4th. The next scheduled deployments will be in week 28, commencing Monday July 8th.

Pathfinding Bug

Elijah Linden has discovered a bug within the pathfinding code, wherein certain regions have continuous navmesh rebaking, which causes some annoying UI effects, hurts simulator performance somewhat and causes memory spikes. Regions can be affected even if pathfinding is turned off.

Voidpointer Linden assumes human form (stock)
Voidpointer Linden assumes human form (stock)

The bug arose as a result of the recent CHARACTER_STAY_WITHIN_PARCEL property added to the pathfinding capabilities. Commenting on the bug at the Server Beta meeting on Thursday 27th June, Voidpointer Linden, who implemented the new CHARACTER_STAY_WITHIN_PARCEL property, said:

As part of the STAY_WITHIN_PARCEL changes, I needed to change the way the navmesh is constructed. This involved making sure that every region did a rebake once. Unfortunately, the criteria that I used to test whether a region needed rebaking had a flaw – it can’t see parcel edges underwater [possibly because the navmesh doesn’t include areas below sea level]. So if a region has more than 1 parcel and has no parcel edges above water, then it thinks it needs to rebake. So it does.

And does so repeatedly, as Elijah Linden reported in BUG-2975 (Regions continue to requests rebake after rebakes have been performed).

There is a fix for the issue, but it currently requires testing, and may not appear for a while. In the meantime, there is one assured workaround: if your region is suffering from the issue and has a parcel which is completely submerged, subdivide / raise one part of a boundary for that parcel (and which is not also a region boundary) above water so it can be found by the navmesh rebake process.

This bug is unlikely to be resolved before week 28 due to there being no deployments scheduled for week 27, as mentioned above.

SL Viewer

The SL release viewer updated to version 3.6.1.278007 on June 27th, containing the fixes from the 3.6.1.277611 beta release. This contains some updates related to the viewer being available via Amazon, and fixes for occlusion culling being less effective than it should be, legacy Shiny being too strong in ALM with materials,light function sampling is incorrect in advanced lighting model and a viewer compilation error.

The beta viewer updated to 3.6.1.277824 on June 26th, with the release notes listing the same updates as 3.6.1.277611 and 3.6.1.278007 – so these appear to be work-in-progress fixes.

SL projects update week 26 (1): server, viewer, materials

Posted on by Inara Pey

Server Deployments – Week 26

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds new LSL capabilities:

  • The new pathfinding property CHARACTER_STAY_WITHIN_PARCEL, which can be used with llCreateCharacter() and llUpdateCharacter(), and is intended to help with keeping characters within parcel boundaries – see my week 19 report for details
  • The new object return functions I reported on in week 23, namely llReturnObjectsByOwner and llReturnObjectsByID, are intended to provide an automated means of returning objects to their owners – see my full update on these functions for details.

This package also includes the following:

  • An update to llReturnObjectsByID() to prevent it from returning other objects which are owned by the parcel owner or estate owner/manager
  • A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833)
  • A fix for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry) – which caused this deployment to be replaced by the Magnum RC package in week 24.

The neighbouring region visibility issue referred to in the package is for SVC-8019, which is related to issues with regions failing to communicate with their neighbours for up to an hour are a restart, causing communications issues (e.g. LSL chat) across region borders. It is not intended to address the issue of diagonally adjacent regions not being visible to one another (SVC-8130).

Release Candidate (RC) Channels

On Wednesday 26th June, all three RC channels (Magnum, BlueSteel and LeTigre) should receive a new server maintenance package, comprising:

  • A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
  • Crash mode fixes
  • New LSL function: string llXorBase64(string str1, string str2)
    • Returns a string that is a Base64 XOR of Base64-formatted input strings, str1 and str2.
    • Addresses the cases from SCR-35 “llXorBase64StringsCorrect returns wrong result when the 2nd string contains nulls”
    • Aside from those cases, this function behaves identically to llXorBase64StringsCorrect()
  • Added max_materials_per_transaction to /simulator/features cap
    • This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.

SL Viewer

General

With the release process yet to switch-over to the new system, the following viewer updates were made in week 25:

  • The SL beta viewer saw an additional release – 3.6.1.277611 on June 21st. This primarily included some fixes for the version of the viewer which is offered via Amazon for download, and rendering fixes
  • The Snowstorm Contributions Test Build viewer was updated to the 3.6.1 code base (version 3.6.1277577, June 20th, for details of the current contributions in the viewer, follow the link). This would appear to be the first step in merging-up a series of third-party viewer contributions which are liable to see a project / beta viewer release after the new viewer release process comes into use.

Viewer Release Process

Commenting on progress with the upcoming new viewer release process at the Open-source Dev meeting on Monday 24th June, Oz Linden said, “We’re in the final verification stages. Might even get it turned on this week.”

As a side note, and In preparation for the new process, I’ve revamped my Viewer round-up page to (hopefully) better reflect the fact that we should be seeing a broader spread of viewers being put out by LL. This is a work-in-progress, and the page may evolve further as the new viewer release mechanism comes into force. Similarly, the weekly summaries produced from this page are also being revised ready for the new release process.

Materials Viewer

Despite issue with the materials viewer, there are a number of content creators already working on products which leverage the new capabilities. At the Open-source Dev meeting on Monday 24th June, Whirly Fizzle pointed people towards the work of Chip Midnight, who has been working on a mesh avatar using materials properties.

Chip Midnight's mesh avatar model (click to enlarge)
Chip Midnight’s mesh avatar model (click to enlarge)

Whilry also supplied a link to  a thread on the SL Universe forums where Chip discusses the avatar. For those interested, it’s worth following the discussion for the next couple of pages – particularly Drongle McMahon’s reply to Chip on the subject of specular and gloss maps.

Continue reading “SL projects update week 26 (1): server, viewer, materials” →

SL projects update 25 (2): server, materials

Posted on by Inara Pey

Update June 21st: A new Materials Support and Tips thread has been started by Creator Linden in the Building and Texturing Forum (with thanks to Daniel Voyage for the poke).

Server Deployments – Week 25

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday June 18th, the SLS main channel received the interest list improvement project which have been previously deployed to Magnum (week 22) and BlueSteel and LeTigre (week 24).

Release Candidate (RC) Channels

On Wednesday 19th June, all three RC channels (Magnum, BlueSteel and LeTigre) received the same server maintenance package, designed to fix a number of crash modes and address an issue with neighbouring region visibility. In addition this package:

  • Contains the new LSL pathfinding property CHARACTER_STAY_WITHIN_PARCEL, and the new LSL object return functions designed to assist land owners with the return of objects under controlled conditions
  • Provides fixes for A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833) and for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry).

The neighbour region visibility issue fixed by the deployment is for SVC-8019, which is related to issues with regions failing to communicate with their neighbours for up to an hour are a restart, causing communications issues (e.g. LSL chat) across region borders, rather than being related to the issue of diagonally adjacent regions not being visible to one another (SVC-8130), which is still an issue on the main grid.

The fix deployed to the Release Candidates does not address issues of diagonally-adjacent regions failing to render to one and/or the other
The fix deployed to the Release Candidates does not address issues of diagonally adjacent regions failing to render to one and/or the other

Commenting on the latter issue while testing it with an alt during the Server Beta meeting on Thursday May 20th, Maestro Linden said, “It looks like some kind of false communications timeout in the remote region, where it disconnects your viewer.” Currently, there is no proposed fix for the issue, although the Lab keep poking at it.

Materials Processing

matbug-715-a
Objects using transparencies as rendered with ALM off in the materials viewer (click to enlarge)
matbug-175-b
The same items rendered with ALM active in the materials viewer (click to enlarge)

The Materials Processing project reached a release status on Wednesday June 19th, with the release of Second Life viewer 3.6.0.277516.

However, problems continue to be reported with transparencies rendering as black when using the viewer, (see MATBUG-175, MATBUG-193 and a similar bug, MATBUG-186).

Two possible workarounds for these problems have been suggested, which may work, depending on the precise nature of the issue, if you’re experiencing it:

  • Going into Preferences > Graphics and unchecking Advanced Lighting Model (ALM) before click OK to apply, then going back into Preferences > Graphics and enabling ALM once more
  • If you have water reflections set to Minimum in Preferences > Graphics, try setting them to a higher value and then unchecking / rechecking ALM.

Some of these issues were known well in advance of the viewer reaching a release status, which promoted comments of surprise during the Open-source Developer meeting on Wednesday June 20th that the viewer had been released. Commenting on this, Oz Linden responded:

I’m not at all surprised that people found combinations of visual attributes we hadn’t tested that were busted, really. There are a staggering number of combinations – after you factor in all the possible settings changes on top of them, the number is absolutely not even close to something we could test. The “black issue” makes it sound simple…. we probably had a dozen bugs during development that had that same symptom for different reasons. I’m sure we’ll get it sorted out.

Continue reading “SL projects update 25 (2): server, materials” →

SL projects update week 25 (1): server, SSB/A, viewer

Posted on by Inara Pey

Server Deployments – Week 25

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday June 18th, the SLS main channel received the interest list improvement project which have been previously deployed to Magnum (week 22) and BlueSteel and LeTigre (week 24). This includes:

  • A fix for excessive AvatarAppearance packets being sent to the viewer [in which the simulator would send many unnecessary AvatarAppearance messages to the viewer]
  • A final fix for the “meeroo problem” whereby animations on Meeroos and other animals fail to update correctly when camming around.

Release Candidate (RC) Channels

On Wednesday 19th June, all three RC channels (Magnum, BlueSteel and LeTigre) should receive the server maintenance package briefly deployed to BlueSteel and LeTigre in week 24. to fix a number of crash modes, addresses an issue with neighbouring region visibility, and adds new LSL pathfinding capabilities and object return capabilities:

  • The new pathfinding property CHARACTER_STAY_WITHIN_PARCEL, which can be used with llCreateCharacter() and llUpdateCharacter(), and is intended to help with keeping characters within parcel boundaries – see my week 19 report for details
  • The new object return functions I reported on in week 23, namely llReturnObjectsByOwner and llReturnObjectsByID, are intended to provide an automated means of returning objects to their owners – see my full update on these functions for details.

This package also includes the following:

  • An update to llReturnObjectsByID() to prevent it from returning other objects which are owned by the parcel owner or estate owner/manager
  • A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833)
  • A fix for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry) – which caused this deployment to be replaced by the Magnum RC package in week 24.

SSB/A Pile-on Test Update

Nyx Linden (stock)
Nyx Linden (stock)

On Friday June 14th, a Server-side Baking / Appearance pile-on test was conducted on the main grid (see my report on events). The Lab is still going over the results of the test and all JIRA filed and log files submitted. Giving a preliminary summary of the test at the Content Creation User Group meeting on Monday June 17th, Nyx Linden said:

We actually just recently got through looking at the bug reports that were filed. Things are looking good, if you know anyone who saw anything major during the pile-on test please encourage them to file a bug ASAP if they have not already done so.

The system seemed to work quite well for most people, and we’re looking closely at the people who were having trouble resolving to try to figure out exactly what happened. The baking service was doing fine, there were some other services that weren’t used to that many people changing their outfits that close together (hence some attachments had difficulty resolving, etc). If anyone knows of failure cases for SSA (aside from those reported if you log in with very old viewers), please let us know asap.

The test did not include a minor update intended for the viewer-end of things, or the code change to help avoid SUN-74. However, as mentioned in my last SSB/A update, the former isn’t required prior to SSB/A starting its deployment across the grid, while the safest way to avoid encountering problems with non-maintained viewers  / viewer without the necessary SSB/A updates is to upgrade your viewer. Now.

Viewer News

Materials Processing

The final beta release (3.6.0.277409) performed well over the weekend, with a crash rate “comfortably under” 9%. The code has been merged with the release viewer and is in its final QA testing ready for deployment. Providing nothing unexpected happens, it should appear on the viewer download page as the release viewer very soon.

Viewer Release Process

Work is continuing on the new viewer release process, which may go live later in week 25 or early in week 26. In the meantime, and as reported in week 24, a viewer source repositories page has been produced on the wiki. There is also a further wiki page explaining the release process, although it is still under development. You can find it listed as the Viewer Integration and Release Processes.

The new viewer integration and release process – click to enlarge (image courtesy of Linden Lab)

Note that the new process does not mean there will be multiple versions of the release viewer available for download (although there will potentially be multiple project / beta / release candidate versions available for download).

Should two projects reach a point of being ready to go to a release status at the same time (such as with “project 1” and “project 2” in the diagram above), a decision will be made by the Lab as to which should go first. That viewer then changes status to release, with the code pulled back to the viewer-release repository. The second viewer awaiting release will then merge with the changes and put out a further release candidate, and will then move to a release status from there.

For ease of reference, the viewer download page and the Alternate Viewers wiki page remain the default places for most users to obtain versions of the SL viewer.

Other Bits

Object Contents Loading

We’re all familiar with using prims as storage for other items (e.g. “boxed” items sold through the Marketplace or using a prim to store items in inventory we don’t frequently use). when a prim has a large number of items in it, there can be a noticeable delay in seeing the contents listed in the Contents tab of the Build floater. In addition, adding objects can be prone to a slow response as well – and can cause problems such as the loss of No Copy items when dropping more objecting into the Contents tab while the system is already copying / adding items to a prim’s contents. I

n terms of the slow loading issue, some have reported times of 30-40 seconds when trying to list the contents of a prim with 100 or so items, and a question was asked at the Simulator User Group meeting on Tuesday June 18th on whether there was any particular reason for this.

Replying to the question, Andrew Linden started with a cautionary note, “Sure, people can create that many items in contents, but I wouldn’t rank it as a good idea.” He then went on, “I don’t know the exact nature of the bottleneck there, but 30 seconds sounds too long. I’m pretty sure it could be sped up, but I’d have to dig around to see why it is slow.”

Kelly Linden then added: “Object inventory transfer from server to viewer uses one of the oldest legacy methods in Second Life. Updating that is probably a good idea but would require a joint viewer and server version change, or some acrobatics on managing compatibility.”

While agreeing this might be the case, Andrew went on, “The UDP protocol should be able to transmit 300 items in much less than 30 seconds. I’ll try to look around to see what is limiting that. However, I should note… I won’t be attending next week. I’ll be on vacation.”

So, there may be further updates on this in the future.

Related Links

SL projects update week 24 (4): server release update

Posted on by Inara Pey

Server Deploys for Week 24

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (Main) Channel

On Tuesday June 11th, the SLS channel received getting the server maintenance project that was on BlueSteel and LeTigre in week 23, and which is intended to fix a simulator crash mode, and a disconnection issue whereby multiple avatars would be disconnected from a simulator simultaneously, giving the impression the region had crashed when it had in fact not done so, and which also impacted LSL HTTP-in URLs.

Based on data since the deployment, it appears the disconnection issue has been addressed, although there was a report that problems of LSL HTTP-in URLs being dropped, Commenting on this issues at the Server Beta meeting on Thursday 13th June, Maestro Linden said, “I managed to confirm that it was a separate problem [to the avatar disconnection problem] Kelly has looked into it, and we think we’ll have a fix for that soon.”

Kelly Linden added, “I’ve been working on some http-in bugs for the last couple of days. I have some fixes but I can’t guarantee they will be 100% effective. There is more Rube Goldberg in that system than I’d like.”

Magnum Release Candidate Channel

On Wednesday June 12th Magnum received an update to the current interest list changes running on that channel, which addresses two bugs introduced by the project. The bug fixes were for the problem of the text of large scripts failing to display in the script editor for people on lower bandwidth connections,  and a fix for the simulator spamming the viewer with AvatarAppearance messages when avatars were in view and were moving around, also resulting in bandwidth issues.

There have also been reports of an “invisible avatar” problem occurring on Magnum regions since the week 22 deployments. which take the form of avatars in the local vicinity de-rezzing following an in-region teleport, and will only re-appear following a relog. The issue was reported as still be present in week 23, and again following this week’s deployment. So far, the Lab has been unable to reproduce in-house, so investigations are proving difficult. As BlueSteel and LeTigre are now also on the same release (see below) the Lab will be watching to see if there are additional reports of this issue.

BlueSteel and LeTigre Release Candidate Channels

Maestro Linden likes to work-out during meetings
Maestro Linden likes to work-out during meetings

On Wednesday June 12th BlueSteel and LeTigre initially received a new server maintenance project to fix a number of crash modes, addresses an issue with neighbouring region visibility, and which added new adds new LSL pathfinding capabilities and object return capabilities.

However, soon after deployment, an issue was found on BlueSteel / LeTigre regions – Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry), which resulted in a rollback which saw BlueSteel and LeTigre updated with the Magnum release package.

“it turned out that if a parcel allowed build but disallowed object entry for your avatar, then your avatar would not be able to rez from agent inventory into the parcel,” Maestro explained at the Server Beta meeting on Thursday June 13th, “And your scripted objects (like the pop-gun) would also be unable to rez. Also, Lucia [Nightfire] reported a tangential issue, which was that rezzing in some group-owned parcels required your avatar to have the parcel’s group active, which is not usually a requirement. These bugs were bad enough that … we rolled BS and LT to the same version as Magnum.”

Fixes are underway for this issue, but it is currently not known if they will be ready for next week’s deployments.

Object Return Capabilities Update

Prior to the rollback on BlueSteel and LeTigre, an issue was noted with the llReturnObjectsByID function, resulting in the function being disabled server-side. “It should be (probably) re-enabled with the next release of that code,” Kelly Linden noted. “However it will have a new limitation – it will no longer be able to return objects owned by the parcel owner.”

“We were concerned about a potential griefing vector if a parcel owner absent-mindedly grants the permission,” Maestro added.

I’ve updated my overview of the new capabilities to reflect this change.

Continue reading “SL projects update week 24 (4): server release update” →

SL projects update 24 (3): New object return LSL capabilities

Posted on by Inara Pey

Update June 12th, 22:40 BST/14:40 SLT: The BlueSteel  / LeTigre deployment which includes these capabilities has been rolled back due to an issue whereby objects cannot be rezzed in BlueSteel / LeTigre parcels which disallow object entry (even if Create Objects is enabled) – BUG-2850. Both regions are now running the week 24 Magnum deployment.

In week 23, Kelly Linden announced new LSL capabilities for the scripted return of objects within a region / parcel.  In making the announcement, he indicated the capabilities would be available “some time in the future”, a comment which appears to have been a little overly cautious, as the new functionality received its first outing on the Main channel in the RC deployments to BlueSteel and Le Tigre on Wednesday June 12th.

The new object return functions are llReturnObjectsByOwner and llReturnObjectsByID, and are designed to be used to enable the automated return of specified linksets to their owners.

The object containing scripts using the functions can either be placed in the land, or worn as an attachment but will only work on land held by the object owner.

The primary aim of these functions is to make for easier clearing of private sandboxes and rental parcels in cases where previous users / tenants may have left objects behind on leaving (thus removing the onus on the land owner to locate and manually return items).  They are not intended as anti-griefing tools, nor are they a “replacement” for the parcel / region auto-return functions.

The Functions

The functions are defined within the BlueSteel and LeTigre release notes as follows:

Additional Notes and Q&A On Capabilities / Limitations

There are also some additional notes which go with the new functions:

  • There are no cases where one of these new LSL calls would return an object that you could not manually return yourself
  • The functions will only work on objects in the same region/parcel as the object containing the script using them. Objects which are returned are coalesced in the recipient’s inventory, rather than being returned as individual objects
  • The functions work if and only if the user would have permission to return the object via the viewer, and it does not handle encroachment
  • To prevent severely damaging accidents the mass returns by owner (llReturnObjectsByOwner) will not work for your own items, items owned by an estate owner or manager or items that are owned by the group the land is ‘set’ to
  • llReturnObjectsByID will not return objects owned by the parcel owner
  • In order to work on group-owned land the object containing the script using the functions must be deeded to the group by the group owner
  • The return capabilities are throttled to a maximum hourly quota based on a parcel’s Land Capacity (under About Land > Object). So, if your Land Capacity is 500, then using these LSL functions you can return up to 500 linksets per hour
    • The throttle is there primarily to prevent a silent war between a rezzer and returner that could impact the back-end servers
    • Even with the throttling, it is anticipated that the functions should be able to return everything on your land within a region in one go, but not necessarily more than once an hour for large-scale returns.

Continue reading “SL projects update 24 (3): New object return LSL capabilities” →