Recipes

Three complete flows to copy, and why each one is built that way.

Three flows worth having.

Greet people

on join

chat hi

on chat matching (?i)\bhello\b

chat hey :)

A chat greeter. (?i) makes the match case-insensitive and \b requires whole words, so "othello" does not set it off.

Careful with anything that replies to chat: the server echoes the client's own messages back as chat lines, so a pattern loose enough to match your own reply will trigger itself forever. Either keep the pattern tight, or add a player allowlist so only other people can set it off.

Log in automatically

Most offline-mode servers with a login plugin want a /login on every join, and a /register the very first time.

on join

wait 1.5 seconds

command /login {{secret:password}}

on chat matching (?i)^(?!/).*/register\b

command /register {{secret:password}} {{secret:password}}

Both details in this pair are load-bearing:

The wait. Plugins often ignore commands sent in the same instant as the join.
That unpleasant-looking pattern. It matches a line containing /register but not one starting with /. Without the exclusion, the server's echo of the client's own /register command matched the pattern and re-triggered the flow indefinitely.

Both read the client's password variable, the same one the ready-made Log in block uses (see variables and secrets). Older flows used server_password; if yours still does, change it to password so the client needs only one value.

A new flow opens with a close relative of this already on the canvas: it answers the server's own lines mentioning /login and /register, each after a short wait, instead of logging in a fixed time after joining. Chat triggers also hear the lines a server sends while the client is still joining, so a prompt that arrives before the client appears in the world is still answered.

Mine until full, empty into a chest, repeat

The pattern behind every farm loop: do work, notice you are full, stow, carry on. Written with a routine so the stowing exists once.

routine stow

go to nearest chest within 32 blocks

open container nearest x y z · radius 4

put registry name x 0 into container — all of it ☑

close container

when run manually or by webhook

while test free slots more than 2 (max 500x)

dig nearest stone within 12 blocks, 1 time(s)

wait between 250 and 900 ms

run routine stow

before the client stops

run routine stow

Why it is built this way:

while on free slots, not a fixed count. The loop ends when the client is nearly full, whatever it happened to pick up.
dig nearest, not dig. Walking is included, and no coordinates have to be known in advance.
A cap on the loop. max 500 bounds it even if the condition never turns false. The firing's action budget bounds it too.
The same routine on before-stop. Stopping the client dumps the inventory instead of leaving an hour of mining in it. That trigger runs on a five-second budget and is skipped for a kick, so treat it as a courtesy, not a guarantee.

To run it on a schedule instead of by hand, swap the manual hat for a timer, but give the loop a smaller cap than the interval, or a slow pass will still be running when the next one is due and will simply be skipped.