Choosing Between Housing Scripts, Shells, and Fixed MLOs

Housing is a persistence and routing decision disguised as a decorating feature. Fixed MLOs place unique interiors in the world. Shells reuse interior models at controlled coordinates or routing buckets. Housing scripts may support one or both while owning keys, furniture, storage, mortgages, and visits. The right combination depends on concurrency, customization, map identity, and how much state your team can maintain.

Fixed FiveM house interior used to compare unique MLO housing with reusable shells

Use the image as a fixed-interior example; confirm delivered rooms, collision, and supported housing integrations.

Understand the three layers

A housing script manages ownership, access, entry, storage, furniture, and financial state. A shell is a reusable interior asset usually entered through teleportation and isolation. A fixed MLO occupies a specific world location and can offer windows, exterior continuity, and unique neighborhood identity. These are not interchangeable product labels.

Fixed MLOs suit landmarks and limited premium properties but can conflict with maps and cannot represent hundreds of identical apartments without deliberate instancing. Shells scale and support customization, but routing, entity cleanup, voice, weather, and exit recovery require care. A hybrid can use fixed public buildings with instanced private units.

Browse house and apartment categories and inspect the FiveM House MLO as a fixed-location reference.

Practical criteria

• Maximum simultaneous occupied interiors is estimated realistically.
• Property, tenant, keyholder, furniture, stash, and mortgage states have stable IDs.
• Routing buckets isolate players and entities without breaking voice or phone calls.
• Entry and exit coordinates recover safely after reconnect or restart.
• Furniture placement validates model, bounds, ownership, and quantity server-side.
• Storage permissions distinguish owner, tenant, guest, and raid access.
• Fixed MLOs were checked for IPL, collision, and address conflicts.
• Deletion and repossession define what happens to inventory and furniture.

Setup workflow

Choose one property type and prove its lifecycle: listing, purchase or rental, key grant, entry, stash use, furniture placement, logout inside, reconnect, key revocation, sale, and cleanup. Do not import hundreds of properties before one lifecycle works.

For shells, test bucket assignment before teleport, entity spawning after placement, voice isolation, visitor invitations, and cleanup when the last occupant leaves. Store a safe exterior return point. On load, verify ownership before restoring a player inside. For fixed MLOs, test every entrance and window area alongside other maps and weather/time systems.

Integrate banking with transaction references so retries cannot charge twice. Integrate inventory with one stash naming convention based on immutable property ID, not address text. Connect phone invitations only after server authorization; see the phone setup guide. Use the installation guide for resource fundamentals.

Furniture catalog size affects clients and moderation. Allow approved models, cap entities per property, validate placement bounds, and provide removal recovery. Do not accept arbitrary model hashes from clients.

Compare options with capacity and recovery tests

Estimate concurrent interiors from actual population patterns, not the total number of property rows. Record likely occupied shells, visitors per unit, furniture entities, stashes, and voice participants during a peak event. For fixed MLOs, count simultaneous scenes at each address and nearby map resources. Use the estimates to compare operational load, address scarcity, customization value, and support complexity rather than assuming shells always scale without cost.

Run a staged failure sequence for one occupied property. Restart the housing script while an owner and guest are inside, stop the inventory bridge during a stash action, disconnect the owner during furniture placement, and reload after revoking a key. The safe result preserves durable ownership and item state, removes incomplete preview entities, restores valid occupants, and sends invalid occupants to the recorded exterior fallback.

Test destructive decisions separately. Simulate sale with tenants, repossession with a nonempty stash, property deletion with placed furniture, and a shell catalog update that removes the assigned model. Produce a reconciliation report before changing state. Inventory return should have a documented destination and capacity policy; furniture refunds should not duplicate items if cleanup retries. Keep historical transaction references so staff can explain what occurred.

Choose an architecture using weighted criteria: neighborhood identity, expected concurrency, furnishing depth, visitor flow, voice and bucket reliability, map-conflict exposure, migration effort, and recovery burden. Pilot several representative properties before bulk creation. A hybrid is justified only when the team can explain which lifecycle owns each type and how a player moves between them without duplicate keys, stashes, or finance records.

Mistakes and troubleshooting

Players see one another's furniture. Check bucket assignment timing and property IDs. Spawn entities only after the server confirms the destination instance.

A reconnect puts players in the void. Persist safe context, wait for character and collision readiness, and fall back to the exterior when property validation fails.

Keys continue after sale. Make transfer revoke or migrate key records atomically; do not rely on cached client lists.

Stashes collide between houses. Build names from immutable property IDs and test clone or migration paths.

Furniture remains after repossession. Define cleanup and inventory return policy before enabling automated repossession.

A fixed house breaks nearby terrain. Isolate map resources, inspect IPL and collision overlap, and review the MLO optimization guide.

Decision checklist

• [ ] Fixed MLO, shell, or hybrid choice matches scale and identity goals.
• [ ] One complete property lifecycle works before bulk import.
• [ ] Buckets, voice, entities, and visitors were tested together.
• [ ] Entry, reconnect, and failed-load fallback are safe.
• [ ] Keys, stashes, furniture, and finance use immutable property IDs.
• [ ] Furniture models and counts are server-limited.
• [ ] Sale, deletion, and repossession have inventory rules.
• [ ] Map conflicts and concurrent occupancy were tested.

Choose fixed MLOs for place, shells for repeatable private space, and a housing script for the rules connecting people to either. Scale only after lifecycle and recovery paths are dependable.