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.
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.
Update May 14th: Speaking at the Simulator User Group meeting on May 1tth (transcript), Falcon Linden confirmed that under the new mesh accounting system, sculpts will be capped at 2: [16:43] Falcon Linden: Namely that sculpts will be capped at 2.0 streaming cost, not 1.0. (Note, that’s a CAP, so if they were less than 2.0 in new accounting before, they’ll still be less than 2.0).
Nalates Uirriah caries more on the proposed Land Impact changes which look as if they will be implemented as a part of Pathfinding – and the news carries something of a possible warning.
While the new accounting system promises to offer benefits with regards to prims, and help encourage scripting efficiency within rezzed linksets, just how it will impact sculpties is unclear.
Sculpts have always been something of a problem-in-waiting since their introduction. Like complex prims (tori, etc.), sculpts were given the same “impact” cost as “regular” prims under the old accounting (prim count) system. So wither you rezzed a cube, a torus or sculpt, they all had an impact of 1. However, like mesh, sculpts are more complex than regular prims and could be said to be somewhat more complex than tori in terms of their download weight due to the need for a texture and a sculpt map to be downloaded and applied to the object.
When Land Impact (initially PE, or Prim Equivalence at the time) was introduced, sculpts continued to be treated as prims – although from comments made at the time, it was evident that, at least on technical grounds, some Linden Lab staff were unhappy with this. However, it is hard to see how the accounting system could have been adjusted to account for the extra “cost” of sculpt without causing mass upset and potentially some breakage across the grid.
The new accounting system that has been proposed, and was revealed in part last week by Falcon Linden as Nalates reported, is specifically to be applied to “legacy prims”. However, whether sculpts are to be classed as “legacy prims”, it would appear, is still a matter to be determined within the Lab.
Speaking at Monday’s Content Creation Group meeting, Nyx Linden had the following to say on the proposed changes:
“The proposed streaming cost cap, if implemented and deployed (nothing is final until it is released), would affect legacy prims – streaming cost of meshes would not be capped. It would affect legacy prims even if they are linked to meshes (and thus fall under the new accounting system). Please note that this is a proposal, and we reserve the right to change any part of it if necessary before release.
“Whether sculpties will be considered “legacy” or not in this context is not 100% determined yet. Since they do require more texture data to display properly, we need to carefully consider exactly how to weight them. The proposed server cost change would be independent of prim type. It’s still in the early stages so bear with us if we end up needing to make tweaks between now and release, but we wanted to let everyone know that changes would be coming.”
After noting that the new accounting process will also be used for linksets using the new physics shape types as well as those containing meshes, Nyx concludes:
“I don’t want to speculate as to the exact status of sculpties under the new streaming cost rules, as we’re still discussing it internally, but your concerns are being considered when looking at the numbers and algorithms.”
The problem here of course is that LL are once again in something of a corner. Altering the impact cost of sculpts is going to have potentially far-reaching effects which are unlikely to be seen as positive. It may even negate the changes being made to llVolumeDetect(TRUE), given this hack is often used in linksets involving sculpts. At the same time, and has been pointed out by Chalice Yao, sculpts could be considered tori, so treating them as legacy prims would make the new accounting system even more worthwhile.
Similarly, Qie Niangao points out that currently, the LI calculations are somewhat biased with regards to mesh:
Yes, but on the other hand, the LI calculations are terrifically generous to Mesh content for exactly the reason that Nyx (bizarrely) mentions as a problem with sculpties: extra textures. Although it’s true that a sculpt necessarily involves a sculptmap as well as a (single) surface texture, a single Mesh can have eight 1024×1024 textures and still get a 0.5 land impact.
It is clear that things are in a state of flux – and that LL are considering options and concerns. Overall, the proposed changes are being regarded as being favourable to all at this time where script costs are concerned. Whether this remains the case will be dependent on what – if anything – needs to be changed in order to handle sculpts.
There are a couple of changes in the works relating to the forthcoming arrival of Pathfinding in Second Life.
llVolumeDetect(TRUE) Exploit
In the first, the use of llVolumeDetect(TRUE) to create partially phantom linksets will no longer work. Always something of a system exploit / hack, this approach has nevertheless seen widespread use across SL in buildings and vehicles. So much so that when it was discovered that the hack no longer worked in the Pathfainding test regions, it was initially reported on the JIRA as a Pathfinding bug (Pathbug-69).
Thanks for your interest and passionate comments. First, let me address one of the root issues here: reliance on undocumented behavior that is known to be a bug. I realize that there are many cases of this in SL. I also realize that all of us, as game developers either in RL or SL, will do whatever it takes to implement a feature we want, even if that means exploiting known bugs or idiosyncrasies. The problem is that continued development of a platform (e.g., SL) often precludes backwards compatibility, particularly when systems have exploited “micro details” of the platform.
Which is not to say Linden Lab is unsympathetic to the issue. Far from it; as in the same statement Falcon goes on to explain:
All of that being said, we as SL developers continue to try to preserve backward compatibility where we can. In this case, I have been able to find a compromise between new features and existing content. Here’s how it will work:
1) If a linkset uses the hack and also uses new accounting (aka mesh accounting or land impact), the first time it is rezzed on a pathfinding sim the hacked prim will be set to physics shape type none. Since the linkset already uses new accounting, this will not negatively impact land impact (in fact, it might reduce your land impact). It may affect a small amount of content that relies on link number of higher numbered prims in collision events by way of llDetectedLinkNumber()
2) If a linkset uses the hack and does NOT use new accounting, the relevant prims will be modified such that they collide only with the terrain. Other than that, behavior should be unchanged. This may impact some land vehicles that previously had hacked phantom prims which did not collide with the terrain.
3) No new linksets can be created that use the hack, and any linking or unlinking event (other than seating an avatar) will remove the hack on existing content.
This should address most of the concerns here. In the future, to create content where only some prims are involved in physics collisions, you will have to use the physics shape type feature.
Ergo, while the arrival of Pathfinding will herald a closure of the llVolumeDetect(TRUE) exploit / hack, LL are attempting to ensure that the impact of the closure in terms of content breakage will be minimal – if it is noticed at all.
Changes to Land Impact Calculations
Coupled to the above change is the announcement that Linden Lab is looking into changing how Land Impact is calculated as a part of the overall Pathfinding roll-out. Nalates Urriah was the first to break the news on the proposal, which will bring a greater degree of granularity to Land Impact increases.
Under the current system, adding scripts to linksets can result in a sudden (and sometimes dramatic) leap in the Land Impact value. With the proposed changes, this will no longer be the case, with changes resulting from the use of scripts being more gradual. Speaking at the Simulator User Group meeting attended by Nalates, Falcon Linden explains the proposed changes thus:
[17:00] Falcon Linden: Changes to Land Impact that you’ll actually like for a change!
[17:01] Falcon Linden: We’re changing streaming cost for prims to be capped at 1.0 and we’re changing server weight to be: 0.5 * num_prims + (0.25 * num_scripts) but capped at num_prims
[17:01] Falcon Linden: so instead of going from half prim count to prim count by adding one script, it will be a more gradual change to encourage fewer scripts
[17:01] Falcon Linden: right now it’s not capped
[17:03] Falcon Linden: okay
[17:03] Falcon Linden: here we go
[17:03] Falcon Linden: I have here a linkset of three distorted torii
[17:03] Falcon Linden: The two child prims are shape type NONE and the root is convex hull
[17:04] Falcon Linden: under the current scheme, its download weight is 13.7, its physics weight is 1.6 and its server weight is 1.5
[17:04] Falcon Linden: total LI 14
[17:04] Falcon Linden: under the new scheme, download weight will be 3, the other weights will be the same in this case, and the overall LI will be 3
[17:05] Falcon Linden: if I add one script to it now, the server weight will go from 1.5 to 3.
[17:05] Falcon Linden: In the new scheme it will go from 1.5 to 1.75.
It should be noted that the latter change is still very much a proposal, although it does appear that it is more than likely to go ahead, given it is beneficial to both Pathfinding and the platform as a whole.
With the Linden Wilderness experience opening to demonstrate pathfinding capabilities, word hasn’t spread too widely concerning a call for region owners to volunteer for a pathfinding beta on the main grid.
[16:39] Falcon Linden: (3) There will be an Agni beta for pathfinding in the coming weeks. The beta will only be open to region owners (though once pathfinding is released gridwide, it will not require you to own a region to use it). If you are interested, please e-mail pathfinding-beta@lindenlab.com
No further details are supplied, but any region owners who are interested should follow-up with an e-mail.
The pathfinding tools themselves are now available through an Alternate Viewer (scroll to Pathfinding), which can be used by anyone with an interest in pathfinding when used in conjunction with the pathfinding enabled regions on the Beta grid (Aditi):
The easiest way of reaching these is to log-in to Aditi and use the World Map to locate the PathTest regions.
One of the PathTest regions on Aditi
Details on the tools themselves can be found on the (in development) pathfinding page of the SL wiki.
There is apparently going to be a Pathfinding User Group starting in the near future. Keep an eye on the UG listings page (or possibly the main pathfinding page of the wiki) if interested.
With thanks to Ciaran Laval for the pointer to the Simulator Group meeting transcript.
Inara Pey: Living in a Modemworld 