The easiest way to get lost in a mapping workflow is to ask one application to prove everything. A good Blender render does not prove that a game asset exported correctly. A good CodeWalker view does not prove that the deployed resource has the right files.
Give each stage one responsibility and one observable output.
Blender is where you author the shape
For an original model, this is where you work on geometry, dimensions, UVs and the source scene. Keep a readable project structure so you can distinguish the visible model from collision and reference material.
Use a very small original object for the first round trip. It should be recognizable enough that you can tell the new export from an older version, but uncomplicated enough that a failure does not leave you with twenty material and geometry hypotheses.
Sollumz prepares the GTA asset structure
Sollumz is the Blender-side modding tool in this workflow. Its documentation covers the supported structures and its installation guide distinguishes extension installation from older add-on routes.
Do not assume that a standard Blender object is already a correctly configured GTA drawable or collision asset. The conversion, hierarchy, shader and export choices are part of the authoring work.
Treat the installed version as part of the project. “I use Sollumz” is not enough detail to reproduce a problem when two people are using different export interfaces.
CodeWalker connects the result to the world
The author’s README describes world inspection, archive exploration, entity editing and project management. This is where you inspect game data and work with the placement context.
Use it to answer specific questions: does the exported asset open, which archetype is selected, which YMAP places it, and is the world transform correct? Keep those questions separate from the quality of your source model.
The README itself says that a complete map-making tutorial is outside its scope. A missing modeling step is not evidence that CodeWalker performs that step automatically.
FiveM is the deployment test
The resource package is a separate artifact with its own manifest. The test server tells you whether the intended files are delivered and whether the map behaves in its actual target context.
Repeat entrance, room-transition and collision tests there. The word “works” should always name the stage: works in the source scene, opens as an exported asset, or passes the server test. Those are three useful but different results.
Keep the handoffs inspectable
Save the original source, the interchange output when used, and the final resource separately. For each handoff, retain a short observation and the tool versions involved.
When a change fails, return to the last successful boundary. If the drawable no longer opens in CodeWalker, investigate the export before editing the resource configuration. If it opens but never appears on the server, inspect the definition, placement and package.
The toolchain setup tutorial turns that separation into a small practical exercise. Once that pipeline is dependable, a larger interior is mostly a matter of adding responsibilities carefully rather than inventing a new process each time.