Server roll-outs w/c 30th July

Oskar has issued a notification of the planned server roll-outs for this week. As they currently stand, the roll-out will comprise:

Main Channel: Sever release 12.07.24.262437 – Tuesday 31st July

This should see a further roll-out of the LSL functions related to the Advanced Creator Tools. This release will see the addition of three new LSL functions:

These new LSL functions work with the current runtime permissions system, and are precursor to future work with experience permissions. More information about the runtime permission is here:PERMISSION_TELEPORT.

This is a roll-out of the code deployed to LeTigre and BlueSteel last week. As with both of those channels last week, the code will be enabled on the main channel regions following the deploy (although LL retain the capability to disable it).

Magnum RC: Further Pathfinding Roll-out – Wednesday August 1st

Roll-out due to commence: 07:00 SLT

A further roll-out of the server-side pathfinding code, with fixes. Currently the wiki notes for this channel appear to be stalled on the 12.07.24.262484 release.

Note that the viewer-side pathfinding tools are now available in the latest Development Viewer.

BlueSteel RC – Wednesday August 1st

Re-start due to commence: 08:30 SLT

There are no changes to this channel. It will have the same code as the main channel.

LeTigre RC: Infrastructure Project update – Wednesday August 1st

Roll-out due to commence: 09:30 SLT

Oskar comments: “This channel will have an infrastructure project that has no intentional changes to existing behaviour. There are perhaps unintentional changes to existing behaviour. If you find some please let us know!”

SL Server roll-outs: creator tools and pathfinding

Update July 18th: The Magnum RC roll-out has been delayed until Thursday July 19th. Oskar may supply a reason on the deployment thread in the forums – keep an eye on that for updates (with thanks to Wolf Baginski).

Main Channel Release

Tuesday 17th July sees the a roll-out of LSL functions related to the Advanced Creator Tools. This release will see the addition of three new LSL functions (comments taken from the release notes):

  • llAttachToAvatarTemp(integer attach_point): Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. The user is ‘automatically’ made the owner of the object. Temporary attached items cannot use the llTeleportAgent or llTeleportAgentGlobalCoords LSL functions
  • llTeleportAgent(key agent_uuid, string lm_name, vector landing_point, vector look_at_point): Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory. This function cannot be used in a script in an object attached using llAttachToAvatarTemp
  • llTeleportAgentGlobalCoords(key avatar, vector global_coordinates, vector region_coordinates, vector: Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS). This function cannot be used in a script in an object attached using llAttachToAvatarTemp.

The new LSL functions work with the current runtime permissions system and are precursor to future work with experience permissions. More information about the runtime permission is here:PERMISSION_TELEPORT.

The keen-eyed will note that these are the functions that were rolled-out to the Magnum RC channel in May, and which were subsequently abused for griefing purposes. However, Linden Lab have added a new capability to the functions  – what is described as an “on / off” switch which is available only to Linden Lab personnel, and which allows the functions to be enabled  / disabled (the functions were also rolled-out to the Le Tigre RC on July 11th with the “on / off” switch capability). As the release notes make clear, the functions are disabled by default in the roll-out, and will presumably remain that way until such time as the updated permissions system has been rolled-out.

The release also includes three bug fixes (again, as specified in the release notes):

  • SCR-342: llTeleportAgent() does not fail gracefully when specifying an invalid landmark name
  • SVC-7966: Magnum RC, llTeleportAgent gives a wrong message
  • SVC-7987: llTeleportAgent always points in the positive Y direction on teleport.

Pathfinding release: Magnum and Le Tigre

On Wednesday 18th July, the Magnum RC will get a further roll of the pathfinding code and Le Tigre will apparently get the same code as well. At the time of writing, the actual release note pages on the SL wiki for Magnum and Le Tigre still reflected the releases for July 11th and the forum post announcing the release did not show any specific changes from the forum post relating to the July 11th release. Any alternations which may have been made following the difficulties some initially encountered on the Magnum RC following that roll-out are therefore hard to identify. This ma change prior to the actual roll-out.

Related Links

