Changing Object Attributes
Object attributes are set through the Linksets floater of the pathfinding tools, and details can be found in the Pathfinding Quick Start Guide and the Visual Guide to Pathfinding.
Attributes can also be set universally for a region using the console command update-pathfinding-objects. This can be used to globally set an attribute against all unscripted or all scripted or all scripted and unscripted objects in a region. This command should be used with care, and only after the instructions have been understood, as it is theoretically possible to permanently break certain scripted objects.
The viewer pathfinding tools include a Navmesh View / Test floater. The View tab in this floater allows the navmesh and the attributes applied to objects to be easily visualised. Object attributes are colour-coded (so that Static Objects are coloured red, for example), and are independently selectable so you can view the navmesh Walkables, or the Static Objects or the Exclusion Volumes or the Material Volumes within a region, or any combination thereof. Note that objects set to Moveable Obstacle or Moveable Phantom are not visible in the navmesh view, except where the navmesh is being overlaid on the normal world view.

Visualising the navmesh: overlaid with the world view (t) and on its own, showing Walkable and Static objects (b)
Characters, LSL Functions, the Modular Pathfinding Kit and Scripts
There are a number of LSL functions linked to the creation of pathfinding characters, together with a Modular Pathfinding Kit which can be used to help with the creation of pathfinding creatures. In addition, LL have written a number of debug scripts which can be used to assist with the creation of pathfinding characters:
- llWanderWithin_debugging - for simple wandering characters
- llPatrolPoints_debugging - for characters following a set coordinate path
- llFlee_debugging - for characters that avoid avatars
- Path_update_debugging -For path_update events
When creating a character, there are a number of points to remember:
- Pathfinding does not provide a way to animate characters. Instead, existing methods to animate characters must be used. For information on animating characters, please see Animation and Animation Streamlined in the SL wiki.
- Pathfinding does enable more dynamic movement and provides a better system for controlling character movement than was previously possible.
- Characters cannot be used as attachments (so no pathfinding cat sitting on your shoulder!)
- Characters are incompatible with some features, such as keyframed motion, being phantom, size changes, and others.
The pathfinding tools within the viewer provide a Characters floater that can be used to locate characters moving throughout a region and to identify the CPU cost of characters affecting the performance of a region.
Console Commands
Pathfinding includes a number of console commands which can be used via the region debug console (CTRL+SHIFT+~ or Develop -> UI -> Region Debug Console). These are:
- update-pathfinding-objects (see Objects and the Navmesh, above)
- set dynamic_pathfinding false – will disable pathfinding for a region
- set dynamic_pathfinding true – will enable pathfinding for a region
Notes:
- These commands can only be used by estate owners / estate managers
- set dynamic_pathfinding_false and set dynamic_pathfinding true will require a region restart to takes effect
- Disabling pathfinding does not alter the physics of a region; all it does is disable the navmesh and the ability of pathfinding characters to use the region
- Once pathfinding has been disabled for a region, it will remain disabled through all subsequent server roll-outs (including those with further pathfinding updates) until actively re-enabled by the estate owner / manager, or Linden Lab explicitly override the disabled setting.
Land Impact Accounting System
Pathfinding introduces a modified land impact accounting system which changes prim accounting for legacy prims:
- All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects.
- Server cost will be adjusted to MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }. This preserves the current value for unscripted linksets and reduce the cost for linksets containing fewer than 2*num_prims scripts. It provides the benefit of rewarding creators for reducing the number of scripts in their objects.
Nalates Urriah provides a more in-depth explanation of these changes.
Issues, JIRA and Bugs
There is a range of known issues and bugs around pathfinding which are still in the process of being resolved. The Release Notes highlight the following issues:
- The collision pipeline has been reorganized. This may affect avatar collisions/control, vehicle movement, and collision callbacks in LSL scripts.
- The terrain collision shape has been changed from a “heightfield” to a “mesh” to provide more efficient collisions, ray-trace, and navmesh computations.
- This may change some collision details. In particular see the “Known Issues” list below.
- When changing the terrain its visible appearance will update immediately, but its collision shape will not.
- The server will wait at least 10 seconds since the last change before computing the new shape, and the computation time may take several seconds.
- Where there is a discrepancy between visible and colliding terrain shapes object and avatar collisions may appear incorrect.
In addition, the following JIRA related to pathfinding have yet to be resolved:
- Vehicles being very iratic and jittery
- Physical Objects Fall Through Terrain Mesh
- Invalid force in llApplyRotationalImpulse bug
- Hacked mixed volumedetect linksets become non-phantom after the region is rolled back from pathfinding to a non-pathfinding version
- llUnSit() moves avatar to incorrect position (a clamped object_position + sit_target) if object_position + sit_target is outside the sim boundaries and the sat-upon object is rotated
- Linking a flexi prim as a child of a non-flexi causes the flexi prim to go non-phantom (PATH-796 - not open to public viewing)
Resources
- SL wiki pathfinding overview
- Pathfinding Tools in the SL Viewer
- What is the NavMesh?
- Pathfinding “Quick Start” guide
- Visual Guide to Pathfinding
- LSL pathfinding functions
- Modular Pathfinding Kit
- Pathfinding scripts (to assist with the creation of pathfinding characters)
- Pathfinding Release Notes
- In addition, the following may be of use:
Related Links
- Pathfinding Performance - Nalates Urriah – dealing with misconceptions about performance impacts with pathfinding)
- Pathfinding and prim accounting Nalates Urriah – coverage of the accounting changes
- llVolumeDetect(True) and Land Impact Changes - the issue that prompted further revision of land impact accounting


“All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0).”
(drumming fingers) Why do I get the feeling that’s going to result in the most interesting screaming on the forums and blogs?
Because that’s got the hair on the back of my neck twitching.
-ls/cm
I’m no expert on this. Nalates has a good article on the accounting system (linked-yo in the section of my article above). However, if I’m understanding this aright:
The new accounting system was in part to stop people using the llVolumeDetect hack to phantom child prims (particularly sculpties) due it causing problems with pathfinding (PRIM_PHYSICS_SHAPE_NONE should be used).
As reported here, there are some issues around tortured prims, sculpts and the used of physics shapes, but in terms of the comment from LL meaning that sculpts in and of themselves are suddenly going to jump in land impact…no. You should be able to test that for yourself on your own land. I’ve certainly seen nothing untowards on mine – and I’ve been on Magnum during the beta as well (althoug, I’ve been fortunate, not even had a single vehicle issue, either…).
My uneducated understand is that the prims 1, sculpts 2 is more an issue with *physical* objects set as physics type, convex hull. I’ve not seen a shift in prim accounting since yesterday on Livintreee.
Pingback: WHAT IS THIS CRAP? » Double, double toil and trouble…
Pingback: Pathfinding: The Long View | Telling: Like it Is
Pingback: Pathfinding Vehicle Fixes