Use the item definitions below to let your inventory open Restaurant products. Keep the item metadata1 intact. Use these exports through the inventory item definitions.
Ox inventory product use#
The server export useRestaurantProduct is installed on the provider2 item definition:
['restaurant_product'] = {
label = 'Restaurant Product', weight = 1, stack = false,
close = true, consume = 0,
server = { export = '0r-restaurant.useRestaurantProduct' }
},
Ox calls this export when the player uses the item. Its arguments are (event, item, inventory, slot); keep the export in the item definition shown above.
Do not call it as exports...useRestaurantProduct(playerId, metadata); those are different arguments. Keep consume = 0 so Restaurant handles portions and removal without Ox consuming the item again.
Ox delivery-bag use#
The corresponding registered item is:
['restaurant_packaged_product'] = {
label = 'Delivery Bag', weight = 1, stack = false,
close = true, consume = 0,
server = { export = '0r-restaurant.usePackagedProduct' }
},
Ox calls this export when the player uses a delivery bag. Use the same item-definition format. Carrying the bag animation alone does not consume it or open its contents.
Use the complete three-item installation examples, including material non-stacking. Do not copy the usable export onto a raw ingredient item.
Non-Ox usable items#
The framework bridge registers usable items. A QB or custom inventory callback must pass the item's actual slot. If an ESX inventory callback has no slot, adapt that callback instead of guessing from the item label.
Follow the comments in modules/bridge/framework/ and modules/bridge/inventory/. Preserve full metadata and slot ownership; let Restaurant own partial portions, exact replacement and final removal. Do not register a second callback that also removes the same product.
Companion exports are presentation calls#
The 0r-restaurant_assets exports handle models, animations and placement for Restaurant. Use the main resource's supported integrations for gameplay actions.
Register item use through the main resource as shown above.
Events and NUI callbacks#
Manage restaurants and orders through the Restaurant panel.
For a custom framework or inventory, follow the existing custom bridge contract. For item-use problems, use Inventory Problems and include the calling resource and item slot in your support report.
Signatures and observable results#
Both public item-use exports run on the server and are called by Ox through the registered item definition, not by a player command.
| Export | Required arguments | Return / result |
|---|---|---|
useRestaurantProduct(event, item, inventory, slot) | event: string must be usingItem; item: table must identify restaurant_product; inventory: table supplies the player id; slot: number is the exact used slot | Returns false so Ox does not consume automatically. A valid call starts Restaurant usage; false itself is not a food-use success result |
usePackagedProduct(event, item, inventory, slot) | Same Ox callback shape; usingItem invokes the bag action for inventory.id and the exact slot; the item argument is unused by this hook | Returns false for usingItem, otherwise no result. A valid bag action opens its supported presentation; failure notifies the player |
No argument is optional in an installed Ox callback. Product use also checks that the invoking resource is ox_inventory. Keep consume = 0 on both item definitions. Observe the player's usage prompt/bag and inventory result to verify success. Do not treat a return value as an item grant API.
Footnotes
-
Extra details saved with an inventory item, such as its material, quantity and restaurant. Read the definition. ↩
-
An installed framework, inventory or interaction system used by Restaurant. Read the definition. ↩