Pathfinding: Magnum RC roll-out, viewer tools and more

Pathfinding is drawing closer to a release across the main grid, and preparation work for the roll-out – which will constitute one of the biggest changes to SL – is underway on several fronts. This article is intended to be a high-level update on various elements of the project, gleaned from a variety of sources.

Magnum RC Roll-out

On Wednesday July 11th, the server-side pathfinding code was rolled-out to the Magnum Release Channel. There had been some predictions that this could lead to significant problems and issues as a result of the issues given within the release notes

Following the release, issues were experienced, notably with mesh vehicles, as reported on the forum thread discussing the releases for the week, and which have been rapidly responded to by Linden Lab personnel. there are still concerns around the roll-out and potential impact, and Linden Lab are continuing to monitor.

In discussing the RC toll-out at the TPV/Developer meeting held on Friday July 13th, Lorca Linden, the Associate Producer responsible for the project, commented: “OK, so pathfinding did go in RC on Magnum on Wednesday [July 11th]. As a whole, things are looking really, really good. We’re seeing very few crashes, the performance is working great we are seeing issues with some vehicles – definitely not all. That’s the only major hitch that we’re looking into, but as a whole the RC has been going quite smoothly.”

New Viewer Tools

As mentioned above, Lorca Linden (together with Stinson Linden and Prep Linden) from the pathfinding project attended the Friday TPV/Developer meeting on the 13th July, where they specifically discussed the viewer-side pathfinding tools. The tools are covered in detail in a new wiki page from Linden Lab, and may already be familiar to those who have been working on the pathfinding beta. They are currently in the Pathfinding Project Viewer, and will need to be incorporated in to TPVs as well. The wiki page provides comprehensive notes on the tools, complete with screen shots; the following in intended to provide a high-level summary and some background notes for those unfamiliar with the core elements of pathfinding, and to provide an overview of what this means for viewers going forward.

Navmesh and the Rebake Tool

For those not familiar with the term, navmesh is short for navigation mesh. This is a representation of a region’s geometry generated and used by the physics simulator to determine paths for pathfinding characters. The navmesh can be somewhat fluid in nature, depending upon what is going on in a region and what is being changed; a new path for a character, for example, will change a region’s navmesh. When this happens, the navmesh for the region needs to be updated, which can take some six hours  if left to update automatically.

To overcome this when pathfinding is rolled out, one of the new tools that will be appearing in the viewer will be a Rebake Region button. This will automatically appear at the bottom of the viewer window of all users within a region when the navmesh requires updating – regardless as to who may actually have altered the navmesh.

Rebake region button for navmesh updates (with thanks to Linden Lab)

Once baking has commenced, the button will fade on all viewers on which is displayed, indicating that an update is in progress (and preventing someone else from initiating a rebake). Once the rebake is complete and the navmesh is updated, the button will vanish from viewers.

Object Attribute Tools

By default, a navmesh treats all resident-made objects within the region in which it is active as obstacles that pathfinding characters must manoeuvre around. Obviously, this may not always be the case; there will be objects (e.g. stairs, ramps, sidewalks, floors, etc.), pathfinding characters need to traverse, climb, etc. This is achieved by altering the pathfinding atrributes associated with an object, and some of the new viewer tools are to allow this to be done and to also allow users to examine in-world objects to determine their status vis-a-vis pathfinding and how pathfinding characters will react to them.

These tools take the form of menu options and additional panels located in the Build and Object Profile floaters.

Dedicated Floaters

Also included in the tools are three dedicated pathfinding floater panels:

  • Linsket floater: designed to give advanced users and builders the ability to customize an area to achieve interesting effects with pathfinding-enabled characters
  • Character floater: designed primarily to help users to locate characters moving throughout a region and to identify the CPU cost of characters affecting the performance of a region
  • View / Test floater: intended for advanced users who are building pathfinding-enabled objects and characters.
Pathfinding characters floater (with thanks to Linden Lab)

Tool Status and TPV Integration

