Creep.moveTo() 是非阻塞方法吗？

Question

        // Creep has Energy packed
        creep.say('E: ' + creep.carry.energy);
        if (creep.carry.energy > 0) {
            creep.moveTo(creep.room.controller);
            creep.upgradeController(creep.room.controller);
        }
        // Creep has no Energy
        else {
            creep.moveTo(Game.spawns.Spawn1);
            Game.spawns.Spawn1.transferEnergy(creep, creep.carryCapacity);
            creep.moveTo(creep.room.controller);
            creep.upgradeController(creep.room.controller);
        }

上面的代码应该发送一个 creep 来升级控制器。当它没有能量时，它应该去出生点取一些。但是它没有移动到重生点，而是停留在控制器上。

问题: 哪个命令正在取消 creep.moveTo(Game.spawns.Spawn1);?

我是否必须使用 creep 的 Memory 并添加一种类似于 isMoving: true 的状态并跟踪它？

Answer 1

这正是您命令 creep 执行的操作。倒数第三行将 moveTo 更改为控制器。删除这一行和下一行。

如果您向 creep 发送多个 moveTo，它只会执行最后一个。因为它覆盖了之前的 moveTo 命令。

Answer 2

不需要取消 creep.moveTo() 因为它只命令 creep 每刻做一个动作。您可以通过选择不调用 creep 的 moveTo() 方法来停止移动。

但是，我明白了为什么人们会误以为 moveTo() 开始沿着一条路径自主行走 - 因为 moveTo() 计算了 creep 需要到达的整个路径目标。每次 tick 都这样做会浪费大量 CPU 资源，因此 moveTo() 每次调用仅启动一步移动并不完全直观。

理解这就是真正发生的事情的诀窍是认识到 moveTo() 默认情况下将计算的路径缓存在 _move 属性下的 creep 的 Memory 中，并且仅在可配置的刻度数后重新计算新路径（根据文档，默认为 5 个）。

这也意味着 creep 的 moveTo() 可能需要最多 5 个刻度（取决于何时发生）默认情况下才能意识到障碍物已经阻挡了缓存路径的更下方，因此可能会朝着障碍一点，直到它选择一条新的畅通无阻的路径。

Creep.moveTo() 是非阻塞方法吗？

Is Creep.moveTo() a non-blocking method?

screeps