BurgerShot | The Complete Restaurant Job

What it is

BurgerShot is a full cook-and-serve restaurant job, not a vendor shop. A customer orders at the till, a cook claims the ticket on the employee tablet, walks to the stations, consumes real ingredients from their pocket, produces the food, and serves it at the counter. The customer then pays and collects.

It runs on QBCore, qbx_core, and ESX, auto detects your banking and targeting resources, and stores everything in its own tables.

From scripts.aczone.xyz.

Features

• Full cook-and-serve loop. Customers order, cooks claim, cook, serve. Ingredients are really consumed and finished items really move through inventories.
• 5 cooking stations. Fries, meat, burger, drinks, and the Murder Meal combo. Each has its own recipe, duration, emote, and sound.
• Cooking skill mini-game. A timing bar opens at the station and the cook presses a key to stop it. Where they stop decides the quality: Raw, Undercooked, Cooked, PERFECT, Overcooked, or Burnt. Raw and Burnt destroy the item and waste the ingredients. Perfect pays a bigger tip and bonus XP.
• Employee XP and levels. 10 levels from Trainee to Legendary, earned from cooking, serving, paid orders, and tips received.
• Cook claim tickets. A cook accepts an order to own it. Only that cook can work it, and only the cook who finishes it receives the customer's tip. One-shot server tickets prevent replay and dupe abuse.
• Server-authoritative positions. Every cook, serve, and pay request is checked against the player's real position, so nothing can be fired from across the map.
• Employee tablet. An item-driven iPad-style UI with Orders, Stash, Supplies, Roster, Funds, and Stats tabs, gated by job grade.
• Manager statistics. Revenue, order counts, top items, top cooks, and recent orders, over Today, 7 days, 30 days, or all time.
• Tips. The customer picks cash or bank and adds an optional tip. The society keeps the subtotal, the assigned cook keeps 100% of the tip, online or offline.
• Society funds. Supplies and withdrawals run through whichever banking resource you already use.
• Anti-AFK auto clock-out. Employees who clock in and idle are warned, then forced off duty.
• Audit log and Discord webhook. Every order, void, payment, and supply purchase is recorded.
• Anti-cheat friendly. No os.* calls anywhere. Every timestamp is computed in SQL with UNIX_TIMESTAMP(), so it runs cleanly under WaveShield and similar.

The order flow

1. The customer walks to a till and places an order. The order enters the kitchen and every on-duty employee hears the bell.
2. A cook opens the tablet, accepts the ticket, and the worker HUD appears with the item checklist.
3. The cook takes the ingredients from the kitchen stash into their pocket. Stations do not pull from the stash automatically, this is deliberate.
4. The cook clicks a station, plays the timing mini-game, and the ingredients are consumed server-side. The finished item lands in their pocket and the line flips to cooking.
5. The cook walks to the serve point and serves. The items move into the stash and the lines flip to done.
6. When every line is done the order goes READY and the customer is told to come to the counter.
7. The customer pays at the pay window, picks cash or bank, adds a tip, and collects. The subtotal goes to the society and the tip goes to the cook.

Commands

• /bcancel cancels your own open order (customer side). It reads your open order from the database, so it still works after a rejoin.
• /bvoid [orderId] voids one order. Manager grade only.
• /bvoid all voids every open order, which is the quickest way to clear a stuck or test queue. Manager grade only.

Job grades

The thresholds are Config.Permissions, so you can move them.

Quick start

1. Drop the AC_Burgershot folder into your resources.
2. Add ensure AC_Burgershot to server.cfg.
3. Paste the item block from sql/items_for_ox_inventory.lua into your ox_inventory/data/items.lua, and copy inventory_images/ into ox_inventory/web/images/.
4. Create the burgershot society account in your banking resource.
5. Restart. The tables are created on first boot and the job is registered automatically.

Full detail on Installation.

Developer API (exports)

The server exports are stable across v1.x, which is what the Drive-Thru Addon is built on. Because FiveM drops the second return value of a cross-resource export when the first is nil, the error-bearing exports return a single result table instead.

-- create an order on any channel
local res = exports['AC_Burgershot']:CreateOrder({
    customerSrc  = src,
    items        = { { id = 'hamburger', qty = 1 } },
    channel      = 'drive_thru',   -- 'counter' | 'drive_thru'
    surchargePct = 10,
})
-- res = { ok = true, orderId = 42, displayId = 'B-0042' }
 
exports['AC_Burgershot']:OpenPaymentDialog(customerSrc, orderId)     -- { ok, err }
exports['AC_Burgershot']:ServeItemsForChannel(cookSrc, 'drive_thru') -- { ok, err, message }
exports['AC_Burgershot']:VoidOrder(orderId, 'reason', actorSrc)      -- { ok, err }
exports['AC_Burgershot']:GetOrder(orderId)                           -- the row itself

Client-side getters, useful from an addon that cannot see this resource's Lua state:

exports['AC_Burgershot']:GetMyCID()
exports['AC_Burgershot']:GetMyJobName()
exports['AC_Burgershot']:GetMyGrade()
exports['AC_Burgershot']:IsOnDuty()
exports['AC_Burgershot']:JobName()

And one public event, which any resource can subscribe to:

AddEventHandler('AC_Burgershot:OrderStateChanged', function(orderId, newState, oldState, row)
    -- states: OPEN, KITCHEN, IN_PROGRESS, READY, SERVED, PAID, VOIDED
end)