DEV Community: FiveM MLOs

How to Set Up a Bar or Nightclub Job on a FiveM Roleplay Server

FiveM MLOs — Wed, 07 Oct 2026 22:34:04 +0000

A bar or nightclub is one of the few places on a FiveM roleplay server where police, gangs, medics and ordinary civilians end up in the same room on purpose. Done well, it becomes the social centre of the city. This post covers the planning side of a bar job: the interior, the job setup, how drinks get stocked and sold, events and staff roles. It stays framework-agnostic, so the ideas apply whether you run QBCore, ESX or something else.

Start with the venue, not the script

The building decides how the job plays, so pick it before you pick any job resource. Walk through the interior on a test server and look for these zones:

A bar counter long enough for two people to serve at once, with space for a register marker.
A storage room or back area where a stash or fridge marker can sit away from customers.
A manager's office for the boss menu, money handling and private conversations.
A floor or seating area big enough for a crowd during events.
A DJ booth or small stage, if you want live events.
A controlled entrance, so security staff have a door to stand at.

A small tavern with a counter, booths and a back room suits a neighbourhood bar; a nightclub needs a bigger floor and a separate VIP area. Browsing a few FiveM bar MLOs side by side is a quick way to compare counter length and floor space before you commit.

Make it a whitelisted job

Bars work best as a whitelisted job with an owner who hires staff, rather than a job anyone can pick at city hall. An owner keeps opening hours consistent and handles staff who stop showing up.

Every framework stores jobs a little differently. On ESX, jobs and their grades live in the jobs and job_grades database tables, and the jobs table has a whitelisted flag. On QBCore, jobs are defined in the core's shared jobs file, and whether a job shows up as a public option depends on your city hall config. A QBCore-style entry looks roughly like this (check the exact format against the version you run):

['nightclub'] = {
    label = 'Nightclub',
    defaultDuty = false,
    offDutyPay = false,
    grades = {
        ['0'] = { name = 'Barback', payment = 40 },
        ['1'] = { name = 'Bartender', payment = 60 },
        ['2'] = { name = 'Security', payment = 60 },
        ['3'] = { name = 'Manager', payment = 90 },
        ['4'] = { name = 'Owner', isboss = true, payment = 120 },
    },
},

Keep offDutyPay off so staff only earn while clocked in, and keep the hourly pay modest. The real income should come from serving players, not from standing behind the counter idle.

Design the stock and selling flow

The loop that keeps a bar alive is simple: staff buy or make stock, serve it to players, and the business keeps the profit. A few decisions shape how that feels.

Where stock comes from. The simplest version is a supplier marker where staff buy bottles with business funds. A richer version has staff mix drinks from ingredients at a crafting station, which gives them something to do between customers.

How players pay. Payment that goes through a register or billing menu works better than cash handed over in a corner. It keeps money in the business account and gives the owner a record of sales.

Server-side checks. Whatever script you use, the server should confirm that the person selling is clocked in, standing near the counter and actually has the item. Never let the client decide the price or the payout.

What drinks do. A short visual effect for alcohol is fun; ten minutes of heavy screen blur is not.

Plan events, not just opening hours

A bar with no reason to visit stays empty. Events give players a time and a reason to show up:

A weekly club night with a staff DJ.
Live music or open mic nights.
Private bookings for gangs, businesses or birthday parties.
Charity nights run with another business.

Post a schedule in your server's announcements or in-game news. Regular, predictable events build a crowd better than random openings.

Define clear staff roles

Clear roles stop five people crowding the counter while nobody watches the door:

Owner: hires and fires, sets prices, manages the business account and plans events.
Manager: runs shifts when the owner is offline and handles complaints.
Bartenders: serve drinks, take payments and restock the counter.
Security: manages the door, the guest list and removing troublemakers, without turning every shift into a fight.
DJ or performer: runs the music and the event itself.

Write these down in a short handbook the owner can share with new staff.

Check the technical basics

Nightclubs often have more lights, props and moving parts than other interiors, so test the building with several players inside. Watch the client console for asset warnings, check that walls and floors have collision, and make sure doors work with your door lock resource. If the interior replaces a default building or sits on top of another map edit, sort out the conflict before launch. The step-by-step install guide covers the manifest and server.cfg side if you haven't added an interior before.

Final thoughts

A good bar job comes down to four things: a venue with the right zones, a whitelisted owner with clear staff roles, a stock loop that rewards actually serving players, and regular events. Get those right and you can swap scripts later without losing what makes the place work. If you are still choosing a building, FiveM MLOs sorts its interiors into categories, so you can plan a bar alongside the rest of your city.

What has worked for keeping bars busy on your server? Share it in the comments.

Why Your FiveM MLO Causes Texture Loss (and How to Check Before You Install It)

FiveM MLOs — Wed, 07 Oct 2026 20:30:45 +0000

If you run a FiveM roleplay server, sooner or later a player reports that the city "goes blurry" or that textures pop in around a certain building. In my experience the cause is often an MLO (a custom interior) that was built without much thought for streaming memory. This post walks through what to check in an MLO resource before you put it on a live server.

1. Know what is inside the resource

A typical MLO resource looks like this:

my_mlo/
├── fxmanifest.lua
└── stream/
    ├── my_mlo.ytyp   -- archetype definitions, including the MLO interior
    ├── my_mlo.ymap   -- where the interior is placed in the world
    ├── my_mlo.ybn    -- collision
    ├── my_mlo.ydr    -- models
    └── my_mlo.ytd    -- textures

And a minimal manifest:

fx_version 'cerulean'
game 'gta5'

this_is_a_map 'yes'

data_file 'DLC_ITYP_REQUEST' 'stream/my_mlo.ytyp'

If the .ytyp is not registered with DLC_ITYP_REQUEST, the interior can fail to load properly or show up without its rooms and portals. That is the first thing to check when an interior looks "empty" or you can see through walls.

2. Check texture dictionary sizes

The biggest performance issue I see is oversized .ytd files. One 4096x4096 texture on a small prop adds up fast when a building has hundreds of them. The FiveM client warns in the console about oversized assets (roughly above 16 MB of physical memory), and those warnings are worth taking seriously.

Quick checks:

Open the .ytd in OpenIV or CodeWalker and look at texture resolutions. Floors and walls rarely need more than 1024 or 2048.
Make sure textures are compressed (DXT1/DXT5 or BC7), not uncompressed A8R8G8B8.
Look for duplicate textures shared across several .ytd files.

3. Rooms, portals and occlusion

A proper MLO is split into rooms connected by portals. The game uses portals to decide what to render, so a well-built interior only draws the room you are in plus what you can see through doorways. A badly built one is a single giant room, which means everything gets drawn all the time.

In CodeWalker, select the MLO and check:

Is the interior split into several rooms, or is it one big room?
Do the portals line up with real doorways and windows?
Are entity sets used for optional props instead of everything being always on?

4. LOD distances and the exterior

Exterior shells with huge LOD distances get streamed from far away. For an interior that sits in a dense area such as Mission Row or Pillbox, that adds load on every client driving past. Check the lodDist values in the .ymap and keep them reasonable for the size of the building.

5. Test it on a clean server first

Before an MLO goes live, I test it on a local server with only the base resources:

Start the resource and watch the client console for "oversized asset" warnings.
Walk through every room and check for missing collision (falling through floors) and see-through walls.
Use resmon while standing inside to make sure nothing script-side is spiking.
Drive around the exterior at speed to see if textures pop in.

If you want a full step-by-step on the install side, there is a guide on how to install a FiveM MLO that covers the manifest and server.cfg part in more detail.

6. What to ask a seller before you buy

If you are buying an interior rather than building one, ask the seller:

Total streamed size of the resource and the largest .ytd.
Whether it is split into rooms with portals.
Whether it conflicts with any default interiors or popular map packs.
Whether you get updates when game builds change.

Business interiors like garages get used constantly on RP servers, so for something like a FiveM mechanic MLO it is worth being picky about performance. Stores such as FiveM MLOs list interiors by category, which makes it easier to compare options before you commit.

Wrapping up

Most "my server lags in this area" complaints come down to a few things: oversized textures, missing room and portal setup, and long LOD distances. Spending 15 minutes checking an MLO in CodeWalker before it goes live saves a lot of player complaints later.

If you have other checks you run on interiors, drop them in the comments.