Framework hub
Move into the QBCore landing page to compare verified scripts, framework fit, and install-ready products built for modern FiveM servers.
Open QBCore hubOnce you know the direction, jump into the highest-leverage commercial hubs for verified scripts, curated bundles, and framework-specific buying paths.
Framework hub
Move into the QBCore landing page to compare verified scripts, framework fit, and install-ready products built for modern FiveM servers.
Open QBCore hubPremium catalog
Move from research into the main shop to compare real products, framework labels, screenshots, and production-ready quality signals.
Open premium shopLaunch faster
Bundles shorten the path from planning to launch by grouping the highest-leverage scripts into a cleaner commercial starting point.
View bundlesEnabling DLC (Downloadable Content) for your FiveM server allows you to offer players the latest maps, clothing, vehicles, and more. This guide will walk...
Enabling Cayo Perico in your FiveM server can enhance the gameplay experience by adding a new island for your players to explore. Here’s a simple...
Turn your FiveM server into a sparkling winter wonderland in minutes—just drop a Lua script and let players toggle snowfall with /enablesnow and /disablesnow. Create, activate, and enjoy snowy skies a
Want handcuffed players to move around in FiveM without losing realism? Our friendly guide walks you through easy code tweaks for QBCore, ESX, and vRP, enabling movement while keeping the unwanted act

