This page is incomplete! You can contribute information using GitHub issues or pull requests.
Halo 2 uses an automatically generated pathfinding mesh using the collision mesh of the BSP as the base. It takes this mesh and adds scenery and instance geometry collision meshes. It then removes any faces that have a slope greater than 45 degrees (and therefore not considered walkable) and then optimises the mesh so it's only made up of convex sectors and uses the minimum number of sectors possible. This is a rather complicated process and somewhat fragile - it will fail if the BSP has any open edges. See figures 1-4 for examples.
As a level designer/map maker you have limited control over the whole process. There are some settings for the generator but most are not user facing and are likely only meant to be tweaked by developers that understand the whole process.
The main setting you control as a map maker is the pathfinding policy used by scenery objects.
Used by device machines and the like. All surfaces are included in the mesh.
The object will be "cut-out" from the pathfinding mesh. AI will not be able to walk on or over the object but will be able to navigate around this. This is a reasonable choice most objects in the playable area.
The object will be added to the pathfinding mesh. AI will be able to walk on it. Use this for large objects AI might end up on.
The object will be ignored by the pathfinding system. It will not affect the mesh. Can be used for objects that won't imped the AI or objects outside the playable area.
The pathfinding mesh just tells the AI where it can walk and possible paths between two points. To do anything more "intelligent" like dropping down from a ledge or climbing over an obstacle.
Many hints are autogenerated but they can also be placed manually using Sapien. You can render manually placed hints (often called user hints) using
ai_render_user_hints 1 or by selecting that hint type in the hierarchy (under AI ⇒ Pathfinding data ⇒ Hints) which will also let you edit them.
Automatically generated hints can be viewed using
Used by some crates use hints. These aren't configured through the scenario/BSP like the other hints are work somewhat differently. They are defined by the object. Like other hints they help the AI navigate the environment by allowing them to climb onto the crate, etc. You can render the "active" object hints using
ai_render_object_hints 1. If you want to see all the hints the engine can use then use
Here is a listing of the types of hints AI can use..
hint_bunker hint_corner_left hint_corner_right hint_vault_crouch hint_mount_crouch hint_hoist_crouch hint_hoist_stand
- Bunker - Hides behind object for cover and shoots over.
- Corner - Hides at a corner of the object for cover.
- Vault - Jumps over the object.When debugging hints these will be marked with the letter V colored green.
- Mount - Jumps on top of the object. When debugging hints these will be marked with the letter M colored orange.
- Hoist - Climbs on object. When debugging hints these will be marked with the letter H colored in blue.
Each hint will also have an assigned height for the action. Bunker and corner hints are excluded from this:
- Crouch - Use crouch animations for a medium sized object. Applies to vault, mount, and hoist.
- Stand - Use standing animations for a large sized object. Applies to hoist only.
You can find the set world units for crouch and stand in the
AI Globals tag block in the
Pathfinding edges can be rendered using
ai_render_sectors 1, this should give you an idea of how complex the pathfinding mesh is but doesn't actually tell you that much. You can render more information about which sector is where using
You can see what path (if any) an AI would take using the structure data ⇒ pathfinding debug hierarchy entry. Use the left and right click to select start and end points respectively. If no path can be found the reason will be printed on screen. If the distance is too long the whole path wouldn't be rendered but some of it will be and the on-screen message will inform you that it was able to find a path.
If you have any instances or scenery that use cutout you need to ensure they actually intersect with the BSP, otherwise they wouldn't get cutout and pathfinding system wouldn't be aware of them.
If you want to find sectors that have pathfinding but aren't marked as walkable you can use
ai_render_non_walkable_sectors 1. This is somewhat of a misnomer as it seems to only mark floor sectors that are non-walkable not all non-walkable sectors.
A complex pathfinding can cause issues for AI - it's better for the mesh to be as simple as possible. Long and narrow sectors are a common issue, these can make the AI move in a weird way when navigating in their vicinity. If there is a particularly problematic area/junction you can use a cookie cutter of the appropriate size to remove it. Don't over-use this or make the cutter too large as cookie cutters remove the pathfinding and that can cause it's own issues. In general well optimised collision geometry should generate good collision geometry.
The scenery tag defines the default pathfinding policy for a scenery object. Set this to whatever is most reasonable for that scenery item.