As mentioned above, these tools are all currently available in a Project Viewer. However, it is anticipated that they will be appearing in a Linden Lab beta viewer in “one to two weeks” (Lorca Linden). The tools themselves are regarded as feature complete by LL, and Lorca encouraged TPV developers at the meeting to consider integrating them into their viewers sooner rather than later.

Integrating the new tools in TPVs is liable to be in two parts:

  • An initial release containing the tools required for setting object attributes, etc.
  • A follow-up release incorporating the use of the Havok libraries Linden Lab is establishing and which will be made available under the new sub-licence arrangement.

The reasons for this are two-fold:

  • The attribute tools, etc., are vital for optimising pathfinding within regions and ensuring everything works correctly (e.g. to ensure pathfinding characters can climb the stairs they’re supposed to by climbing or walk along the prim sidewalk they are supposed to walk along, etc.
  • The Havok libraries are not yet available, although Oz hopes to have them in a position where he can talk in more detail to TPVs about them “pretty soon”, and while it is nice to be able to visualise the navmesh, etc., it is not quite such vital part of the pathfinding process.

Universal Tools

Alongside the viewer tools, pathfinding will see a set of universal tools rolled-out in console format. These will be available to region owners and estate managers and will allow them to change an entire class of object in a region to have certain pathfinding attributes once pathfinding goes live. Linden Lab are approaching this in terms of having all non-scripted objects set them to be static obstacles that pathfinding characters must manoeuvre around, while anything that is scripted is set to “dynamic”, as it is thought to be moving.

This obviously doesn’t fit all cases – vendor boards, for example are scripted, but they are hardly what can be termed “moving” objects. Indeed, it might be argued that the majority of scripted objects within a region are non-moving, and therefore should have their pathfinding attribute set to “static”. However, LL feel they have no way of easily differentiating between a non-moving scripted object and a moving scripted object, and thus feel that setting all scripted objects to “dynamic” is the better option and allowing the attribute to then be modified through the viewer where necessary, as setting them to “static” could result in a worse overall behaviour case within a region.

Other Tools and Items

Alongside the above, Linden Lab have previously indicated that they will be making the following available as pathfinding rolls-out:

  • A set of script templates used for the creatures found in the Wilderness areas
  • A script for a “master rezzer system”.

The latter is a means by which region performance and the number of pathfinding characters rezzed in the region can be monitored, and which will reduce the number of pathfinding characters within a region in response to the region’s performance / number of avatars within the region.

Potential Timescales for Roll-out

During the TPV/Developer’s meeting, Lorca outlined some potential dates for pathfinding. note that these are currently potential, and shouldn’t be taken as tablets of stone:

  • The pathfinding tools should be available in one to two weeks in a beta viewer
  • The server-side release is dependent upon how well (or otherwise) the current release to the Magnum RC progresses, and may potentially come within the next two-to-four weeks, but certainly no sooner than two weeks.

Again these are not confirmed dates, and may well change in the next couple of weeks – particularly if major issues are found with the Magnum RC roll-out.

Related Links

User Experience Tools: initial roll-out to Magnum RC

Today sees the first phase in rolling-out the new User Experience tools to the Main grid. As noted in the official release notes, the tools have been rolled-out to the Magnum Release Channel.

The new tools were previewed back in March in a rare SL blog post, which I covered at the time it was released. Today’s Magnum release adds three new LSL functions for User Experience:

  • llAttachToAvatarTemp (integer attach_point) — Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. Additionally, if this function is used with experience permissions, the user is ‘automatically’ made the owner of the object. If you use this function without the experience permission, the target MUST be the owner of the object for it to attach properly
  • llTeleportAgent (key agent_uuid, string lm_name, vector landing_point, vector look_at_point) — Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory
  • llTeleportAgentGlobalCoords (key avatar, vector global_coordinates, vector region_coordinates, vector look_at) — Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS).

This initial roll-out does not include the expanded Experience Permissions System, as Oskar Linden points out in a forum post on this week’s server releases. Instead, the new functions work with the current runtime permissions system (specifically PERMISSION_TELEPORT), although plans are in-hand to roll-out the new permissions systme at some point in the future.

