Change Detection & Recording

• Wait — waits a fixed amount of time (e.g. 2 seconds), no matter what happens on screen. A "blind wait".
• Wait for Change — continuously monitors the screen and only continues when the view changes within the specified region. A "smart wait".

Typical scenarios:

• Waiting for loading to finish → use "Wait for Change" to monitor the loading animation area; once the view changes (loading done), continue
• Waiting for an opponent's move → monitor the game view and trigger a response when something changes
• Waiting for a page transition → monitor the content area; a change means the page has navigated

Smarter than "wait 3 seconds": if the change happens quickly, it executes sooner; if it's slow, it automatically waits longer. It neither wastes time nor misses the moment.

"Wait for Bar Change" is designed specifically to monitor length changes in bar-shaped elements such as health bars, progress bars, and energy bars.

Why multiple templates? Because a bar looks different at different lengths (a full bar is long, a nearly empty bar is short). You need to capture screenshots of the same bar in different states as references:

1. In the node configuration, click "Capture Reference Bar"
2. Select the health bar region → enter a name (e.g. "Full HP", "Low HP")
3. We recommend capturing 2 images: one at full health and one at roughly 1/4 or 1/3 health

Note: don't use too many templates — too many reduces detection efficiency. Two is enough to cover most scenarios.

The engine continuously matches which template the current view is closest to. When the match result switches from one template to another, it determines that "the bar has changed".

Typical usage: monitor a character's health bar, and when health drops by more than a certain ratio → automatically use a potion.

These two thresholds are easy to confuse, but they control different things:

• Match threshold (default 0.85) — controls "how similar the current view must be to a template to count as a match". Same meaning as the threshold in regular image search. Too low causes false matches; too high causes missed matches.
• Change threshold (default 0.1) — controls "how much the bar's length must change to count as a real change". 0.1 means it only reports when the length changes by more than 10%. This prevents frequent false alarms caused by slight view jitter.

Easy way to remember: the match threshold governs "whether it can be found", and the change threshold governs "how much change counts as a change".

Generally, keep the defaults. If small health bar fluctuations trigger false alarms → raise the change threshold to 0.15–0.2.

Full steps:

1. Add a Loop node (infinite loop) so the script keeps monitoring
2. Inside the loop, add a Wait for Bar Change node:
   • Region: select the area where the health bar is located
   • Templates: capture 1 reference image at full health + 1 at low health (about 1/4)
   • Timeout: set to 0 (keep monitoring until a change occurs)
   • Change threshold: 0.1 (the default is fine)
3. After Wait for Bar Change, add a Condition: check whether delta (the change ratio) indicates health has decreased
4. When the condition is met, add a Find Image node: find the potion icon and click it
5. Add a short Wait (e.g. 500ms) to prevent repeated triggering

This way, the script continuously monitors the health bar and automatically clicks the potion once it detects a significant drop in health.

Reference example: the Windows version ships with a built-in "Game Helper – Health Bar Monitor" demo project. You can import the demo package from the menu to view the full configuration (includes 2 templates: full health + 30% health).

Windows version:

1. Switch to the "Macro Manager" tab (Ctrl+7)
2. Click + New Recording
3. A green border appears on screen (marking the design region), with a "■ Stop Recording" button in the bottom-left
4. Perform the steps you want to automate as usual (clicks, typing, etc.)
5. When done, click "■ Stop Recording"
6. Choose "Save to Project"

Android version: in the editor, switch to recording mode. Your actions are intercepted and recorded by a full-screen overlay, while the underlying interface simultaneously carries out your actions.

After recording, you can play it back from the macro list to test, or embed it in the main flow via a "Call Recorded Macro" node.

When recording, MacroAI only records actions inside the design region. This is intentional, to prevent accidental actions (such as clicking on MacroAI's own interface) from being recorded.

Situations that are not recorded:

• Clicking a position outside the design region (the border flashes red as a warning)
• Clicking on MacroAI's own windows/buttons
• Android version: clicking on the recording floating bubble area

Solutions:

• Make sure all your actions stay within the green border
• If the target window is larger than the design region, you'll need to recreate the project or modify the design region
• Seeing the border flash red = that action wasn't recorded and needs to be redone

Macro playback preserves the time intervals from recording. If you acted quickly while recording, playback will also be fast.

How to adjust:

• Deliberately slow down while recording, leaving enough gap between each step
• If a step needs to wait for loading, actually wait for the loading to finish before performing the next step while recording
• Delays can't be edited after recording — if you're not satisfied, delete it and record again

Better approach: for scenarios that need precise pacing, we recommend building the flow manually in the node editor (Wait nodes + Click nodes) rather than relying on recording. Recording is better suited for "fixed action sequences where the intervals don't matter".

The macro itself cannot be edited. After recording, you can rename it, edit its description, play it back, or delete it — but you cannot modify the individual events inside (you can't remove a specific click, adjust a delay, or change a coordinate).

Recorded it wrong? Delete it and record again.

Want conditions? Use the node editor:

1. Add a "Call Recorded Macro" node in the node editor and select your macro
2. Add condition, loop, image search, and other nodes before and after it
3. This way the macro handles "performing the actions" while the node editor handles "controlling the logic"

You can also split a long sequence into several short macros, recording each separately and connecting them with node logic — more flexible.

Main differences:

• Action types: Android records touch actions (taps, swipes). There's no keyboard input (Android keyboard input goes through the IME and can't be intercepted directly)
• Recording method: Android uses a full-screen overlay to intercept touch events while replaying them on the layer beneath (you can see the effect of your own actions)
• Playback method: gestures are injected via the Accessibility Service's dispatchGesture — no root required
• Limitations: you can't interact with the status bar / navigation bar area while recording; multi-finger gestures (such as pinch-to-zoom) are not currently supported

For this reason, on Android we recommend building flows with the node editor and using recording as a supplementary tool. The Windows version has a more complete recording feature (supports keyboard and Chinese IME input).