Your weapon stops being an icon in a menu and becomes an object in the world.

It rides on your back or your hip where everyone can see it. You can hide it under a jacket, hand it to someone, leave brass on the floor when you fire, and read the serial off a gun to find out whose hands it passed through. Free, for any ESX, QBCore, QBox, or OX server — and it does not touch your combat balance.

Inspecting a weapon — the serial, and every player who has carried it.

Every feature is toggled and tuned from here, live, without touching a file.

• The gun is on your body. Rifle across the back, sidearm on the hip, blade at the belt — visible to everyone, in positions the server can tune. Drawing it plays a real holster animation instead of the weapon appearing in your hands.
• Carry two long guns and both are there. A rifle and a shotgun share the same place on your back, and until now one of them was simply invisible. Each gets its own spot, and how you draw either one is an animation the server picked by watching it.
• Hide it under your clothes. A jacket conceals well, a light top conceals badly, a bare torso refuses. Walk around with a subtle tell that you are adjusting something at your belt.
• Weapons jam. How often depends on the condition of the gun, and you clear it under pressure while someone is shooting back.
• Every weapon has a serial, and a memory. Inspect one and you see its serial, its condition, the name engraved on it — and the list of players who have carried it before you.
• Firing leaves brass. Casings stay on the ground, tied to the weapon that fired them. Someone can read a serial off one, or you can pick them up and clean the scene.
• Hand a weapon to another player. They have to accept it. The transfer happens on the server, so nothing duplicates and nothing is lost.
• Store guns where guns go. Wall racks, gun lockers, and vehicle trunks — the weapon is physically in there, with its serial and condition intact.
• Police can pat you down. A badly concealed weapon is found instantly; a well-hidden one takes a search.

• It does not touch combat balance. No recoil changes, no damage changes, no accuracy changes. Everything here is carry, identity, and consequence — so it drops into a server that already has its shooting tuned.
• Configure it in game, not in files. A React dashboard (/mbt_malisling) toggles and tunes every feature at runtime. Changes persist to the database and survive the next update, because they do not live in the resource folder.
• Two interface styles, one switch. Every prompt and HUD ships in Standard (fixed on screen) and Cinematic (anchored beside the weapon in the world). Nothing else about the script changes.
• Clients are never trusted. Inventory, serials, ownership and transfers are all resolved server-side. A faked event gets nothing, and every inbound net event is rate-limited per player.
• One resource, four frameworks, two inventories. ESX, QBCore, QBox and OX are auto-detected; ox_inventory is primary with a complete qb-inventory bridge.
• oxmysql is optional. Without it the script runs DB-free and only the persistence features step aside. Nothing breaks.
• English, Italian and French included, and adding a language is one file.

Frameworks: ESX · QBCore · QBox · OX (auto-detected).

⚠️ Upgrading from 1.x? Replace the whole folder — do not keep your old config.lua

The old config.lua opens with MBT = {}, and it is loaded after default.lua. Keeping it wipes every default the new version needs, and the script will not start.

Configuration also moved. In 1.x everything lived in config.lua; now feature tuning lives in default.lua and is meant to be changed live from the dashboard, while config.lua holds only server settings (admin command, language, notifications, webhooks). Your 1.x tuning will not carry over — set it again from the dashboard, where it will persist to the database and survive future updates.

Delete the old folder, drop in the new one, and re-apply your settings. There is no migration path: 2.0 is effectively a different script.

1. Download or clone this repository into your server's resources folder.

2. Add to your server.cfg (after your framework and inventory):

   ensure ox_lib
   ensure ox_inventory      # or qb-inventory
   ensure mbt_malisling

   After the first start, restart the server once so the sling convar applies cleanly.

