Перейти к содержимому

Подбитые здания и проверка находки

Четвёртый вид поиска ищет то, что надо чинить. А заодно разберёмся, почему ответ иногда застревает

тик 0
Связь с юнитом0
тип
Поиск юнитом1
locateфлагвраг?рудаXYoutFoundoutBuild
Информация2
=
у
Информация3
=
у
Стоп4
@counter0number
битыйXnullnull
битыйYnullnull
нашлосьnullnull
битыйnullnull
здоровьеnullnull
пределnullnull
ulocate damaged core true @copper битыйX битыйY нашлось битый

На карте две двойные турели, и одна из них подбита: у неё 60 здоровья из 250. Её поиск и находит — целая соседка в счёт не идёт.

damaged смотрит только на свои здания: поля «метка» и «чужое ли» он не использует вовсе. Ищет он ближайшее к юниту здание, у которого здоровье меньше предела.

Это ровно то, что нужно ремонтнику:

ubind @poly
ulocate damaged core true @copper x y нашлось цель
jump 0 equal нашлось 0
ucontrol approach x y 4 0 0

Поли подлетает к подбитому зданию, а чинит он его в игре сам: ремонт — его собственное занятие, командовать им не надо. Программе остаётся только подвозить его к работе.

Это общее правило для всех четырёх видов поиска, а не особенность damaged.

ulocate, как и uradar, пересчитывает находку раз в 40 тиков, а в промежутке отдаёт прошлый ответ. Причина простая: обойти всю карту дорого, а программа крутится по несколько сотен раз в секунду.

Из этого следует пара привычек:

  • не пытайтесь «обновить» поиск, повторив инструкцию подряд несколько раз: ответ будет один и тот же;
  • не удивляйтесь, что починенное здание ещё две трети секунды числится подбитым.

У ulocate есть и четвёртый вид поиска — spawn, точка появления вражеских волн. Работает он так же: координаты плюс «нашлось», здания там нет.

Неофициальный проект, с Anuke не связан. Спрайты, шрифты и переводы Mindustry © Anuke, используются по GPL-3.0; Fira Code — по OFL-1.1. Код сайта — GPL-3.0.