Restaurants
Open a restaurant, let its staff build the menu, and take food orders through the Food app.
The app is called Food. Customers order from it, staff cook and deliver from it — same app, different screen depending on the player's job.
Two things are worth knowing before you start:
- Restaurants are not in the config. They live in the database, so you create them once and they stay.
- Menus are not in the config either. Staff write their own menu in game, and can change prices whenever they like.
What the config decides is which items may be sold, and the rules around orders.
Step 1 — Create the restaurant
A restaurant is one job code plus a name, and you open it from your own phone.
Give yourself admin mode:
/adminauth trueNow open Food. A wrench appears in the top right — that is the Restaurant admin screen.
| Field | What to put in |
|---|---|
| Job code | The job exactly as your framework knows it — burgershot |
| Name | What customers see — Burger Shot |
| Description | One line under the name. Optional |
| Logo URL | Image link. Optional |
Save, and the restaurant is open. /adminauth false hides the wrench again.
The job code is the key everything hangs off, so it cannot be changed later — the menu and the order history are attached to it. Saving a restaurant on a job code that already has one updates that one instead.
The list underneath
Everything you have created is listed below the form, closed ones included:
Burger Shot
burgershot · 2 on duty- Tap a row to load it back into the form and edit its name, description or logo. The job code is locked while editing.
- The switch on the right opens and closes a restaurant. Closing hides it from customers but keeps its menu and order history — there is no delete on purpose.
on dutyis how many of its staff are working right now. Zero means customers see it as closed.
Step 2 — Let staff write the menu
Whoever works that job opens Food and lands on the Orders screen instead of the customer one. A slider icon in the top right opens the Menu editor.
Who gets that icon is a job grade:
MenuEditGrade = 3, -- grade needed to edit the menuGrade 3 and above edits; everyone below just cooks. Each menu line is:
| Field | Notes |
|---|---|
| Name | The dish, as customers read it — Double Cheeseburger |
| Description | Optional |
| Price | What the customer is billed |
| Category | Food, Drink or Dessert |
| Inventory item name | The item actually handed over — picked from a list |
That last one is the important one: the customer receives a real inventory item. Double Cheeseburger at $45 can hand over a burger.
Which items may be sold
The picker only offers what you list here, so add your own food items:
Items = {
"burger", "sandwich", "hotdog", "pizza", "taco", "donut",
"water", "cola", "coffee", "beer", "energydrink",
},Labels and images come from your inventory automatically — only the names belong in this list. A name that is not here is refused even if a modified client sends it.
Images are read from ItemImagePath, which has an entry per supported inventory. Set it to false to show no images at all.
How an order runs
| Step | Who | What happens |
|---|---|---|
| Order | Customer | Picks a restaurant, fills a cart, adds a note. Their street is sent along |
| Accept | Any staff | The order becomes theirs |
| Preparing | That staff | Customer sees the status change |
| Delivering | That staff | A waypoint is set to where the customer is now |
| Deliver | That staff | Items are handed over, then the bill is raised |
Prices are read from the menu on the server, never from the customer's phone, and each order keeps a snapshot — editing a price later does not change what an open order costs.
A few rules the app enforces on its own:
- One open order per customer at a time.
- Cancelling costs the customer a cooldown, and stops being possible once the courier is out.
- No delivery unless the customer has room for all of it — a half-handed-over order is rolled back rather than billed.
- Staff who disconnect mid-order hand it back to the queue.
Settings
Config.Restaurant = {
Enabled = true,
RequireDuty = true, -- only clocked-in staff receive orders
MenuEditGrade = 3, -- job grade needed to edit the menu
DeliveryDistance = 20.0, -- metres the courier must get within
OrderTimeout = 900, -- seconds before an unanswered order expires
CancelCooldown = 120, -- seconds before the customer may order again
Cart = { MaxPerItem = 10, MaxItems = 20 },
BillingDescription = "Food order", -- uses Config.BillingCommissions
Blip = { enabled = true, blip = 267, colour = 5, scale = 0.8, text = "Food Delivery" },
}Categories sets the three menu tabs; the labels are locale keys, so translate them in locales/*.json rather than here.
When something is not working
The restaurant shows as closed. Nobody is on shift. A restaurant with no staff online takes no orders, because the food would sit until it expired. With RequireDuty = true they have to be clocked on, not merely on the job.
Staff see the customer screen. Their job does not match the job code. Case and spelling have to be exact.
Both show up in the same place: the Restaurant admin list. If someone is at work and the row still reads 0 on duty, the job code is wrong or they are off duty.