3. (Optional) Register the gun-rack item if you want players to place racks from inventory.

   ox_inventory — ox_inventory/data/items.lua:

   ['gunrack'] = {
       label  = 'Gun Rack',
       weight = 8000,
       stack  = false,
       server = { export = 'mbt_malisling.gunrack' },
   },

   qb-inventory — qb-core/shared/items.lua:

   ['gunrack'] = { name = 'gunrack', label = 'Gun Rack', weight = 8000, type = 'item',
       image = 'gunrack.png', unique = true, useable = true, shouldClose = true,
       description = 'Wall-mountable weapon rack' },

   The item name, the server.export suffix, and MBT.WeaponRack.Placement.Item in default.lua must all match.

4. Restart your server, or run ensure mbt_malisling in the live console.

5. Open the admin dashboard in-game with /mbt_malisling (admin only) and tune to taste.

Configuration is split across two files plus the live dashboard:

• default.lua — the complete default block for every feature (toggles, thresholds, animations, positions). Loaded first. Most values are meant to be tuned live from the dashboard, not by hand.
• config.lua — server settings and every keybind: Admin (command + ACE permission), Keybinds, QBWeapons, Language, Debug, Notification, ReduceMotion, VersionCheck, and the Discord audit webhooks. Loaded after default.lua, so it can override any default.
• Dashboard (/mbt_malisling) — toggles and tunes features at runtime; changes persist to the mbt_malisling_config database row and survive resource updates.

-- config.lua
MBT.Language = 'en'      -- 'en', 'it', 'fr'
MBT.Debug    = false     -- debug logs + dev tuning commands

MBT.Admin = {
    Command    = 'mbt_malisling',
    Permission = 'command.mbt_malisling',   -- ACE permission for the dashboard + placement
}

Notifications: the notify function in config.lua ships presets for ox_lib, ESX, QBCore, QBox, and native GTA — uncomment the one that matches your server.

Every key the resource binds is listed together in config.lua, under Keybinds. Set '' for no key: each feature keeps its chat command either way.

They are the one setting the dashboard cannot change, and there is a reason. Bindings register once when the resource starts, and FiveM then caches them per player profile — so changing a key later moves nothing for anyone who has already joined your server. After that point it is the player who rebinds, in GTA Settings → Key Bindings → FiveM, where every binding appears prefixed with [MBT].

Two things worth knowing. The holster prompt's two bindings each carry the input family they belong to; change Key and Input together, because a keyboard key left on MOUSE_BUTTON never fires and never says so. And config.lua is replaced when you update, like every other file in the folder — keep a note of your keys, or you will set them again after the next release.

Most police uniforms — GTA's own and nearly every EUP pack — have a duty holster with a pistol modelled into the clothing. We attach ours on the same hip, so the officer ends up with two. The second one lives in the mesh: nothing can see it or move it.

Hide ours for that job, in config.lua:

MBT.HiddenByJob = {
    ['police'] = { ['side'] = true },
}

Keys are body slots, not weapon families: side is every pistol, back every long gun. The rule applies to everyone who sees that officer, and it re-evaluates the moment they change job.

The job '*' means everyone. Use it when a slot should never show at all — pistols that draw normally and never hang on the hip — rather than listing every job on your server to mean "never":

MBT.HiddenByJob = { ['*'] = { ['side'] = true } }

It is per job, not per outfit — an officer in plain clothes has the same job and no modelled holster, and loses their pistol too. Use two jobs if you need the distinction. And if you would rather move our pistol than remove it, MBT.CustomPropPosition in default.lua has done that all along.

Weapon drops, armory racks and pat-downs can each post to a Discord webhook. The URLs live in config.lua and not in the dashboard: a webhook is a secret, and the dashboard is rendered on the player's side. They sit behind an IsDuplicityVersion() guard so they never reach a client.

-- config.lua
if IsDuplicityVersion() then
    MBT.WeaponDrop.Logging.Webhook = 'https://discord.com/api/webhooks/...'
    MBT.WeaponRack.Logging.Webhook = ''
    MBT.PatDown.Logging.Webhook    = ''
end

Leave a URL empty (the default) and that log stays off. No webhook, no logging — nothing else to switch.