No details have yet been released on the Professional Creators Programme that was mentioned in the original preview blog post, but if you are interested in learning more about the tools, the Advanced Creator Tools Notification Group is still open to membership, and you are encouraged to join the Group.

Oskar notes that LL will be actively monitoring the forum thread announcing the roll-out, and anyone encountering issues with the new functions is encouraged to post feedback in the thread, cross-referencing any relevant JIRA they raise.

Given the functions are now on the Magnum RC, and people are being encouraged to provide feedback, this roll-out would appear to move the User Experience tools outside of the associated Closed Beta programme.

For ease of reference, here’s the video LL released with the original preview announcement:

Related Links

Linden Lab roll-out Region Idling

Simon Linden has posted to the Server topic area of the technology forum about a new SL server feature, “region idling” which commences today, Wednesday 16th May.

This will see those regions that do not have any avatars either in them or camming into them to lower their frame rates and script processing, thus reducing their load on their host CPU. This should in turn improve the performance of the other regions running on the same hardware.

The idling itself should be entirely transparent to users, with the region immediately returning to “full speed” should anyone enter the region or cam into it. However, Simon does warn of a possible caveat to the transparency:

We expect this feature to be totally transparent to users. Residents will not see or be on regions that are idling. Scripts, however, may observe the effect if they are using the llGetRegionTimeDilation() function, and may require fixing.

There are some additional points to note with this capability, which are addressed in an FAQ also posted to the forum.  These include:

  • Regions are not turned off or shut down. They merely run at a slower frame rate when nobody is there. They will appear exactly the same way as before in search, the world map and other Second Life features
  • Region idling cannot be manually disabled for a region
  • Any scripts that use LSL network functions will suspend region idling for a short period of time to allow them to function normally.  This will allow scripts that connect to outside services via email, http and xmlrpc to run as expected.

The roll-out of the function will commence with the Blue Steel release channel, and will then be progressively rolled-out to the rest of the grid in the coming weeks. Anyone suspecting region idling is having an adverse effect on their region is requested to file a JIRA (no specific project given), providing clear information on the problem and the exact times it happened.

Related Links

Mesh: the roll-out

[POSTED 8:22PM PDT Aug 22, 2011] Rolling restarts for regions on the main Second Life server channel will be performed on Tuesday, August 23rd at approximately 5:00am PDT. Please make sure to save all builds and refrain from making purchases during this time.

Mesh: transformative? (w/thanks for Claudia222 Jewell)

With this simple notice, mesh commenced its roll-out to the remaining portion of the Main gird that has yet to see it (approximately 70%), as per the server release notes.So, assuming all goes well, the entire Main grid will be mesh enabled from today.

This isn’t the end of the mesh project, but really the beginning; thing’s are going to suddenly change overnight – it’s going to take time for mesh to make its presence felt, and as Linden Lab themselves admit, there will be further updates, revisions and improvements ahead.

As a result of this, we can doubtless expect the Beta “Viewer 3” to go to full release status shortly (if not today as well), which brings with it mesh support with some added features. Please see the update at the end of this article.

For those wishing to see mesh, issues still remain: the code for rendering mesh objects has yet to be incorporated into a number of third-party 2.x Viewers, and it unclear as to whether the code can be backported into the 1.x code.

In the meantime – a video from rockerfaerie featuring some of Claudia222 Jewell’s remarkable mesh art.

Updates

At 1300 SLT Nyx Linden confirmed the following:

  • All channels of the Main grid now support mesh except the BlueSteel RC channel (which one assumes will get mesh during the RC channel restarts on Wednesday 24th August)
  • The Default official Viewer is now Viewer 3 (currently 3.0.0.238864)

More on Mesh

Update 25th August

The “additional feature” referred to in this article was the ability to disable mesh rendering in a region. However, in commenting on a JIRA raised in relation to the capability, Charlar Linden stated:

Charlar Linden updated SH-2341:Status: Expected Behavior  (was: Open)   Resolution: Not Applicable – thanks – this flag would have no effect, and is being removed soon.

So it would appear the option to disable mesh is not intended to be a part of the Viewer.