你好，我遇到寻路失败的情况了 about astar HOT 10 CLOSED

下面这种情况，寻路就会失败

int[][] maps = {
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
{ 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0 },
{ 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0 },
{ 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0 }
};
MapInfo info=new MapInfo(maps,maps[0].length, maps.length,new Node(1, 1), new Node(4, 5));

因为你终点不可达，new Node(4, 5)在maps中是的值是1

from astar.

你好，您仔细看下我这个map，new Node(4, 5)这个终点貌似是0

from astar.

new Node(4, 5)，应该是图里面的第六行，第五列这个吧？

from astar.

new Node(4, 5)，应该是图里面的第六行，第五列这个吧？

确实有问题，我看下

from astar.

这是因为H值没乘代价，我分析的是这样。
如果我没错，那这个代码真的误导了非常多的人了。即有bug还增加消耗。
现在百度一搜全是复制的这个项目里的
https://blog.csdn.net/qq_43413788/article/details/108630704

from astar.

这是因为H值没乘代价，我分析的是这样。
如果我没错，那这个代码真的误导了非常多的人了。即有bug还增加消耗。
现在百度一搜全是复制的这个项目里的
https://blog.csdn.net/qq_43413788/article/details/108630704

不是这个代价问题，已经修复了，可以运行代码看看，H这个时候没必须要乘代价

from astar.

G都乘了代价，H不乘代价，比较不会出问题吗？
假设从12*12地图中，(4,4)寻路到(11,11)
在(4,4)周围的八个格子中，理所当然的最优点应该是(5,5)
而实际上最优点会变成(4,5)
因为曼哈顿值不乘10(DIRECT_VALUE横竖移动代价)而直接作为H使用，是这样的：
(4,5)的G=10,F=13;而(5,5)的G=14,F=12，明显10+13 < 14+12
乘上DIRECT_VALUE再看：
(4,5)的G=10,F=130;而(5,5)的G=14,F=120，明显10+130 > 14+120

from astar.

G都乘了代价，H不乘代价，比较不会出问题吗？
假设从12*12地图中，(4,4)寻路到(11,11)
在(4,4)周围的八个格子中，理所当然的最优点应该是(5,5)
而实际上最优点会变成(4,5)
因为曼哈顿值不乘10(DIRECT_VALUE横竖移动代价)而直接作为H使用，是这样的：
(4,5)的G=10,F=13;而(5,5)的G=14,F=12，明显10+13 < 14+12
乘上DIRECT_VALUE再看：
(4,5)的G=10,F=130;而(5,5)的G=14,F=120，明显10+130 > 14+120

这里还有斜走的，为什么斜走要*10？

from astar.

10是曼哈顿值得代价，即使斜着走也是用移动的曼哈顿值*10
你也可以搜一下其他形式得实现，看他们是不是都乘了
G乘和H不乘进行比较，显然是没什么道理吧
你看一下这篇吧：A*算法的java实现
这篇是我时间筛选得2016年的博文，没有受你这个项目得影响，是都乘了代价得

from astar.

10是曼哈顿值得代价，即使斜着走也是用移动的曼哈顿值*10
你也可以搜一下其他形式得实现，看他们是不是都乘了
G乘和H不乘进行比较，显然是没什么道理吧
你看一下这篇吧：A*算法的java实现
这篇是我时间筛选得2016年的博文，没有受你这个项目得影响，是都乘了代价得

理解你的意思了，确实是有问题，如果按照曼哈顿的计算方式，是属于横竖移动的，理应乘上响应代价，多谢提醒，我修改下代码

from astar.