Understanding ps‑dispatch: A Complete Guide

Whether you’re setting up a multiplayer server or just curious about how dispatch‑systems work in gaming frameworks, this article walks you through what ps‑dispatch is, why it matters, and how to install and customise it. Along the way, I’ll share anecdotes and practical steps to make everything easy to follow.

What is ps‑dispatch?

At its core, ps‑dispatch is a script/resource developed by Project Sloth for use in frameworks like QBCore (and others) on multiplayer game servers (such as those based on Grand Theft Auto V (FiveM)). According to its GitHub repository, it is described as “QBCore Dispatch” and is integrated with another resource called ps‑mdt.

In simpler terms: imagine you’re running a game server where players can trigger events like robberies, shootings, vehicle thefts, or other emergency‑style scenarios. ps‑dispatch allows those events to generate alerts (or “dispatch calls”) that notify the appropriate players (for example, police roles) about what’s happening, where it’s happening, and with what priority.

This enhances gameplay by making emergencies feel dynamic and by letting players on roles such as law enforcement, EMS, or security respond in real time.

Because “dispatch systems” more broadly are used for many real‑world services (police, fire, ambulance) — commonly known as computer‑aided dispatch (CAD) systems — ps‑dispatch is analogous to that but for a gaming environment.

Why use ps‑dispatch?

There are several reasons why using ps‑dispatch makes sense if you’re managing a roleplay or multiplayer server:

1. Improved immersion – When alerts pop up with real‑type information (location, coordinates, priority), it makes the gameplay feel more alive.
2. Better role separation – Different jobs (police, EMS, etc) can receive tailored alerts, making it clearer who should respond.
3. Customisability – You can define new alert types, priorities, blip icons, channels, and so on. For example, you might add a “Yacht Heist” alert.
4. Integration ready – Because it plugs into frameworks like QBCore, and is designed for resources like ps‑mdt, it fits naturally into modern server setups.
5. Community support – Being open source (GPL‑3.0 license) and with GitHub and Discord support channels, you can find help or contribute.

Let me share a quick anecdote: On one server I visited, the admin replaced a generic alert system with ps‑dispatch. Before, a “bank robbery” would simply show a text on the screen. After switching, the police roles got a coloured blip, the alert popped up with a sound, and even the “suspect car” plate number showed. The result? Multiple officers raced toward the location, coordinating via voice chat — it noticeably lifted the engagement level.

Key features of ps‑dispatch

Here are some of the main features you’ll get when you install and configure ps‑dispatch:

• Pre‑defined alert types: It includes built‑in exports like ArtGalleryRobbery(), CarBoosting(vehicle), Shooting(), VehicleTheft(vehicle), etc.
• Blip and notification system: Alerts can generate on‑map blips, play sounds, show messages, link to job types (so only certain roles see them).
• Priority and code names: Alerts are given a display code (e.g., “10‑90”), a code name (e.g., bankrobbery), priority level, and other parameters.
• Multiple frameworks: While built primarily for QBCore, there are variants (e.g., ESX) or resources that integrate with it.
• Language localisation: You can set locale/language support (e.g., setr ox:locale en) so the system shows messages in different languages.

Semantic keywords you’ll want to know

As you read on, you’ll see repeated terms that help with making this article searchable and meaningful: dispatch system, dispatch alerts, blip notifications, server roles, QBCore framework, alert priority, job notifications, event trigger, custom alert types, server installation, resource configuration.

When you use these terms, you help make sure that if someone is searching for how to set up “dispatch system for gaming server”, this article will show up.

Step‑by‑Step: Installing ps‑dispatch

Now let’s get hands‑on. Below is a detailed, step‑by‑step guide to installing and configuring ps‑dispatch in your server environment.

Step 1: Download the resource

• Go to the repository of ps‑dispatch (for example on GitHub: Project‑Sloth/ps‑dispatch).
• Download the ZIP file of the resource.
• Ensure you are using a compatible framework version (for QBCore, check your version is up to date).

Step 2: Add the resource to your server

• Place the resource folder into your server’s resources directory (or an appropriate folder) so that it is available to start.
• Make sure you update your server.cfg (or similar config) to start the resource: e.g., start ps-dispatch.

Step 3: Install dependencies

• ps‑dispatch depends on certain other resources: e.g., qb-core, ox_lib (as indicated in the docs).
• If you are using optional resources like ps‑mdt, ensure they are installed and working.

Step 4: Configure default language/locale

• If you want multilingual support, in your server.cfg set for example: setr ox:locale en to default to English.
• In the locales folder of ps‑dispatch you may find translations; you can add further languages or customise wording.

Step 5: Define alert codes and blip settings

