Anchors — regions that follow the game

An anchor ties your search regions to a stable landmark on screen instead of fixed pixel coordinates. Move the window or change resolution, and every region marked “relative to the anchor” moves along by itself. It is the single most useful concept for flows meant to keep working day after day.

What is an anchor — and why you need one

Most vision nodes work on a rectangle of the screen: “read the text in this box”, “look for this image in that area”. Those rectangles are stored as absolute pixel coordinates. That is fine — until the game window moves. Drag it a few pixels, maximize it, switch to another monitor or resolution, and every box now points at the wrong place. The flow keeps running but searches in empty space.

An anchor solves this. Instead of pinning a region to the screen, you pin it to something that always sits in the same spot inside the window — a fixed HUD element, a frame, an icon that never moves relative to the interface. That landmark is the anchor. Your regions are then stored as an offset from it, not as absolute coordinates.

How it works

The “Find anchor (image)” node searches the captured window for a small, stable anchor image. When it finds it, it stores the top-left corner of the match as an image-relative reference point. There is exactly one anchor at a time — the one found most recently.

Every region node has a “Region relative to anchor” switch. When it is on, the node adds the anchor's reference point to its own region before searching. Move the HUD and the anchor is found in a new spot on the next “Find anchor” run — so all relative regions shift by the same amount and land back on their targets. Nothing else in the flow has to change.

Set it up in five steps

1. Add a “Find anchor (image)” node early in your flow — after you capture the window, before any region node that should follow the anchor.
2. Capture or pick the anchor image: a small, unmistakable, always-visible part of the HUD. Use the built-in template tool to cut it straight from a screenshot.
3. Check the similarity (default 0.95). Higher is stricter; lower tolerates small visual changes. If the anchor is missed, lower it a little; if it matches the wrong thing, raise it.
4. On each region node — Find image, Read text (OCR), Color search, Visible?, Switch/branch, Health bar — turn on “Region relative to anchor”, then draw the region as usual. It is stored as an offset from the anchor automatically.
5. Mind the order: “Find anchor” must run before the relative region nodes, wired on its “found” output. On “not found”, branch to a safe fallback instead of searching blindly.

A concrete example

Say you read your cargo hold's fill percentage with OCR. You pick a fixed corner of the HUD frame as the anchor and mark the cargo number as “relative to the anchor”. During testing everything lines up perfectly.

The next day you open the game on a laptop at a smaller resolution, so the whole HUD sits 180 pixels to the left. The first “Find anchor” locates the frame in its new position; the OCR region shifts 180 pixels with it and reads the right number on the very first pass — no editing, no re-recording.

Tips & pitfalls

• Choose a stable, unique landmark. The anchor image must be something that never moves inside the interface and does not repeat elsewhere on screen — a distinctive frame corner or icon, not a patch of background or a number that changes.
• There is only one anchor. The whole flow shares a single anchor — the one found most recently. If different parts of the screen need different reference points, run “Find anchor” again to re-point it before the regions that depend on it.
• Always handle “not found”. If the anchor cannot be located, its position is left untouched and relative regions do not move. Wire the “not found” output to a retry, a wait, or a clean stop instead of letting the flow act on stale coordinates.