At startup the server asks the GitHub Releases API whether a newer version exists, and the dashboard shows a badge if so. It is one plain GET and sends nothing about your server. Set MBT.VersionCheck = false in config.lua if you'd rather it made no outbound request at all.

Every one of these is a FiveM keymapping, so a player can rebind it in Settings → Key Bindings → FiveM. The defaults live in each feature's block in default.lua as Key.

Drawing a sidearm shows a confirm prompt: its two keys are set in MBT.HolsterControls.

Every command name is configurable — each feature's block in default.lua has a Command field, and the dashboard's is MBT.Admin.Command in config.lua.

Client-side, for other resources on your server. These are the supported ones — treat anything else you find in the source as internal and subject to change.

-- after applying a new outfit or ped model
exports.mbt_malisling:ResetWeaponsOnBack()

For anyone reading the code before trusting it on their server.

• Server-authoritative. Inventory contents, serials, ownership and transfers are resolved from the server's own view. A client that claims to hold something it does not hold gets nothing.
• Per-event rate limiting on every inbound net event, keyed per server ID.
• Serials are written only on safe transitions — never while a weapon is being fired — because writing item metadata mid-fire triggers an inventory refresh that would visibly re-spawn the slung prop.
• Strict-ready state bags. Replicated state (concealed, scope, flashlight) is written by the server only, so a client cannot declare itself concealed.
• Handoff and ammo transfer are atomic, with rollback. Both sides consent, and a failure halfway leaves the item where it started rather than in neither inventory.
• Chain of custody lives outside the weapon's metadata, deliberately: writing it on the equip path would re-trigger the inventory update above.
• Self-managed persistence. The optional oxmysql tables are created on first run and prefixed mbt_malisling_*. Without oxmysql those features gate themselves off and the rest runs DB-free.
• The ox_inventory patch fails loudly. It keeps a .bak, is idempotent, and refuses to write if a future update moves the anchors it looks for, rather than corrupting the file.

Written down rather than left for you to discover.

A slung weapon's flashlight follows the weapon in your hands. Put a rifle with the flashlight component on your back while the light is on, then toggle the light on a different weapon, and the slung one changes with it.

This is the engine, not the script: GTA ties a weapon object's flashlight rendering to a single flashlight state on the ped, so any SetFlashLightEnabled — from us or from any other resource — reaches every weapon object that ped owns, including props on the back. We tried re-asserting the light source per object, blocking the toggle control, monitoring and reverting the state, and drawing a custom light; each either broke the rendering, was bypassable, flickered, or left the physical lens flickering anyway because the engine draws it. Fixing it properly means replacing the whole flashlight system, which is more than this script should be. The flashlight's saved state across equip and relog is correct — it is only the live mirroring that bleeds.

On qb-inventory, prompts are a beat less immediate. ox_inventory fires native events we hook directly; qb has no equivalent, so that bridge polls the inventory for changes. Everything works, but expect slightly less snappy holster prompts. If you have the choice, pair this with ox_inventory.

The qb-inventory bridge has full feature parity with ox_inventory on all load-bearing paths (stow/retrieve/transfer preserve the serial, no duplication). A few qb-specific notes:

• qb-weapons: disable its draw animation (client/weapdraw.lua) — it animates every weapon swap through UNARMED, which conflicts with any weapon-on-back system. The dashboard surfaces a warning when it's active.
• Ammo Sharing: ammo is matched by qb-core's default ammo item names (pistol_ammo, rifle_ammo, …). If you renamed your ammo items, extend the QB_AMMO map in modules/inventory/qb/server.lua.
• Equip-on-retrieve at a rack/trunk is best-effort on qb (the weapon is always returned to the inventory; the auto-equip may occasionally no-op due to a replication-timing window).
• Forensic casing serials fall back to the client-reported value on qb (ox resolves them server-side).
• Player-placed racks and other persistence features require oxmysql.

