Movement and stopping

Coordinates in tiles, an order that lasts ten seconds, and «stop» that does not mean «freeze»

mediumYou need: Binding by type, Properties of units

steptick 0

Unit Bind0

type

Unit Control1

typemovexy

Sensor2

=

 in

Sensor3

=

 in

@counter0number

xnullnull

ynullnull

ubind @poly
ucontrol move 16 4 0 0 0

Two lines, and the poly flies to tile 16 4. Watch x: it grows while the unit is on its way and settles around sixteen once it has arrived.

Field	What is in it
first	move
second and third	the target’s coordinates in tiles
the rest	unused by move, write zeroes

The coordinates are the same as @x and @y: map tiles, not world units. So “fly to the store” is sensor x container1 @x, sensor y container1 @y and those same numbers in move.

Note

A unit arrives roughly at a point, not exactly: it has acceleration, inertia and drag. Checking arrival by comparing coordinates is pointless — within exists for that.

The order is repeated, not issued

Control of a unit lasts ten seconds — 600 ticks. Every new order starts that count again, and when the time runs out the unit returns to its usual behaviour: a poly flies off to repair buildings, a dagger walks to the nearest enemy.

Movement simply stops at that point — there is nobody left to drive it. But the work it was given stays: mining, building and the flag survive the timer and are removed only by a new order.

So a program about units almost always looks like this: bind, command, end the iteration — and start again. There is nothing wasteful about it; a repeated order does not knock the unit off course.

stop is not a brake

steptick 0

Unit Bind0

type

Sensor1

=

 in

Jump -> 52

if >

Unit Control3

typemovexy

End4

Unit Control5

typestop

@counter0number

xnullnull

Here the program leads the poly to 16 4, but as soon as x passes ten it issues ucontrol stop. The unit then coasts several more tiles, and x settles around seventeen — past the target.

stop means “I am no longer driving you”, not “stand still”. Speed is killed by drag, and a flying unit carries a long way.

Silent failure

To hold a unit at a point you command move to that point, not stop. A move works like a tether: the unit stands there, and if pushed it comes back. stop simply lets go of the control until the ten-second term expires.

Other ways to move

Command	What it does
move	straight to a point, ignoring the terrain
approach	towards a point, stopping at a given radius
pathfind	to a point by road — a ground unit walks round a wall
autoPathfind	where the unit would go by itself: to the enemy core
boost	lift a ground unit into the air, if it can
idle	do nothing, but stay under control

approach comes in handy when getting right up close is unnecessary: to a turret to repair it, or to an enemy at firing range. Its radius is in the third field, in tiles as well.

Note

For flyers move and pathfind are the same thing: air needs no roads. The difference shows only on the ground, and the course sandbox has no pathfinding: ground units go straight too. In the game pathfind leads them around.

Remember

• ucontrol move x y leads the bound unit to a point; the coordinates are in tiles.
• Control lasts 600 ticks, so the order is repeated every iteration.
• A unit arrives roughly at a point: there is acceleration and inertia.
• stop releases the movement rather than braking; to hold a unit, move it to the same point.
• pathfind goes round obstacles, approach stops at a distance.

Task

In the first example change the target to 3 8 and run it: the unit turns around and flies back up, and y heads towards eight.

In the second example change ucontrol stop to ucontrol move 10 4 0 0 0. Now the unit does not overshoot: having reached tile ten, it stays about there.