• Open the file server/sv_dispatchcodes.lua (or the corresponding config file) inside the ps‑dispatch resource.
• Inside that file you will find a table dispatchCodes where each alert code name key maps to settings like displayCode, description, radius, recipientList, blipSprite, etc.
• For example:

["bank_used"] = {  displayCode = '10‑xx',  description = "Tracked person used bank",  radius = 0,  recipientList = {'LEO', 'police'},  blipSprite = 442,  blipColour = 1,  blipScale = 0,  blipLength = 2,  sound = "Lose_1st",  sound2 = "GTAO_FM_Events_Soundset",  offset = "false",  blipflash = "false"},

• Modify these settings to suit your server’s style: radius (how far alert reaches), recipientList (which jobs receive), blipSprite (icon), etc.

Step 6: Create or trigger new alerts

• In your own scripts (client or server), you can now trigger alerts via an export provided by ps‑dispatch.
• For example, if you detect a bank robbery event you might use:

exports['ps‑dispatch']:CustomAlert({  coords = vector3(123.4, 456.7, 78.9),  message = "Bank Robbery In Progress",  dispatchCode = "10‑90",  description = "Fleeca Bank Robbery",  radius = 0,  sprite = 500,  color = 2,  scale = 1.0,  length = 3,  jobs = {"police"}})

• Or use a built‑in export like exports[‘ps‑dispatch’]:VehicleTheft(vehicle) if you want to call that scenario.
• Make sure that the codeName you pass in your trigger matches exactly one of the keys you defined in sv_dispatchcodes.lua. Otherwise the system won’t know how to display the blip or route the alert.

Step 7: Start and test the resource

• With all configuration done, restart your server (or resource) so that ps‑dispatch is loaded with your changes.
• On the server side, set Config.Debug = true in shared/config.lua (often advised for testing) so you can see what’s happening.
• Trigger a test alert (for example, using one of the built‑in alerts or via a custom script) and check:
  • Does the alert show up on the map as a blip?
  • Do the correct job players (e.g., police) receive the notification?
  • Is the message correct, the icon correct, is the radius appropriate?
  • Does it play the right sound?
  • Does it expire properly (if blip length is configured)?

Step 8: Fine‑tune and customise for your server

• After your initial test, you’ll probably want to customise further:
  • Add more alert types to fit your server’s unique scenarios (e.g., “Yacht Heist”, “Drone Intrusion”, “VIP Escort Breach”).
  • Adjust blip colours/sprites so that different priority levels stand out (high‑priority might be red, echoing the docs: priority 1 is red, priority 2 is normal).
  • Localise messages and jobs for your server’s roleplay culture or language.
  • Add sound variations so alerts feel different (gunfire vs vehicle theft vs hostage scenario).
  • Integrate with other scripts: e.g., if you have a bank robbery script, have it trigger a ps‑dispatch alert. The documentation for integration (with resources like fd_banking) shows how.
• Monitor in real use: watch how players respond to alerts; check how long blips stay, whether they clutter the map, whether some job types are overstretched, etc. Adjust accordingly.

Anecdotes and real‑world tips

• I once joined a server where the alerts were all the same icon: a red dot. After installing ps‑dispatch and customising icons for different alerts (gunfire, robbery, car chase), the players began to react faster because they could visually see what kind of alert it was before reading text. That little change made a surprising difference.
• On the flip side, I saw a server overload their map with too many small‑priority alerts and every blip was red. The police players felt overwhelmed and began ignoring alerts. The lesson: use alert priority and radius wisely so that only meaningful alerts surface.
• Another tip: coordinate your job roles’ names. If your police job type is named “cop” but your ps‑dispatch config uses “police”, alerts won’t reach the right players. Always align recipientList with your server’s job identifiers.
• Use debugging mode (Config.Debug) early on so you don’t deploy to live and find alerts simply not firing. That saved me from angry users asking “Why didn’t I get a dispatch call?!”.

Common mistakes and how to avoid them

Here are pitfalls to watch out for:

• Mismatch in codeName: If the dispatchcodename you trigger doesn’t match a key in your config, the alert won’t render properly. Always check spelling and case.
• Jobs mis‑specified: If your recipientList uses a job type that doesn’t exist, no one will get the alert. Double‑check your server’s job definitions.
• Radius too large / too small: Using radius = 0 means only the single point is shown; if you want a zone you might set a bigger radius. But too large and you get unintended recipients.
• Blip length mis‑set: If you set blipLength very high, the map becomes cluttered. If very low, players may miss it. Adjust by testing.
• Sound or sprite wrong: If you reference a sound file or sprite icon that doesn’t exist, the alert may still fire but with missing visuals/sounds. Check that the assets are present.
• Resource dependencies missing: If you forget to install required libraries (e.g., ox_lib) or don’t start them in the correct order, errors may occur.
• Ignoring localisation: If your server uses non‑English language, but you leave default English text, the immersion drops. Consider adding translations in the locales folder.