Guide: Allowing Movement While Handcuffed (FiveM) In role‑play servers with FiveM, handcuffs add a touch of realism and tension. Many players discover that the default freezing behavior can be too restrictive, making the experience feel artificial. This guide shows you how to let players move while handcuffed across all popular frameworks—QBCore, ESX, and vRP—while still preventing the most obvious actions like shooting or driving. ---
When a player is cuffed, the server toggles three client-side things: the handcuff animation plays (mp_arresting/idle), SetEnableHandcuffs flips the cuffed-state flag, and the entity is usually frozen with FreezeEntityPosition to lock the player in place. To let players walk while cuffed, unfreeze the entity but keep the offensive-action controls disabled via DisableControlAction on a continuous client thread. The exact line to change depends on your framework — covered below for , , and vRP. ---
Search the police job or utility scripts for the cue that triggers handcuffing. It normally looks like: ```lua TaskPlayAnim(playerPed, 'mp_arresting', 'idle', 8.0, -8, -1, 49, 0, 0, 0, 0) SetEnableHandcuffs(playerPed, true) FreezeEntityPosition(playerPed, true) ```
Replace the freeze call: ```lua FreezeEntityPosition(playerPed, false) -- Allows free walking ``` Your updated snippet becomes: ```lua TaskPlayAnim(playerPed, 'mp_arresting', 'idle', 8.0, -8, -1, 49, 0, 0, 0, 0) SetEnableHandcuffs(playerPed, true) FreezeEntityPosition(playerPed, false) ```
Create a continuous thread that disables the potentially problematic actions: ```lua Citizen.CreateThread(function() while true do Citizen.Wait(10) if IsHandcuffed then DisableControlAction(0, 24, true) -- Attack DisableControlAction(0, 25, true) -- Aim DisableControlAction(0, 142, true) -- MeleeAttackAlternate DisableControlAction(0, 75, true) -- Leave Vehicle DisableControlAction(0, 92, true) -- Shoot in vehicle end end end) ``` Replace `IsHandcuffed` with the variable that indicates the do‑handcuff state for your specific script. ---
Find `esx_policejob/client/main.lua` and locate the following code: ```lua TaskPlayAnim(playerPed, 'mp_arresting', 'idle', 8.0, -8, -1, 49, 0, 0, 0, 0) SetEnableHandcuffs(playerPed, true) SetPedCanPlayGestureAnims(playerPed, false) FreezeEntityPosition(playerPed, true) ```
Change `FreezeEntityPosition(playerPed, true)` to `false` so that walking is possible.
Implement a similar thread to keep weapons and vehicle controls at bay: ```lua Citizen.CreateThread(function() while true do Citizen.Wait(10) if IsHandcuffed then DisableControlAction(0, 142, true) -- MeleeAttackAlternate DisableControlAction(0, 30, true) -- MoveLeftRight DisableControlAction(0, 31, true) -- MoveUpDown DisableControlAction(0, 24, true) -- Shoot DisableControlAction(0, 92, true) -- Shoot in car DisableControlAction(0, 75, true) -- Leave Vehicle end end end) ``` Be sure to link `IsHandcuffed` to your ESX handcuff flag. ---
The core logic often resides in `vrp/modules/police.lua` or a custom resource. Look for: ```lua vRPclient.playAnim(player, {true, {{mp_arresting, idle}}, true}) vRPclient.setHandcuffed(player, true) vRPclient.setFreeze(player, true) ```
Swap the freeze line: ```lua vRPclient.setFreeze(player, false) ```
Insert or modify a client script to continuously disable undesired controls: ```lua Citizen.CreateThread(function() while true do Citizen.Wait(10) if IsHandcuffed then DisableControlAction(0, 24, true) -- Attack DisableControlAction(0, 25, true) -- Aim DisableControlAction(0, 142, true) -- MeleeAttackAlternate DisableControlAction(0, 75, true) -- Leave Vehicle DisableControlAction(0, 92, true) -- Shoot in vehicle DisableControlAction(0, 30, true) -- Move Left/Right DisableControlAction(0, 31, true) -- Move Up/Down end end end) ```
Define a global variable and listen for a server‑side event: ```lua local IsHandcuffed = false RegisterNetEvent('vrp:handcuff') AddEventHandler('vrp:handcuff', function(status) IsHandcuffed = status end) ``` Trigger this event whenever a player is handcuffed or released. ---
Test on a staging server before pushing live — police-script changes are one of the easiest ways to brick an arrest flow on a busy night. Audit your final DisableControlAction list against the official control reference so you don't accidentally re-enable shooting or vehicle entry. If your server uses QBCore or ESX, pin to a specific release tag and document the patch in your repo so future framework upgrades don't silently revert this change.
Treat How to Allow Movement While Handcuffed in FiveM as a production server change, not as a one-off edit. Before it goes live, one staff member should test the flow with a normal player account while another watches the server console. Record which resource was started, which config file changed, and which dependencies must run before it. If an item, job, command, menu, or marker is not visible to the correct role, the change is not ready for release.
Check the player experience as well as the admin experience. A setup is stable only when joining, spawning, inventory usage, interaction, and disconnects work without new warnings. For performance-related topics, a short test on an empty server is not enough. Run at least one realistic scenario with multiple players, vehicles, or active scripts so you can see whether the behavior changes under load.
Finally, document the decision in your staff Discord or server wiki: what changed, why it changed, which file is affected, and how to roll back. This small note saves time later because support staff do not have to guess which version is live or which dependency should be checked first.
After implementation, write down which decision you made and which alternative you deliberately skipped. That matters on a FiveM server because several admins often touch the same resources over time. If a problem appears later, the team needs to know whether the likely cause is a config change, a framework update, a new script, or an external dependency. Record the framework version, the resource name, the file that changed, and the date of the change.
Plan a short follow-up test after the first real play session. Many problems only appear when several players spawn vehicles, open menus, change jobs, trigger inventory metadata, or synchronize Discord roles at the same time. Collect feedback in a structured way: what action the player took, which error appeared, which role or job they had, and whether the problem survived a reconnect. That turns scattered complaints into a useful pattern that developers can actually reproduce.
If the topic touches gameplay balance, do not treat technical success as the only success condition. A feature can be technically correct while still causing support load, unfair payouts, confusing menus, or avoidable staff interventions. Review the first logs, compare the behavior against your rules, and adjust the configuration before players build habits around a broken value.
Use this section as a release checklist before you apply the change on a live FiveM server. Start by copying the current configuration, listing the resources touched by the change, and checking whether the topic depends on your framework, database, inventory, jobs, Discord roles, or txAdmin permissions. Many FiveM problems are not caused by the feature itself. They come from the wrong startup order, missing dependencies, inconsistent item names, or unclear staff permissions.
After the first restart, read the server console before inviting players to test. Warnings about missing exports, missing items, unknown job names, failed SQL queries, or duplicated resources should be solved immediately. If you are changing several things at once, test each resource separately with a fresh character and with an admin account. That makes it easier to tell whether the issue is inside the resource, inside an ESX/QBCore/QBox bridge, or inside your server configuration.
A production server also needs a rollback plan. Keep the previous script or config version, note the database tables involved, and decide when you will revert instead of debugging live. A practical rule is simple: if players cannot join, interact, or keep their items normally after ten minutes, roll the change back and continue on a staging server. Stability matters more than shipping one extra feature during peak hours.
The most common mistake is testing only with administrator permissions. Many systems work for admins but fail for normal players because of ACE permissions, job grades, Discord role checks, or inventory metadata. Test at least three roles: normal player, staff member, and full admin. Write down which commands, items, menus, or map markers should be available to each role before you call the setup finished.
Another common mistake is ignoring monitoring after the change. Watch resmon, txAdmin warnings, client console errors, and Discord feedback for the first play session. If a resource constantly uses too much time or creates repeated client errors, it lowers server quality even when the feature appears to work. Larger changes should go through a short maintenance window with a clear testing checklist.
These resources help you treat How to Allow Movement While Handcuffed in FiveM as part of the full server stack instead of an isolated fix. The better your setup, framework, rules, marketplace resources, and monitoring work together, the fewer support issues you will have after launch.