Author a door that moves around the right origin

Door authoring is different from writing a door-lock script. The asset needs the right drawable hierarchy, origin, collision and archetype settings before a script can operate it reliably. This guide covers the three door families in the official asset series; it does not certify a shipped door binary or a particular framework’s door-lock integration.

Prepare an owned door mesh and textures, back up the project, and keep an unmodified reference export. Use game templates only from your own game installation for local inspection; this project does not redistribute them.

Choose the door family

Motion	Local reference drawable	Origin	YTYP Special Attribute
Swinging	`v_ilev_bl_door_l.ydr`	At the hinge, on the opening edge	Normal Door (7)
Horizontal sliding/gate	`prop_facgate_07b.ydr`	Bottom corner	Sliding Door (8)
Vertical garage door	`lr_prop_supermod_door_01.ydr`	Bottom center	Garage Door (5)

For all three families, enable the archetype’s Dynamic and Enable Door Physics flags. These values describe the asset; they do not grant players permission to open it.

Establish the hierarchy and pivot

Import the appropriate reference with the asset-library workflow. Retain its armature/bone structure while replacing the visual mesh with your own work.

Align your mesh with the reference’s closed position. In Edit Mode, select geometry at the intended pivot and snap the 3D cursor there.
Return to Object Mode and set the mesh origin to the 3D cursor. For a swinging door, inspect the hinge from more than one view rather than accepting a bounding-box center.
Apply the transforms needed by your export workflow before wiring the final hierarchy. Recheck scale, orientation and the closed pose after applying them.
Convert your mesh to a Drawable. Remove the reference’s visual door mesh, unparent your replacement as needed, and parent it to the template Armature/Drawable.
Add a Copy Transforms constraint to the replacement mesh. Set its target to the template armature and choose the door bone.
Rename the resulting asset consistently. Keep the reference file and your distributable output separate so no template model is accidentally shipped.

Check the closed pose, origin and bone relationship before proceeding to collision. A hinge door that swings around its center usually has an authoring pivot problem, not a network synchronization problem.

Rebuild edited collision bounds

When collision scale or transforms change, create a new Bound Composite and parent the collision into it. Do not assume transforming an old composite preserves the required structure.

Inspect collision at the closed pose and during the intended movement. Look for a second static collision shape left in the frame, duplicate bounds, non-applied scale, and offsets between the mesh and collision. Do not erase the building’s collision to compensate for a door setup error. Use the collision lab to separate geometry faults from placement faults.

Register the archetype and placement

Create a YTYP archetype for your drawable, choose the special attribute from the table, and set both door flags. Export the drawable, textures and YTYP, then create the YMAP placement. Keep filenames, archetype name and placement name consistent and unique.

The resource manifest registers the exported YTYP in the usual way:


fx_version 'cerulean'
game 'gta5'
this_is_a_map 'yes'
files { 'stream/lab_door.ytyp' }
data_file 'DLC_ITYP_REQUEST' 'stream/lab_door.ytyp'

This declaration does not implement a lock, access control, a garage trigger or persistence. Add those separately through a server-authoritative resource after the asset works without the framework. Never let an arbitrary client choose which persistent door record becomes unlocked.

Test each door family separately

For swinging doors, verify movement around the hinge in both directions and check that the frame stays still. For sliding gates, check the horizontal travel from the bottom-corner origin. For a garage door, check vertical travel around the bottom-center setup. Do not change all three origin schemes in one debugging pass.

Record the client track/build and FXServer artifact. Test initial loading, open/close behavior, collision while moving, two clients, streaming out and back in, and a resource restart. A successful Blender preview or CodeWalker reload is not evidence that all these game behaviors passed.

Failure	First authoring check
Door rotates around the wrong place	Mesh origin, bone origin and family-specific pivot.
Door is immovable	Special Attribute plus Dynamic and Enable Door Physics.
Visible door moves but passage remains blocked	Static or duplicate collision, edited Bound Composite, collision hierarchy.
Motion is the wrong kind	Template family and attribute 7, 8 or 5.
Only one client sees the intended state	After confirming the asset, inspect the door controller and replicated server state.

See Cfx.re asset series Part 8 , map animations, asset authoring and secure events.