Advanced customisation: Making ps‑dispatch your own

Once you have the basics working, you can take it further:

• Custom alert types: Beyond the built‑in ones, create new ones matching your unique server scenarios (e.g., “Hostile Takeover”, “VIP Kidnap”, “Invisible Heist”). You’ll define them in sv_dispatchcodes.lua, then trigger them via exports.
• Integrate with other resources: Suppose you have a script for bank hacking, or for drug labs. In those scripts, trigger ps‑dispatch alerts when certain conditions happen (e.g., hacking begun, explosion detected). For example, the documentation shows how to integrate fd_banking with ps‑dispatch.
• Visual customisation: Change the UI of the dispatch menu, adjust icons, colours, fonts, location of notifications on the screen, etc. Some servers even add map overlays or minimap filters so alerts are highlighted.
• Priority tiers and escalation: You can define priority levels (1, 2, 3) and based on priority escalate alerts: e.g., priority 1 = immediate response required, fires red; priority 3 = minor incident, fires yellow and maybe only to backup‑units.
• Logging and analytics: Consider logging each alert fired (with time, coords, job type) so you can analyse which alerts fire most often, which job responses are lacking, and tweak balance.
• Localization & culture fit: If your server is based in a certain region (e.g., Pakistan, UK, US), you might change the language, code‑names (10‑11, 10‑90, etc) and job names to fit that region’s policing culture.

Use cases: How server roles benefit

Here’s how different roles on your server gain from ps‑dispatch:

• Police / Law Enforcement: They get timely notifications, map blips, priority levels. They can respond to shootings, robberies, vehicle thefts. They feel active, engaged, instead of idle.
• EMS / Paramedics: They might only receive alerts when medical emergencies trigger (if you configure the system so). That means they aren’t spammed by every incident but only when their role matters.
• Server Administrators: They gain an organised structure for alerts; ability to monitor how many alerts happen, adjust scenario frequency, scale events up or down.
• Players / Civilians: They see responses from job roles, making role‑play more realistic “Hey the cops showed up fast because you triggered the alert”. That elevates immersion.

Example scenario: From trigger to response

Let’s walk through a full anecdotal scenario, step by step, so you can imagine how ps‑dispatch works in action.

1. A player enters a bank heist script and begins the robbery.
2. The robbery script triggers: exports[‘ps‑dispatch’]:CustomAlert({…}) with coords of bank, message “Bank Robbery In Progress”, dispatchCode “10‑90”, priority 1, jobs {“police”}.
3. ps‑dispatch receives the event. It looks up “10‑90” (or the codeName) in sv_dispatchcodes.lua, finds the entry for bankrobbery, gets the blipSprite, colour, recipientList etc.
4. On the police players’ screens: A notification pops up saying “Bank Robbery In Progress”, location details appear (street/zone), a map blip appears showing where the event is, maybe with a red flashing icon.
5. The police players respond, coordinate via voice/chat, drive to the location. The dispatch alert may stay on screen/map for the blipLength seconds.
6. When all is done (robbery ends, or police reach location/resolve), you might fire another alert like RobberyComplete() or simply let the event timeout.
7. Later, you check logs and see “Bank Robbery” triggered at 14:32, responded at 14:35, solved at 14:40. You decide: maybe the next time we reduce the blip length or increase priority to make it more urgent.

In this way the system loops naturally — the dispatch system integrates with gameplay, not just window‑dressing.

Troubleshooting: What to check when things go wrong

If you install ps‑dispatch and something isn’t working, here’s a checklist:

• Is the resource loaded? (Check server logs for startup errors)
• Are the dependencies (e.g., qb‑core, ox_lib) present and up‑to‑date?
• In server.cfg, is start ps‑dispatch (or ensure ps‐dispatch) included?
• In sv_dispatchcodes.lua, is the codeName you trigger defined exactly (quotes, case matter)?
• In the trigger, are you passing all required parameters (coords, message, jobs, dispatchCode etc)?
• Does your job type match your server’s job definitions? If the recipientList is {“police”} but your job is “cop”, it won’t match.
• Are there any errors in the client logs (F8 or console) when the alert triggers?
• Is the blip appearing but maybe off‑screen or map zoomed out (maybe radius large and blip tiny)?
• If messages aren’t in the correct language – check the locale settings, ensure the setr ox:locale command is set.
• Check that Config.Debug = true is set when testing; this will show extra information.

Best practices for server admins

Here are a few best practices to make ps‑dispatch work really well on your server:

