Update 0.3.1 — the mouse enters the language, the world gets memory, and the editor lets you move code around

Until now a program could only read what was already on the grid, every value it kept had to live inside some cell, and the only thing you could do to a line of code was delete it. All three are fixed in this update.

Your program can see the mouse

The SYSTEM node has four new parameters, and they change what kind of thing you can build: for the first time the automaton can react to a person while it runs, instead of only to the picture you painted before pressing START.

• MOUSE X / MOUSE Y — the cell under the cursor, in grid coordinates. That is the same space as SELF.X/SELF.Y, so a cell asks "is the cursor pointing at me?" by comparing MOUSE X = SELF.X and MOUSE Y = SELF.Y. No pixels, no window sizes, nothing to convert.
• MOUSE L / MOUSE R — whether the left or right button is held, 1 or 0. Two separate values, so "both at once" needs no arithmetic.
• When the cursor is not on the field — over a panel, past the edge, outside the window — both coordinates are -1 and both buttons are zero. A cell coordinate is never negative, so MOUSE X >= 0 is your "is the mouse on the field" check.
• A click over a panel never reaches the program: that is interface work, not input for your automaton.
• Within one tick the values are frozen, so every cell of a generation sees the cursor in exactly the same place.

Four nodes, and suddenly a fire that follows your hand, sand you can pour, water you drag across the field, a level that reacts to where the player points.

The SYSTEM panel now shows the same thing on a Mouse row — the cell under the cursor and the buttons held, or a dash when the cursor is elsewhere. Handy for checking that the engine thinks you are pointing where you think you are pointing.

The world has variables now

A cell has six property slots. The world itself had nothing — so a count of living cells, an animation phase, a score, or a plain "the explosion already happened" flag all had to be hidden in the properties of some sacrificial cell in the corner of the grid.

• A VARIABLES section in the world panel, right below CONSTANTS. Add one with + var, rename it with ab, drag its token into your program — exactly like a constant, in a different colour.
• Three new nodes: VAR reads it, SET VAR writes it, ADD VAR adds to it.
• One value for the whole grid. What one cell writes, every cell processed after it sees in the same tick.
• The value in the panel is live. Your program writes into the very field you are looking at, so the section is a window into the state of your world while it runs — and the first real debugging tool this language has ever had. You can still type a value in by hand to nudge things.

Why not just make constants writable? Because a constant should stay where you put it. A variable is the thing that moves under your hands; a constant is the thing that does not.

BEFORE TICK — code that runs once per generation

A new section above MAIN, and it runs once per tick, before the first cell is touched. It exists for two jobs:

• Zero an accumulator before the pass, so MAIN can count something across the whole grid and the next tick can read the total.
• Compute once what is the same for every cell — an angle, a phase, a value derived from SYSTEM — instead of recomputing it in each of tens of thousands of cells. In the Radar example the sine and cosine of the beam angle are worked out sixteen thousand times per tick. Now they need not be.

"Run this once at the very start" is not a separate feature — it is IF SYSTEM.TICK = 0 inside the same block.

The block has no cell of its own, and that shows up as values rather than as errors: SELF.X/SELF.Y give -1, reading through SELF/NEIGH gives zero, writing through them does nothing, COUNT is zero, DISTANCE is -1. AT(x,y), VAR, SYSTEM and arithmetic work at full strength — the block writes to the grid by address, not by neighbourhood.

The usual shape of things, then: reset in BEFORE TICK, accumulate in MAIN, read on the next tick.

The section is collapsed by default — most programs will not need it — and if a runaway loop ever eats the whole tick budget in there, the warning badge says so instead of reporting an unexplainable "0 of 16000 cells updated".

The editor: labels on every field

A NEIGH reference used to be three fields in a row with no captions at all, and which one was the X offset was something you simply had to remember. Every input in a code row is labelled now: of (whose cell), dx/dy (the offset), prop (which property), kind / to kind, var, no. (parameter index), ch (colour channel), x:/y: for AT coordinates.

The editor: moving code around

Until now the only action on a statement was "delete", and a new one could only be appended to the end of a list. Inserting a line between two existing ones was impossible — you appended to the end and rebuilt it by hand.

Hover a row: it lights up faintly, and a ... button appears at the right edge. Click it and you get:

• add — a new statement right after this one, anywhere in the program.
• c — copy this statement with its whole body.
• p — paste the copy right after this one.
• ^ / v — move the statement up or down its list.

Deleting is still the permanent x in the row itself — the one action that should always be one click away. A legend under the section header spells the buttons out, so nothing has to be memorised.

Expression rows get the same menu with two buttons: copy this subtree, or replace this node with what is in the buffer. That is how one carefully built condition moves anywhere — into another branch, into a call argument, into the value of an assignment.

The buffer holds a deep copy and pastes a copy: however many times you paste a branch, each one is edited on its own. An empty block (a freshly made IF) takes a paste through the paste button next to + stmt. And while the buffer holds something, a CLEAR BUFFER button shows up in the toolbar next to the view selector — the buffer outlives the project you copied from, so it is worth being able to empty it.