What Is an MLO in FiveM? (And How to Install One Without Breaking Your Server)

The clean way to think about it: the .ytyp is the blueprint, the .ymap is the address. That distinction explains most MLO problems. If the blueprint is not registered, the address points at nothing.

MLOs are built and edited with CodeWalker, which is the reference tool for GTA V map modding and the thing you will use if you ever go beyond installing other people's work.

Two parts of that archetype are worth knowing by name, because they come up constantly when something looks wrong:

• Portals are the openings — doorways, windows — that connect rooms and control what the game renders from one room into the next. When you can see through a wall in an MLO, or the world outside vanishes when you step into a room, a portal is misconfigured. It is the most common visual defect in a badly built interior, and it is not something you can fix from server.cfg.
• Entity sets are optional groups of props inside the interior that can be toggled on and off — furnished versus unfurnished, shutters open versus closed, a raid-damaged variant. A good MLO exposes them, and a script can switch them at runtime. If an MLO you bought looks empty, it very often is not broken: its entity sets simply are not enabled.

Installing one, properly

An MLO is a normal FiveM resource. The whole job is the fxmanifest.lua, and there are exactly three things it must do.

fx_version 'cerulean'
game 'gta5'

this_is_a_map 'yes'

files {
    'stream/**/*'
}

data_file 'DLC_ITYP_REQUEST' 'stream/my_interior.ytyp'

Line by line, because each one does something specific:

• this_is_a_map 'yes' — marks the resource as a GTA map and reloads map storage when it loads. Without it, the game does not treat your files as map data.
• The files block — makes the assets available. (Assets in a stream/ folder are normally streamed automatically; the explicit files block is what makes the .ytyp reachable for the next line.)
• data_file 'DLC_ITYP_REQUEST' — this is the line people miss. It registers the interior's archetype with the game's extra-content system. Miss it and the .ymap places an instance of an archetype the game has never heard of, and you get an invisible or non-functional interior — the single most common "I installed an MLO and nothing happened".

Then, in server.cfg:

ensure my_interior

One correction worth making loudly: many guides tell you to use data_file 'MAP_TYPES'. MAP_TYPES is not a valid data_file type. It is not in Cfx's data-file reference. The interior-related types that do exist are DLC_ITYP_REQUEST, PERMANENT_ITYP_FILE and INTERIOR_PROXY_ORDER_FILE. If you copied a manifest from a tutorial and your MLO does not load, check this line first.

A useful thing to know while debugging: FiveM supports raw XML .ymap and .ytyp files — you can ship the uncompiled XML as long as the file is named with the plain .ymap / .ytyp extension. It is parsed by the game's own parser, so it can behave slightly differently from CodeWalker's, but it is genuinely supported and makes inspection much easier.

The limit that actually breaks servers

Here is the real reason "too many MLOs" destabilises a server, and it is not vague.

Every MLO instance consumes an interior proxy, and that pool is finite. FXServer exposes it:

increase_pool_size "InteriorProxy" 400

The documented maximum increase is 450. That is a hard ceiling, not a suggestion. Servers that stack MLO packs indefinitely eventually run into pool exhaustion, and the symptoms are ugly and confusing — interiors that will not load, crashes near certain buildings, players falling through the world.

So the pool size is a lever, and it is a lever with an end. If you are adding your fortieth MLO pack, the answer is not to keep raising numbers. It is to remove the MLOs nobody uses.

Two MLOs in the same place

Do not do it.

If two MLOs occupy the same interior location, they conflict. The reported symptoms are consistent and unpleasant: you cannot enter the interior, players are invisible inside it, or the game crashes near it.

Being honest about the limits of what is known here: Cfx.re does not document what happens when two MLOs overlap, and the community explanations of the mechanism are anecdotal. I am not going to invent one for you. What is reliable is the practical rule: before you install an MLO, find out whether it replaces a vanilla interior, and whether anything else you have already installed replaces the same one. MLO packs frequently include a replacement for the same popular locations — the police station is the classic — and installing two of them is a self-inflicted wound.

A safe install checklist

1. Test on a development server. Never install an MLO on a live server first. This is not a formality — a bad MLO can crash clients on connect.
2. Check what it replaces. If it overwrites a vanilla interior, make sure nothing else you run already does.
3. Read the manifest before you ensure it. Confirm this_is_a_map, the files block, and the DLC_ITYP_REQUEST line. If it says MAP_TYPES, fix it.
4. Add one at a time, and restart between each. When five MLOs go in at once and the server starts crashing, you have five suspects.
5. Watch the Streaming column in resmon. MLOs cost streaming memory, not script time — a heavy interior will not show up as CPU ms at all, which is why people miss it. Our performance guide covers how to read that properly.
6. Walk it before you ship it. Enter every room, check collision, check the portals render correctly from outside, check the lighting. A broken portal is invisible until a player finds it.

An MLO is one of the highest-impact things you can add to a roleplay server — a real, unique location changes how people play far more than another script does. It is also one of the easiest things to install wrong in a way that only shows up later. You can find map and interior resources, with community reviews, on the FiveM scripts marketplace.

Researched and drafted with AI assistance. How ViceHub guides are made