Your MLO Doesn’t Care About ESX or QBCore — Your Jobs Do

“Does this MLO work with QBCore?” is the wrong question – and the one every US RP Discord still asks. A FiveM MLO is a map resource. It streams the same way on ESX, QBCore, QBox, and standalone stacks. What does care about your framework is everything that points into the building: ambulance beds, police lockers, mechanic lifts, housing entrances, doorlocks, and target zones.

This playbook is the after-install config pass sellers rarely write down. Use it when the interior looks perfect but duty markers still sit in the old vanilla lobby. Pair it with How to Install a FiveM MLO for the map layer, and the FiveM MLO buyer’s checklist before you pay for the next shell.

Map layer vs framework layer (clear diagram in prose)

Think of your city as two stacked systems:

+———————————————+

| FRAMEWORK LAYER (jobs / doors / targets) |

| ESX / QBCore / QBox / custom stacks |

| Coords / door hashes / zones / inventories |

+——————^————————–+

| points at rooms & props

+——————+————————–+

| MAP LAYER (the MLO) |

| fxmanifest + stream/ (ymap, ytyp, ybn…) |

| Framework-agnostic – same on every stack |

+———————————————+

  • Map layer = geometry, collisions, portals, and props. Install once; ensure the resource; verify you are not double-loading a vanilla shell.
  • Framework layer = behavior. Job scripts read config tables of vector3s, box zones, and door hashes. Those numbers are not magically updated when you drop a new interior.

If you only change the map, players walk into a beautiful hospital while EMS still respawns at the old Pillbox elevators. That is not an ESX vs QBCore incompatibility. It is unfinished pairing.

Operator rule: Prove the MLO alone on a staging server (no job rewrites yet). Only after the shell is clean do you open framework configs. If you still need a QBCore staging server, see how to install a QBCore server with txAdmin.

After install: coords, duty zones, cloakrooms, garages

Every framework job follows the same checklist. Names differ (Config.Locations vs shared/locations.lua); the work does not.

  1. Entrance / interact point – Front door or reception where players clock in, open menus, or see blips.
  2. Duty / off-duty – Toggle zones so staff do not go on duty in the street.
  3. Cloakroom / lockers – Outfit and stash points; often several per department.
  4. Boss / management – Office desks for boss menus and society accounts.
  5. Garage / vehicle spawn – Air, ground, or boat spawns tied to the new bay or lot.
  6. Special props – Beds, evidence lockers, lifts, crafting benches, stash props your scripts expect.
  7. Doorlocks – Cells, evidence, OR, bay doors, and armories need fresh door hashes or lock IDs from the new shell.
  8. Blips – Map icons that still point at vanilla Mission Row or Pillbox confuse new players.

Where to get numbers: Prefer the seller’s product docs (entrance + key interior coords). If docs only list an entrance, walk the interior in a test client with a coord printer or your admin menu and record the rest yourself. Do not invent room counts or “exact” vectors from marketing copy – measure on your installed pack.

Order of operations:

  1. Install and stage the MLO (install guide).
  2. Fix IPL / remove conflicts if it is a replacement shell.
  3. Update framework configs.
  4. Retest the full job loop with a non-admin character.

EMS + Pillbox / hospital examples

Medical RP fails loudly when scripts and maps disagree. After you place a hospital or Pillbox-class rebuild from our hospital MLO category, expect to touch:

Script concern What to update Why it breaks if you skip it
Ambulance garage / helipad Vehicle spawn + return coords Units spawn inside walls or on the old roof
Check-in / reception Duty + public interact points Civilians menu at empty sidewalk markers
Treatment / beds Bed props or revive zones EMS “puts” patients in mid-air or old wards
Surgery / trauma Restricted zones + doorlocks Public access to OR; doors still hash to vanilla
Lockers / stash Cloakroom + inventory stash coords Uniforms and med bags open in the old basement
Boss / pharmacy Management desks Society menus float in void rooms

Pillbox replacements are the classic US city case: the map may include remove instructions for vanilla IPLs, while esx_ambulancejob, qb-ambulancejob, or QBox medical resources still ship default Pillbox vectors. Update both layers. For buyer context on Pillbox-style footprints, see our Pillbox Hospital MLO guide, then wire jobs only after the shell stands alone.

Practical tip: Run one full call – dispatch -> garage -> triage -> bed -> checkout – on staging. If any step snaps you to the old building, you still have a leftover coord.

PD + MRPD / cells / evidence

Police scripts are coord-heavy. A Mission Row or custom station from the PD MLO category usually needs a wider pass than “move the blip.”

Typical update list for ESX police, qb-policejob, QBox LEO resources, and jail add-ons:

  • Public lobby / front desk – Report crime, non-duty interact, visitor pathing
  • Duty / cloakroom / armory – Often three separate points; do not collapse them into one lobby marker
  • Briefing room – Meeting / MDT / boss brief coords if your pack uses them
  • Booking -> cells – Handcuff / jail / unjail vectors and doorlock hashes for every cell door
  • Evidence / locker storage – Stash props and evidence lockers your inventory script expects
  • Garage / impound handoff – Patrol vehicle spawns and sometimes tow/impound links
  • Helipad (if present) – Air unit spawn separate from ground garage

MRPD replacements fail in two common ways: (1) dual interiors from incomplete removes, and (2) perfect map with jail scripts still teleporting into Rockstar’s old cell block. Fix conflicts first; then rehash doors. Mission Row buyers can start from the Mission Row PD MLO lander for footprint context, then treat every cell door as a lock config task – not a map bug.

