Skip to content

Properties of units

After ubind you can ask @unit the same things — where it is, whether it is intact, what it is busy with

A unit is asked with the same sensor as a block. There is one difference: a unit has no link name, so it has to be taken first — that is what ubind does, and the taken unit sits in @unit.

tick 0
Unit Bind0
type
Sensor1
=
in
Sensor2
=
in
Sensor3
=
in
Sensor4
=
in
Sensor5
=
in
@counter0number
xnullnull
ynullnull
healthnullnull
kindnullnull
fliesnullnull

The first line takes the first free poly, and the rest ask it the same things that were asked of a container yesterday.

@x and @y give tiles: for the poly in the example, 8 and 5. Inside the game everything is counted in pixels, eight per tile, but logic divides them by eight and multiplies back — which is why in mlog you never see 64 or 40.

The fractional part is real, though: a unit stands at a point, not in a tile, and its @x can well be 8.37. Buildings have fractional parts too, but for another reason — an even-sized block’s centre falls on a seam.

Property What it means
@x, @y where it is now
@health, @maxHealth whether it is intact
@flying whether it is airborne: for mechs this changes
@mining whether it is mining right now
@totalItems, @firstItem what it is carrying
@flag the tag ucontrol flag puts on a unit
@controlled who commands it: 0 — nobody

The full table is in the reference: it also shows which properties a unit has and which belong to buildings only. What those properties mean and how to change them is the ucontrol group’s business; sensor can only read them.

@unit lives exactly as long as the unit does. The moment it is shot down, @unit holds null, and every sensor on it gives the same back.

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.