Choose tasks, settings and presentation
Read settings with hexis.config.snapshot() at startup.
A script should describe what you want to do, provide its settings and decide
what to show. Use a native task when one already does the work you need. For
farming, that means calling farming.harvest(recipe, settings) instead of
writing another loop to hold keys, detect drops and count broken blocks.
Java executes the task and measures its progress. Lua supplies the recipe, chooses optional activities and presents results. Lower-level APIs remain available for tasks that do not fit an existing action.
Start with two files
| File | What belongs there |
|---|---|
main.lua | The recipe, a settings snapshot and the call that runs the task |
bundle.json | Identity, permissions, file hashes, settings controls and defaults |
A farming recipe is an ordinary Lua table. You do not need a crop JSON pack.
Move it into farm.lua only when that helps you read the script. Add hud.lua
or activities.lua when you want those customizations. Filenames do not grant
permissions, and there is no base class to extend.
See a complete farming entrypoint or download the modular example.
Keep three responsibilities separate
| You want to change | Change this |
|---|---|
| Crop, angle or movement pattern | The recipe and its exposed settings |
| Labels, colors or displayed readings | The HUD renderer |
| When another task runs | The activity readiness condition and action callbacks |
Replacing the HUD does not change farming movement. Omitting profit data does not disable BPS health checks. Adding an activity does not give it permission to take controls while farming is still using them.
Use observations for presentation
Read a snapshot and display it. Do not count rendered frames as harvested blocks, calculate BPS from item drops, or make safety depend on drawing a panel. Snapshots can be incomplete during startup or recovery. Show an unavailable value until the reading is ready.
Let actions own their lifetime
An action handle represents work that may still hold controls. Requesting a pause is not the same as completing it. Wait for the paused result before starting another activity. Cancellation is terminal; it is not permission to restart automatically.
The farming session wrapper handles that sequence for optional activities. Read the activity contract.
Check customizations independently
- Try the task with presentation disabled. Health checks must still work.
- Feed startup and ready snapshots to the renderer. Missing readings must not become a made-up zero.
- Confirm an activity starts only after the farming action has released controls.
- Confirm failed return validation leaves farming stopped.
These are authoring checks, not a guarantee that an arbitrary farm is supported. Use the API reference for the exact fields and supported limits.