Does it work with ESX, QBCore, QBox, and OX? Yes — the framework is auto-detected. Inventory is ox_inventory first, with a complete qb-inventory fallback.

Do I need oxmysql? No. Without it the script runs DB-free; only the persistence features (placed racks, trunk storage, chain of custody, saved positions) are disabled, and everything else works.

Does it modify ox_inventory? It applies a small, automatic patch to ox_inventory's weapon module at startup so the holster prompt can hook the equip/disarm flow. It is re-applied on every start, keeps a .bak, and refuses to touch the file if a future ox_inventory update moves the anchors it looks for — it fails loudly instead of corrupting anything. If it can't write (read-only or locked-down host), see below.

The patch failed. How do I apply it manually? Both manual installers ship in tools/ — run the one for your server's OS:

# Linux / macOS
chmod +x tools/install_ox_patch.sh && ./tools/install_ox_patch.sh

# Windows
.\tools\install_ox_patch.ps1

Each finds ox_inventory on its own (or takes the path as an argument), keeps a .bak, and is safe to re-run — it restores its own backup first, so the patch is never applied twice. The usual reason to need them is a permissions one: the server process could not write to ox_inventory, and running as a user who can fixes it.

If you would rather do it yourself, only one file changes: ox_inventory/modules/weapon/client.lua.

1. Back it up.
2. Paste the contents of patches/ox_hook.lua immediately before the line:

   sleep = anim and anim[3] or 1200

3. Paste the contents of patches/ox_append.lua immediately before the last return Weapon in the file.
4. Restart ox_inventory, then mbt_malisling.

That is the whole patch — the first block asks malisling whether to holster or keep the weapon in hand, the second lets it register per-weapon holster animations. Re-apply after any ox_inventory update.

To stop the resource patching ox_inventory on its own — because you applied it yourself, or your host manages that file — put this in server.cfg:

setr malisling:autopatch false

My weapon doesn't show on my back. Make sure ox_inventory's weapon animation convar is enabled (inventory:weaponanims 1), and on qb that qb-weapons' weapon-draw animation is disabled. Check the F8 console for warnings.

How do I add a language? Copy locales/en.lua to e.g. locales/de.lua, translate the strings, and set MBT.Language = 'de'.

How do I position the slung weapon / rack weapons? Use the dashboard's Position Editor for body positions (per type and per job), and /mbt_racktune / /mbt_trunktune for rack and trunk offsets.

Developed by the Malibu Tech Team.

MalibuTech was founded with my brother Gianmarco. He was the scripter, and Malisling was his — the first commits are from January 2023, and he kept working on it through that June.

Three of his decisions are still load-bearing in 2.0, after everything around them has been rewritten:

The jamming never polls. He hung it on CEventGunShotWhizzedBy, a game event that only fires when a round passes close by. There is no thread asking "is he shooting yet" — the cost is zero until a shot is actually fired. It is still exactly where he put it.

dropCurrentWeapon is his. He added it in June 2023 so other resources could make a player drop the gun in their hands. It is still in the export table above, unchanged, and it is what a surrender or arrest script calls today.

He built the resource to know male peds from female ones, and gave every carry position a separate value for each — then left the two sets identical, with tuning the female offsets still on his list. The structure he left is the reason the Position Editor in this version can be per body, per weapon type, and per job at all.

The code around all of it has been rewritten many times since. The shape of it is still his.

DarkSideofTheCode was his name in the FiveM community. It stays on his work.

Thanks to the FiveM community for continuous feedback and testing.

This project is licensed under the PolyForm Noncommercial License 1.0.0.

You are free to use and modify this software for noncommercial purposes only — personal use, hobby servers, research, and education. Any commercial use, redistribution for profit, or inclusion in paid products is prohibited without written permission from Malibu Tech Team.

• Showcase: YouTube
• Cfx release thread: forum.cfx.re
• Documentation: malibutechteam.com/docs

Copyright 2023-2026 MalibuTech.