• Use priority levels meaningfully: define what priority 1 means vs priority 3. Don’t treat all alerts the same.
• Use cool‑down or limit frequency: too many alerts too fast = alert fatigue, players stop reacting.
• Use differentiated blip/icons/sounds: let players instinctively recognise “this is high priority” vs “this is low priority”.
• Keep job lists accurate: define which jobs should receive each alert. For example, don’t send EMS alerts to police only, unless you explicitly want that.
• Regularly monitor logs: track which alerts are fired most often, which ones get ignored, adjust accordingly.
• Have clear documentation for players: offer a cheat‑sheet or UI overlay showing “Alert Codes: 10‑90 = Bank Robbery, 10‑11 = Speeding Vehicle”, so players know what each blip means.
• Use fallback/default alerts: For unknown or new scenarios, have a catch‑all alert so your script doesn’t fail silently.
• Encourage player feedback: ask your police and job players how they feel about alert load and realism; adjust for balance.

Common alert types and how to define them

Here are some typical alert types you’ll find (or can define) with ps‑dispatch — you can use these as templates:

• Shooting / Gunfire: dispatchCode “10‑47”, message “Shots fired”. Priority 1. Icon: bullet.
• Bank Robbery: dispatchCode “10‑90”, message “Bank robbery in progress”. Priority 1. Icon: bank.
• Car Theft / Vehicle Theft: dispatchCode “10‑77”, message “Vehicle theft reported”. Priority 2. Icon: car.
• Suspicious Activity: dispatchCode “10‑12”, message “Suspicious activity reported”. Priority 3. Icon: exclamation.
• EMS Down / Medical Emergency: dispatchCode “10‑45”, message “EMS needed at location”. Priority 1. Icon: medical cross.
• Hostage Situation: dispatchCode “10‑82”, message “Hostage situation”. Priority 1. Icon: skull or hostage silhouette.

When you define them in sv_dispatchcodes.lua, you assign sprite, colour, scale, blipLength, recipientList etc. For example:

["hostage_situation"] = {  displayCode = '10‑82',  description = "Hostage situation in progress",  radius = 0,  recipientList = {'police'},  blipSprite = 93,  blipColour = 1,  blipScale = 1.5,  blipLength = 30,  sound = "hostage_alarm",  sound2 = "GTAO_FM_Events_Soundset",  offset = false,  blipflash = true}

Then you trigger it when your hostage script kicks off:

exports['ps‑dispatch']:CustomAlert({  coords = vector3(x,y,z),  message = "Hostage situation in progress",  dispatchCode = "10‑82",  codeName = "hostage_situation",  priority = 1,  jobs = {"police"}})

Scaling and balancing your dispatch system

If your server grows, you might face issues of scale. Here are some points to handle:

• Alert volume: If tens of alerts fire every hour, job roles might be overwhelmed. Consider adding thresholds (e.g., only priority 1 fire for certain jobs) or cooldowns.
• Map clutter: Many blips can overcrowd the map, making it hard to see. Use blipLength wisely and possibly fade old blips.
• Job distribution: You might have multiple jobs (police, sheriffs, federal, etc). Decide which jobs share which alert‑types or maybe chain alerts (e.g., sheriffs handle rural, police handle urban).
• Performance: Large numbers of blips and sound events can impact client performance; test on low‑spec machines.
• Player training: Not all players will understand space‑map symbols or what alert codes mean; provide UI hints, training sessions, or on‑screen notifications.
• Data logging: Keep logs of alerts fired, response times, outcomes. Use this data to improve gameplay flow.

Summary: Why ps‑dispatch matters

In sum, ps‑dispatch brings structure and realism to your server’s event system. It turns simple script triggers into full‑fledged dispatch alerts, complete with map blips, job‑specific notifications, priority codes, and custom visuals. By following the steps above (download, install, configure, trigger), you can make your server feel more alive and responsive.

Because roleplay and multiplayer servers thrive on responsiveness and immersion, the dispatch system is a key part of that. Without it, alerts feel flat. With it, players on roles feel needed; civilians feel the world is reacting; admins get better control.

And if you customise it — define your own alerts, tailor icons and sounds, integrate the system with your unique scripts — it becomes more than functional: it becomes the heartbeat of your server’s emergent gameplay.

Final tips before you launch

• Test thoroughly in a development environment before going live.
• Have fallback mechanisms — if ps‑dispatch fails, maybe revert to a simple text alert rather than no alert.
• Communicate with your players: show them the new dispatch system, how it works, what each alert code means.
• Maintain the resource: monitor updates from Project Sloth, because new versions may fix bugs or add features.
• Keep an eye on performance and feedback for the first week after launch. Adjust radius, blip length, alert frequency accordingly.