DEV Community: FiveM MLOs

Optimizing MLO Streaming for 64+ Player FiveM Servers

FiveM MLOs — Fri, 09 Oct 2026 20:29:32 +0000

Most FiveM servers do not notice their map problems at 20 players. They notice them the first weekend the city fills up. Textures load late, people fall through floors in the hospital, the police station takes ten seconds to render, and someone in Discord posts "is the server lagging or is it just me?"

Usually it is not the server. It is the client trying to stream far more custom map data than it can hold, in the exact places where everyone gathers. This post is the process I use to keep custom interiors (MLOs) workable once a server goes past 64 slots. None of it needs special tools beyond what FiveM and a few community utilities already give you.

Why player count changes the problem

A custom interior is streamed to every client that gets near it. One player standing in an MLO only needs to load that MLO. Forty players spread across the city means the server is fine, but each client still has to load whatever is around it, plus everything every nearby player's vehicle, ped and clothing brings in.

The places that hurt most are predictable: the main hospital, the main police station, the central garage, the mechanic shop and whatever club or bar is popular this month. These are the spots where crowds, emergency vehicles, custom cars and custom interiors all overlap. A map that looks perfect in a solo test can be the one that tips a mid-range PC over its texture budget when twenty people are standing in front of it.

Remember that past 32 slots you are running OneSync, and with it larger culling and population behaviour. That is all good for scale, but it means more entities near the player at peak times, so the map has less headroom than it did on a small test server.

Step 1: Audit what you are actually streaming

Before optimizing anything, list it. Go through your resources folder and write down every map and MLO resource, what it replaces or adds, and where it is in the world. You are looking for three things:

Duplicates. Two versions of the same interior, often an old one left behind after an upgrade. Both stream, both collide, and both cost memory.
Overlaps. Two different maps that touch the same area. Overlapping collisions are the most common cause of "I fell through the floor" reports.
Dead weight. Interiors nobody uses. If no job, script or storyline points players to a building, it is paying a memory cost for nothing.

On most servers I have helped with, this audit alone removes several resources. That is the cheapest optimization you will ever do.

Step 2: Watch the warnings FiveM already gives you

FiveM's client console warns about oversized assets when they load. Run the server locally, fly around each custom interior, and keep the console open. Any map that repeatedly throws size warnings is a candidate for rework or replacement.

Also use the built-in resource monitor (resmon) while standing inside each interior. MLOs are mostly streamed data rather than scripts, so the monitor will not show the texture cost directly, but it will show you if a map ships with a bundled script (doors, elevators, lights) that is burning client time every frame. Bundled scripts that tick constantly with no player nearby are worth flagging to the creator.

For deeper problems, the client profiler (profiler record in the F8 console, then view the capture) shows frame spikes while you walk through a building. A spike every time you cross a doorway usually points at a portal or room setup issue, not the textures.

Step 3: Cut texture weight where nobody looks

Texture dictionaries are usually where the memory goes. A single interior can ship with very large textures for small things: a poster, a floor mat, a label on a box. At normal view distances, nobody can tell the difference between a huge texture and one a quarter of its size.

Practical rules:

Downscale small-surface textures. Signs, posters, decals, small props. These rarely need high resolutions.
Keep detail where players stand close. Reception desks, the main counter, the cells in a police station. Players stare at these during roleplay, so keep them sharp.
Check for duplicated textures across maps. Some creators each ship the same generic textures under different names. If you control the files, sharing one dictionary helps.
Respect the license. Only edit files if the asset's license allows it. If a map is escrowed, you cannot change it, so performance has to be a buying criterion instead (more on that below).

After any change, retest in the same spot. Texture work is easy to overdo, and a hospital that looks blurry is a roleplay problem of its own.

Step 4: Fix collisions and portals before players find them

Collision issues show up as people falling through floors, getting stuck in walls, or vehicles launching off a ramp that should not exist. With more players, these happen more often simply because more people walk more paths.

Things to check in every interior:

Walk every room, stair and doorway on foot. Then do it again in a vehicle where relevant (garages, ambulance bays, sally ports).
Open and close every door. Make sure doors locked by your door-lock script line up with the actual door models.
Look through windows and doorways from outside. If the inside pops in late or vanishes, the portals or room boundaries are wrong.
Check the transition between the MLO and the surrounding street. Seams are where overlapping maps usually fight.

If you find problems in a paid map, report them to the creator with coordinates and a short clip. Good creators fix these. If they do not, that tells you something for your next purchase.

Step 5: Spread the load across the city

This one is about design, not files. If every important building is in the same few blocks, every client near downtown is loading all of them at once.

Some servers deliberately spread key locations: hospital in one district, main PD in another, the busiest mechanic somewhere else. That is not always possible, and it has roleplay trade-offs (response times, travel), but it is worth thinking about when you choose which interiors to add. If you are deciding how many custom interiors a server of your size really needs, this breakdown of fivem server mlos by player count is a good starting point for planning before you buy.

Step 6: Test under real load, not on an empty server

Solo testing finds broken files. It does not find performance problems. For that you need people.

A simple load test:

Schedule a 30 to 60 minute session with as many staff and trusted players as you can get.
Pick the three busiest locations and have everyone gather there in turns, with emergency vehicles and custom cars.
Ask testers to note their PC specs and FiveM graphics settings (especially the texture budget settings), and to report anything that loads late or flickers.
Record the server's own metrics during the test so you can separate client-side streaming issues from server-side lag.

Keep a short spreadsheet: location, what went wrong, which testers saw it, and what spec they were running. Patterns appear quickly. If only low-VRAM players report the hospital, it is texture weight. If everyone sees it, it is more likely collision, portals or a conflict.

Step 7: Make performance part of buying

The easiest optimization is choosing well in the first place. Before you add an interior, ask the seller or check the listing for:

Whether the files are open or escrowed (can you optimize them later?).
Whether there are known conflicts with popular base maps.
Real in-game footage, ideally walking through the whole interior, not just one angle.
How updates are delivered when the game or FiveM changes.

Whatever store you use, whether that is a creator's own page, a marketplace or a specialist shop like fivemmlos.com, ask for that information before you pay. Five minutes of questions can save you a weekend of debugging.

A short checklist to keep

One version of each interior, no leftovers.
No overlapping maps in the same area.
Console clean of repeated size warnings near busy locations.
Bundled map scripts checked in resmon.
Small-surface textures reasonable, close-up surfaces sharp.
Every door, stair and vehicle entry walked by hand.
Key locations not all stacked in the same few blocks.
One real load test before every major map change.

Final thoughts

Big servers do not need fewer custom interiors. They need fewer wasted ones, and they need the ones they keep to be clean. Do the audit, watch the warnings, test with real people, and treat performance as a buying criterion rather than a problem you fix after launch. Your players will not notice that you did any of this, and that is the point.

If you have your own tricks for keeping a busy city smooth, I would like to hear them in the comments.

How to Vet a FiveM Shop Before You Install Anything: A Technical Checklist

FiveM MLOs — Fri, 09 Oct 2026 19:45:45 +0000

If you run a FiveM server, every resource you install runs with real access to your server. A script can read and write your database, trigger server events, and in some cases run code you never meant to allow. A map can break streaming for every player who drives past it. That makes the question of where you buy assets a technical one, not just a shopping one.

This post is the checklist I use before installing anything from a seller I have not used before. It is split into two parts: checking the shop, and checking the files.

Part 1: Checking the shop

Does it explain what it sells?

A legitimate seller tells you what each resource does, which framework it supports, and what it depends on. Vague listings like "best script, works on all servers" are a bad sign. Look for:

Framework and version (QBCore, Qbox, ESX, standalone).
Dependencies (ox_lib, oxmysql, a target system, a specific inventory).
Whether the code is open or escrowed.
Real in-game screenshots or video, not just mockups.

A specialist fivem mlo store or a general fivem script shop should make this information easy to find on every listing.

