Держать одного юнита

Привязываться каждую итерацию незачем. Правильный цикл привязывается редко — только когда прежний юнит больше не годится

среднийНужно знать: Привязка по типу, Циклы

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

Решение не в том, чтобы запоминать юнита в переменной. Оно в том, чтобы не привязываться лишний раз.

Правильный цикл привязывается редко

если

тип

@counter0number

итерацийnullnull

негоденnullnull

привязокnullnull

другойnullnull

прежнийnullnull

сменnullnull

op add итераций итераций 1
sensor негоден @unit @dead
jump 5 equal негоден 0
ubind @poly
op add привязок привязок 1

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

Держится это на простом свойстве: @unit живёт между итерациями. Это обычная переменная процессора, её никто не чистит, и к следующей итерации в ней лежит тот же юнит. Переменная-копия для этого не нужна вовсе.

А если привязываться каждый раз

тип

@counter0number

итерацийnullnull

привязокnullnull

другойnullnull

прежнийnullnull

сменnullnull

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

Когда переменная всё-таки нужна

@unit один, а юнитов может быть несколько. Как только процессору нужно помнить больше одного, приходится складывать их куда-то ещё — и доставать обратно:

тип

@counter0number

мойnullnull

тотЖеnullnull

ubind @poly
set мой @unit
...
ubind мой

В поле ubind можно поставить не только тип, но и самого юнита. Тогда привязка не идёт по кругу, а возвращается ровно к нему — тотЖе это подтверждает.

Так делают, когда:

юнитов несколько и у каждого своё занятие — тогда их держат в ячейке памяти, по месту на каждого;
юнита передают другому процессору — тот достаёт его из общей ячейки и привязывается;
программа между делом привязывалась к кому-то ещё, и надо вернуться к своему.

Юнит гибнет, привязка помнит

если

тип

@counter0number

мойnullnull

мёртвnullnull

живыхnullnull

Вспышка стоит под огнём чужой турели и через несколько секунд погибнет. Смотрите за переменными: мёртв станет единицей, а живых покажет, что привязываться больше не к кому.

Вот что при этом происходит:

юнит выбывает из перебора — ubind @flare сразу начинает отдавать пустоту;
привязка продолжает указывать на покойника. Ни @unit, ни переменная не обнуляются;
sensor мёртв мой @dead отвечает единицей — это и есть способ проверить.

Отпустить юнита

Привязка не отдаёт команд сама по себе, а вот ucontrol — отдаёт, и юнит после неё десять секунд слушается процессора вместо собственного разума. Ждать этих десяти секунд не обязательно:

ucontrol unbind 0 0 0 0 0

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

Задание

В первом примере уберите строку jump 5 equal негоден 0 — и правильный цикл превратится в неправильный: привязок догонит итераций, а смен покажет, что юнит меняется почти каждую итерацию.

Во втором примере поставьте ubind @poly вместо ubind мой в предпоследней строке и посмотрите на тотЖе: он останется единицей. Поли на карте трое, привязок к этому месту четыре — перебор успел замкнуться и сам вернулся к первому. Совпадение, а не правило: добавьте четвёртого поли, и оно пропадёт.

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