Chariot icon indicating copy to clipboard operation
Chariot copied to clipboard

Pathfinding entities never take diagonal path

Open phrohdoh opened this issue 7 years ago • 2 comments

"Diagonal" in this context means from the perspective of the viewer looking at the 2d window (not in relation to the grid coordinate system).

Determining cell neighbors does include diagonal pieces.

A test that includes only diagonal possibilities passes:

    #[test]
    fn test_find_tile_path_diagonal_only() {
        let width = 3;
        let map = vec![
            1, 0, 0,
            0, 1, 0,
            0, 0, 1,
        ];

        let (terrain, path_finder) = make_terrain_and_path_finder(map, width);
        let occupied_tiles = OccupiedTiles::new();

        let test = &mut |from, to, exp| {
            let path = path_finder.find_tile_path(&terrain,
                                                  &occupied_tiles,
                                                  from,
                                                  to,
                                                  UnitTerrainRestrictionId::Flying);
            assert_eq!(exp, path);
        };

        test((0, 0), (2, 2), vec![(0, 0), (1, 1), (2, 2)]);
    }

@angered-ghandi do you have any insight as to why this may be the case?

phrohdoh avatar Feb 05 '18 16:02 phrohdoh

Thinking on this in the context of AoE's diamond (rotated) maps the units are only taking diagonal routes.

This test fails:

    #[test]
    fn test_find_tile_path_nondiagonal_only() {
        let width = 3;
        let map = vec![
            0, 1, 0,
            0, 1, 0,
            0, 1, 0,
        ];

        let (terrain, path_finder) = make_terrain_and_path_finder(map, width);
        let occupied_tiles = OccupiedTiles::new();

        let test = &mut |from, to, exp| {
            let path = path_finder.find_tile_path(&terrain,
                                                  &occupied_tiles,
                                                  from,
                                                  to,
                                                  UnitTerrainRestrictionId::Flying);
            assert_eq!(exp, path);
        };

        test((1, 0), (1, 2), vec![(1, 0), (1, 1), (1, 2)]);
    }

/*
  left: `[(1, 0), (1, 1), (1, 2)]`,
 right: `[(1, 0), (1, 1)]`',
*/

phrohdoh avatar Feb 05 '18 16:02 phrohdoh

@Phrohdoh, if 1 means passable and 0 means impassible, the second test is failing because you're starting from an impassible tile (1, 0).

The test passed when I changed the last line from:

test((1, 0), (1, 2), vec![(1, 0), (1, 1), (1, 2)]);

to:

test((0, 1), (2, 1), vec![(0, 1), (1, 1), (2, 1)]);

ghallak avatar Mar 19 '18 21:03 ghallak