Is there a working support channel?

Find the support email, ticket system or Discord before you buy. Send a pre-sales question if you can. A fast, specific answer tells you more about the shop than any marketing copy.

Are the policies readable?

Check the terms, refund policy and license. In particular:

How many servers can you use the asset on?
Is a test server allowed alongside the live one?
What happens if the asset does not work as described?

Does the pricing make sense?

If a shop sells hundreds of well-known paid scripts or MLOs for the price of one, it is almost certainly selling leaked copies. Leaked resources are one of the most common ways backdoors end up on servers. They are also usually old versions with no updates.

Is there install documentation?

Good sellers publish install guides. A clear installation page that explains where files go and what to add to your config is a sign the seller expects to support you after the sale.

Part 2: Checking the files

Even from a shop you trust, never drop a new resource straight into your live server. Inspect it first, then test it on staging.

Look at the folder structure

A FiveM resource is a folder with a manifest file and code or stream assets. A typical script looks something like this:

my_resource/
  fxmanifest.lua
  config.lua
  client/
    main.lua
  server/
    main.lua
  locales/
    en.lua

A typical MLO looks more like this:

my_interior/
  fxmanifest.lua
  stream/
    *.ymap
    *.ytyp
    *.ybn
    *.ydr
    *.ytd

Red flags at this stage:

Executable files (.exe, .bat, .dll) inside the resource. A FiveM resource does not need them.
An installer that asks to run on your machine or server.
A map resource that contains server-side Lua for no obvious reason.

Read the manifest

Open fxmanifest.lua. It tells you what the resource loads. Check:

Which client and server scripts it runs.
Whether it loads files from unexpected places.
Whether it declares dependencies that match the listing.

If an MLO's manifest loads server scripts, find out why before installing it.

Search for suspicious patterns

For open source scripts, a quick search across the folder catches many common problems. These are not always malicious, but each one deserves a closer look:

# remote code loading or HTTP calls you did not expect
grep -rn "PerformHttpRequest" .
grep -rn "load(" .
grep -rn "loadstring" .

# heavily obfuscated strings
grep -rnE "\\\\x[0-9a-fA-F]{2}" .

# shell or OS access
grep -rn "os.execute" .
grep -rn "io.popen" .

A legitimate script may use PerformHttpRequest for Discord logs or a license check. That is fine if it is documented. An undocumented request to an unknown domain, especially combined with load() on the response, is a classic backdoor pattern.

Escrowed scripts cannot be inspected this way, which is why buying escrowed code only from sellers with a clear track record matters.

Check server event handlers

Many money and item exploits come from server events that trust the client. Search for RegisterNetEvent and AddEventHandler in the server files, then read what each handler does:

Does it check that the player is allowed to do this?
Does it validate amounts and item names on the server?
Does it accept a price or reward value sent from the client?

If a server event gives money or items based on numbers sent by the client, it can be abused by anyone with a mod menu.

Check database changes

Look for SQL files and any CREATE TABLE or ALTER TABLE statements. Make sure they match your framework's schema and will not overwrite existing tables. Back up your database before running anything.

Part 3: Testing on staging

Inspection catches obvious issues. Testing catches the rest.

Use a staging server with the same framework, resources and database layout as live.
Install one resource at a time. If something breaks, you know what caused it.
Watch the server console on start for errors and warnings.
Use the resource monitor to see how much time the resource takes on server and client, at idle and in use.
For MLOs, walk and drive around the interior. Look for clipping, missing textures and areas you can fall through. Ask someone on a lower-end PC to test too.
Test with a few players, especially for anything that touches money, inventory or jobs.

For interiors in particular, a dedicated MLO buyer's checklist covers the layout, conflict and performance checks in more detail.

Part 4: Keeping access limited

Even trusted resources should only have the permissions they need.

Do not give resources broad ACE permissions unless they genuinely require them.
Keep your server's console, database and txAdmin credentials separate and strong.
Restrict who on your staff team can add new resources to live.
Keep a log of what was installed, when and by whom.

What to do when a seller fails a check

Not every failed check means the seller is dishonest. Sometimes documentation is just thin, or a dependency was left off the listing by mistake. Contact the seller, describe exactly what you found, and ask for an explanation. A legitimate developer will usually clarify why a resource makes an HTTP call or loads a file, or will send a fixed version.

If the answer is vague, or you get no answer at all, do not install the resource on live. Remove it from staging, note what you found, and move on. Keeping a short internal list of sellers you trust, and sellers you will not use again, saves your team from repeating the same investigation next time.

A quick checklist

Shop

Clear listings with framework, dependencies and escrow status
Working support channel
Readable terms, refunds and license
Pricing that makes sense
Install documentation

Files

Clean folder structure, no executables
Manifest matches the listing
No undocumented HTTP calls or dynamic code loading
Server events validate on the server
SQL reviewed and database backed up

Testing

Staging server, one resource at a time
Console clean on start
Resource monitor checked
Interiors walked, driven and tested on low-end hardware
Small player test before live

None of this takes long once it becomes a habit, and it is far cheaper than recovering a compromised server or rebuilding a broken economy. Vet the shop, inspect the files, test on staging, and only then let a new resource near your players.

Toggling MLO Entity Sets in FiveM and Keeping Them in Sync for Every Player

FiveM MLOs — Fri, 09 Oct 2026 19:23:04 +0000

Many custom interiors ship with optional variations: a lab that can be upgraded, a club with an event stage, a garage with extra lifts, a house that can be empty or furnished. In MLO terms these are entity sets, named groups of props inside the interior that code can enable or disable at runtime. This post explains how they work, how to find their names, how to toggle them with a few natives and, most importantly, how to make sure every player sees the same version of the room.

What an entity set actually is

An MLO's interior definition lives in its .ytyp file. Alongside the rooms and portals, that definition can contain a list of entity sets. Each set has a name and a list of entities (props) that belong to it. When a set is active, those props are drawn as part of the interior; when it's inactive, they are not.

Two things follow from that:

You can only toggle sets the creator actually defined. You can't turn an arbitrary prop into a set from a script.
The set names are fixed strings chosen by the creator, such as upgrade_lvl1 or stage_props.

Finding the set names

The easiest way is the documentation. Good creators list their entity set names in a readme or on the product page, often with a screenshot of each variant.

If there is no list, you can look inside the ytyp. Tools that open GTA V resource files can export a ytyp to XML, where the interior's archetype contains an entitySets block. Each item in that block has a name field: those are the strings your script needs. Only do this with files you have the right to use, and don't redistribute anything you extract.

Toggling a set from the client

Entity set state is applied on the client. The basic flow is: find the interior ID, change the set, then refresh the interior so the change is drawn.

-- client.lua
local function setEntitySet(coords, setName, enabled)
    local interiorId = GetInteriorAtCoords(coords.x, coords.y, coords.z)
    if interiorId == 0 then
        return false -- no interior at these coords (or not loaded yet)
    end

    if enabled then
        ActivateInteriorEntitySet(interiorId, setName)
    else
        DeactivateInteriorEntitySet(interiorId, setName)
    end

    RefreshInterior(interiorId)
    return true
end

GetInteriorAtCoords returns 0 when there is no interior at that position, so check for it. Use coordinates that are clearly inside the interior, such as the middle of the main room, rather than the doorway, where you may hit the exterior instead.

You can check the current state with IsInteriorEntitySetActive(interiorId, setName), which is handy for debugging.

Describe your interiors in a config

Hard-coding coordinates and set names in logic gets messy as soon as you have more than one interior. Put them in a shared config instead:

-- shared/config.lua
Config = {}

Config.Interiors = {
    lab = {
        coords = vector3(1088.6, -3187.4, -38.9),
        sets = { 'upgrade_basic', 'upgrade_full' },
    },
    club = {
        coords = vector3(-1592.3, -3012.0, -76.0),
        sets = { 'stage_props', 'vip_area' },
    },
}

The coordinates above are placeholders; use a point inside your own interior. Keeping a list of valid set names per interior also lets you reject typos before calling the natives.

The sync problem

Here is the catch. Because entity sets are toggled on the client, running setEntitySet on one player's machine changes the room only for that player. Everyone else still sees the old version. For a lab upgrade or a club event, that breaks immersion immediately: one player sees a stage, their friend sees an empty floor.

The state needs one owner, and that owner should be the server. A clean way to do that without extra libraries is a global state bag. The server writes the desired state; every client reads it and applies it, including players who join later.

Server: owning the state

-- server.lua
local function setInteriorState(name, activeSet)
    local interior = Config.Interiors[name]
    if not interior then return false end

    local valid = false
    for _, s in ipairs(interior.sets) do
        if s == activeSet then valid = true break end
    end
    if activeSet ~= nil and not valid then return false end

    GlobalState['mlo:' .. name] = activeSet -- nil means "no optional set"
    return true
end

RegisterCommand('setinterior', function(source, args)
    local ok = setInteriorState(args[1], args[2])
    print(('[interiors] %s -> %s (%s)'):format(args[1], tostring(args[2]), ok and 'ok' or 'rejected'))
end, true) -- restricted: needs the matching ACE permission

Passing true as the third argument to RegisterCommand makes it restricted, so only players or consoles with the ACE permission command.setinterior can run it. In a real script you would call setInteriorState from your job logic, for example when a lab upgrade is paid for, after checking the player's job server-side.

Client: applying the state

-- client.lua
local function applyInterior(name, activeSet)
    local interior = Config.Interiors[name]
    if not interior then return end

    local interiorId = GetInteriorAtCoords(interior.coords.x, interior.coords.y, interior.coords.z)
    if interiorId == 0 then return end

    for _, s in ipairs(interior.sets) do
        if s == activeSet then
            ActivateInteriorEntitySet(interiorId, s)
        else
            DeactivateInteriorEntitySet(interiorId, s)
        end
    end
    RefreshInterior(interiorId)
end

-- react to changes made while we're online
AddStateBagChangeHandler(nil, 'global', function(_, key, value)
    local name = key:match('^mlo:(.+)$')
    if name then applyInterior(name, value) end
end)

-- apply the current state on join / resource start
CreateThread(function()
    for name in pairs(Config.Interiors) do
        applyInterior(name, GlobalState['mlo:' .. name])
    end
end)

The change handler is registered with a nil key filter and the bag name 'global', then filters keys by prefix itself. The startup thread covers players who join after the state was set.

Re-apply when the interior loads

An interior that is far away may not be loaded yet when the startup thread runs, in which case GetInteriorAtCoords returns 0 and nothing happens. A simple fix is to re-apply the state when the player gets near:

CreateThread(function()
    while true do
        local pos = GetEntityCoords(PlayerPedId())
        for name, interior in pairs(Config.Interiors) do
            if #(pos - interior.coords) < 80.0 then
                applyInterior(name, GlobalState['mlo:' .. name])
            end
        end
        Wait(5000)
    end
end)

A five-second loop with a distance check is cheap. If you already have a zone or polyzone system, trigger applyInterior on entering the zone instead.

Practical tips

Test each set alone first. Toggle every set with the simple client function before wiring up sync, so you know the names are right.
Watch for overlapping sets. Some creators design sets as exclusive (only one at a time); others expect several active together. The example above treats them as exclusive; adjust it if yours stack.
Check performance. Large sets add props to the room. Look at the resource monitor and frame times with the heaviest set active.
Read the install notes. Some interiors need a particular resource start order or a separate map file for their sets to appear. The general steps are at fivemmlos.com/how-to-install-fivem-mlo/.

Wrapping up

Entity sets let one interior do the work of several, but only if every player sees the same version. Keep the state on the server, apply it on every client and re-apply when the interior loads. When you shop for fivem server mlos that you plan to script against, look for listings that name their entity sets clearly; it saves a lot of digging later.

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.