Adding recipes and spots

Everything the resource does is driven by the files in shared/. Adding processing never means editing client/client.lua or server/server.lua.

There are two things you can add:

a recipe — one more entry in an existing spot's items table;
a spot — a new file in shared/, with its own location, blip and recipes.

shared/template.lua is the reference for both. It shows every field a spot can set, including the optional job and gang gate that the two chicken examples leave out.

Before you start

Both the produced item and every required material must already be defined in qb-core/shared/items.lua, with a label and a weight. The resource reads QBCore.Shared.Items[...] directly in four places and never checks for nil, so a typo in an item name will throw an error rather than show a warning. Items also need an image in ps-inventory if you want them to look right in the bag.

Adding a recipe to an existing spot

Open the spot's file and add one more entry to items. The key is the item the player receives.

    items = {
        ["chicken_breast"] = {
            -- existing recipe
        },
        ["chicken_wings"] = {
            processingDesc = "Verarbeite...",
            required = {
                ["plucked_chicken"] = 1
            },
            amount = 2,
            animation = {
                dict = "anim@amb@business@weed@weed_inspecting_lo_med_hi@",
                anim = "weed_crouch_checkingleaves_idle_01_inspector",
                flags = 8
            },
            duration = 6000,
            icon = "fa fa-hand"
        }
    }

That is the whole change. The extra recipe appears in the spot's menu on the next restart, and its required items are listed underneath its name.

To restrict it, add job and/or gang:

            job = {"butcher"},
            gang = {"leone"},

Those two lists are OR'd together — a butcher gets in, and so does a Leone member. Leaving both out means anyone can use the recipe.

Adding a new spot

Copy template.lua to a new file in shared/, named after what it does, for example shared/fish_fillet.lua. Any .lua file in that folder is picked up by the shared/*.lua glob in fxmanifest.lua; there is no list to register the file in.
Change spotName. It has to be unique across all spot files, because it is the key in Config.ProcessingSpots and the prefix of the qb-target zone names. It does not have to match the file name.
```
local spotName = "fish_fillet"
```
Set label and icon. These are what the player sees when they look at the zone, and they are reused as the menu header.
Set the blip, or delete the whole blip = { ... } table if the spot should not show on the map. Do not leave a partial table behind: when blip is present, every field in it is read.
Set the zones under spots. Stand where you want the zone, read your coordinates off a dev tool, and fill in coords, length, width, heading, minZ, maxZ and distance. Add [2], [3] and so on if the same menu should be reachable from several counters.

To see what you built, set Config.ShowPolyDebug = true in shared/config.lua and restart — every zone is then outlined in the world. Turn it off again afterwards.
Replace the items table with your own recipes, as above.
Restart the resource. Spot files are read once at startup and the zones and blips are built once, so refresh alone is not enough.

The bottom of the file — the CreateThread that writes options into Config.ProcessingSpots — should be left as it is. It is what makes the file a spot at all.

Chaining spots

The two chicken files show a chain: plucked_chicken.lua turns chicken into plucked_chicken, and cut_chicken.lua turns plucked_chicken into chicken_breast. Nothing special is needed for this. A recipe's product is just an item, so naming it in another recipe's required table is all a chain is.

Two behaviours worth knowing

A single action can pay out several batches. The server works out how many complete batches the player currently has materials for and processes all of them in one go — a recipe needing 1 plucked_chicken will consume all twelve a player is carrying and hand back twelve products, for one progressbar of duration milliseconds. If you want processing to be slow, the batch size has to be the limiting factor; raising duration on its own does not help.

Nothing checks that the recipe is reachable. The job and gang test happens on the client, and the server takes the recipe table it is sent at face value. Keep that in mind when a recipe's product is worth much more than its materials.

FilesExpand file tree

recipes.md

Latest commit

History