Skip to content

Unit Radar

The same radar, only it looks from your unit rather than from a building — and with your unit's range

tick 0
Unit Bind0
type
Unit Radar1
target1target2target3sortradarsortOrderoutput
Unit Radar2
target1target2target3sortradarsortOrderoutput
Sensor3
=
in
Sensor4
=
in
Sensor5
=
in
@counter0number
nearnullnull
farnullnull
nearXnullnull
farXnullnull
rangenullnull
ubind @dagger
uradar enemy any any distance 0 1 near

The dagger looks for enemies around itself: near is the flare on tile nine, and the same search with a zero in the second-to-last field gives the far one, on tile fourteen.

uradar’s fields are the same as radar’s: three filter conditions, what to measure by, which to count first. There is one difference, and it is in the fifth field.

radar uradar
looks from the building in the fifth field the bound unit
range that building’s range the unit’s own range
fifth field a building unused, write 0

uradar effectively has no fifth field: the source is always @unit, and the zero is there just for tidiness. No binding, no search: the answer will be emptiness.

The range is taken from the unit and differs for each: a dagger’s is 18.25 tiles, a flare’s is noticeably less, a big unit’s noticeably more. You can ask the unit itself:

sensor range @unit @range
tick 0
Unit Bind0
type
Unit Radar1
target1target2target3sortradarsortOrderoutput
Sensor2
=
in
Sensor3
=
in
Stop4
@counter0number
minenullnull
whoIsItnullnull
myselfnullnull

The dagger looks for allies — and finds the poly, not itself. That is a built-in rule: the source of the search is excluded from the list.

Otherwise searching for an ally would be useless: the nearest ally to a unit is always itself, and uradar ally any any distance would return the very unit that had just been bound.

uradar recomputes its target once every 40 ticks, and that is not the same window as an ordinary radar’s: a building’s is thirty ticks, while a unit’s is its own, because it lives not in the instruction but in the very control that ubind and ucontrol hang on the unit. In between, uradar gives back what it found last time — even if the target has flown away or died.

The same fact has a second consequence: uradar takes the unit under control. It needs the same controller the orders need, so it creates one — it just gives no orders.

Two thirds of a second is not much, but for a unit it is noticeable: it is moving and so is the target. That is why aiming for fire (ucontrol targetp) is issued every iteration: the target may be stale, but the order is fresh.

Unofficial fan project, not affiliated with Anuke. Mindustry sprites, fonts and translations © Anuke, used under GPL-3.0; Fira Code under OFL-1.1. Site code is GPL-3.0.