Stream your map as a FiveM resource

Treat the resource folder as a release artifact, not as your working directory. It should contain the game-ready files your map needs and a clear manifest. Blender backups, editor projects and unconverted interchange exports belong elsewhere.

Start with a clean directory

For a small custom interior, use a structure like this:

cw_workshop/
  fxmanifest.lua
  stream/
    cw_workshop.ymap
    cw_workshop.ytyp
    cw_workshop_shell.ydr
    cw_workshop_col.ybn

This is an example inventory, not an exhaustive list for every project. Add the textures and other actual dependencies your exports require. The names must match your assets and references, not merely resemble this example.

Write the resource manifest

For the example’s single YTYP:

fx_version 'cerulean'
game 'gta5'

this_is_a_map 'yes'

files {
    'stream/cw_workshop.ytyp'
}

data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop.ytyp'

Cfx.re documents the resource directives in its manifest reference and the YTYP registration type in its data-file reference.

For multiple custom YTYPs, enumerate the relevant files and registrations consistently or use the documented globbing support deliberately. Do not add registrations for files you are not shipping. A map that only places existing game archetypes can have a smaller manifest, as shown in the first YMAP tutorial.

The manifest helper generates this small example in your browser. It does not inspect your assets or validate an entire MLO.

Do not confuse manifests

A CodeWalker-generated game map manifest is not fxmanifest.lua. Likewise, a .cwproj is not a game map and cannot be streamed in place of its exports.

Use native game-format outputs produced through your chosen toolchain. Changing a filename suffix is not conversion. Keep the interchange folder out of the release directory so accidental copies are easier to notice.

Start it on a development server

Place the resource under your server’s resources directory. Resource category folders such as [maps] can organize projects; the resource name in the command must still match the actual resource folder.

From the server console:

refresh
ensure cw_workshop

Persist the appropriate ensure line in your server configuration for future starts. Check the server output rather than assuming that typing a command proves successful loading. The server command documentation is the authority for command behavior.

Visit your recorded test coordinates. A resource can start without placing its content where you expected, so inspect placement independently from startup.

Test the delivered package, not your workspace

Copy only the candidate release folder into a clean test location. Keep a list of its filenames and compare that list with the intended exports. If the map works only when another experimental resource is running, identify the missing dependency rather than leaving the dependency implicit.

Test reconnecting, approaching from outside the area and starting the server with the resource configured from the beginning. For an MLO, also repeat the room, portal and collision routes from the relevant lessons.

Keep Legacy and Enhanced release outputs distinct. The edition note explains why an older successful Legacy test is not a compatibility statement for Enhanced.

Make updates reversible

Give the release folder or external archive a version and retain the previous working package. Record the exact changes and the test route used. When updating a shared server, use the server operator’s maintenance process rather than experimenting on connected players.

After a failed deployment, restore a known working set of files together. Mixing an older YMAP with a newer YTYP or collision file makes rollback harder to reason about. A repeatable release is one you can identify, reproduce and replace as a unit.