Evidence rooms: If your evidence script binds to a specific prop model or stash ID, confirm that prop exists in the new MLO. A pretty evidence room without the expected prop still needs a config or prop swap – measure before blaming the map.

Mechanic job + bay / target zones

Mechanic loops are prop-driven. After installing from mechanic shop MLOs, align the job with the bay layout you actually bought:

  • Clock-in / boss desk – Front counter or office, not mid-bay
  • Customer intake – Where civilians open the repair menu or drop keys
  • Work bays – Zones large enough for the vehicle + player; too-tight boxes fail on lifted cars
  • Lifts / ramps – If your script animates or targets a lift prop, match the model or disable that feature
  • Parts / crafting / stash – Storage rooms and crafting benches
  • Garage / delivery spawn – Flatbed or loaner vehicle points outside the shell
  • Bay doors – Doorlocks or garage-door scripts if the MLO includes closable doors

Tuner and Mirror Park-style shops often look “done” in screenshots while qb-mechanicjob, ESX mechanic resources, or crafting scripts still target the old Benny’s-adjacent coords. Walk each bay with the vehicle you care about (SUV vs sports) so zones are not car-sized for the wrong class.

Housing systems (ps-housing, qb-houses, esx_property – high-level)

Housing is still framework pairing – even when the shell is a mansion or apartment MLO from houses & mansions.

High-level only (resource names evolve; always read your housing docs):

Stack (examples) What you typically re-point Watch-outs
QB-style (qb-houses, ps-housing, and similar) Entrance / exit, interior shell ID or poly, stash/wardrobe/logout coords, doorlocks Shell name or interior ID must match what the housing resource expects; wrong ID = empty void or wrong apartment
ESX-style (esx_property and forks) Property enter coords, interior type, chest/wardrobe markers, keys Older ESX property packs assume IPL interiors – MLO shells may need a modern housing resource or custom entry
QBox / ox-era stacks Same idea: enter poly + furniture/stash targets via ox_inventory / ox_doorlock Prefer one doorlock system citywide; mixing qb-doorlock and ox_doorlock on the same shell causes “door works for staff, not owners” tickets

Operator rules for housing MLOs:

  • Confirm whether the product is a shell for housing scripts or a static visit-only interior.
  • Do not assume every mansion MLO ships as a drop-in ps-housing shell – check the listing.
  • Furniture and stash props are script concerns; the map only provides the rooms.
  • Test enter -> stash -> wardrobe -> logout -> re-enter before selling the property in-city.

We do not invent compatibility matrices or player-count claims here. If a listing does not document housing hooks, treat it as a map and plan script work – or ask support before checkout.

Target systems: ox_target vs qb-target (doors / props if bundled)

Third-eye / target resources are framework-adjacent, not part of the MLO zip (unless a seller bundles optional extras – and most map packs do not).

System Common on Pairing note
ox_target QBox, many ESX/QB “ox” stacks Zones and entity targets in Lua; often paired with ox_doorlock + ox_inventory
qb-target Classic QBCore cities Box/sphere zones and bone targets; migrating cities often run both briefly – pick one for new interiors
qtarget / others Legacy or mixed Same job: re-create zones at new desks, beds, lifts, and lockers

What to retarget after an MLO install:

  • Duty computers and boss desks
  • Stash lockers and evidence props
  • Hospital beds and stretchers
  • Mechanic lifts and craft benches
  • Doors that use target-based locks instead of auto doorlock scans

Doors: If the MLO docs list door hashes or object models, feed those into your doorlock resource. If they do not, use your locker’s door debugger in-game – do not guess hashes from another creator’s MRPD. Bundled “doors configs” in a map download are helpers, not a reason to skip testing on your lock script version.

Props: Targets bound to a specific prop model fail when the new interior uses a different desk or locker. Either retarget the new entity or swap in the prop your script expects (license permitting). Escrowed maps may block prop edits – plan on retargeting instead of rewriting the mesh.

Need the interior first – then wire the jobs

Framework scripts cannot roleplay in a building you have not installed. Buy the map that matches the department loop, stage it clean, then spend an evening on coords. That order saves tickets.

Shop the place; keep your stack:

Before you buy: run the buyer’s checklist (rooms, IPL, docs, coords). After you buy: install with the step-by-step MLO guide, confirm no double interiors, then apply this pairing playbook.

FiveM MLOs is built for US English RP operators who want licensed downloads and clear product pages – not “works on everything” hand-waving. The map is framework-agnostic. Your jobs are not. Wire them on purpose.

FAQ

Do I need a different MLO for ESX vs QBCore vs QBox? No. The MLO is a map resource and streams the same on all three. You may need different job resources or config files that point at the new coordinates and door hashes.

The interior looks fine but markers are in the wrong place. Is the MLO broken? Usually not. That pattern means the framework layer still uses old vectors. Update duty, cloakroom, garage, bed, and target coords after the map passes a solo staging test.

Should I change jobs before or after fixing IPL clipping? After. If two lobbies are loading, any coords you copy from “the new desk” may be unreliable. Clean the map layer first, then measure.

Does the MLO include ox_target or qb-target zones? Most map packs do not. Expect to create or move zones yourself unless the listing explicitly ships optional target configs for your stack.

What about housing – will any mansion work with ps-housing or esx_property? Not automatically. Confirm whether the product is documented as a housing shell or a static interior, then match entrance, stash, and doorlock setup to your housing resource’s requirements.

Where do I get accurate coordinates? From the seller’s docs when provided, or by measuring in-game on a staging server after install. Do not copy another server’s vectors for a different SKU.

Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart