📦 Prop Conflicts

Prop conflicts happen when multiple resources modify the same YMAP entity but do not agree on its final state.

When is it a conflict?

Conflict Tool can report a prop conflict when two or more resources refer to the same archetype in the same placement area and disagree about what should happen to it.

Examples:

• one resource deletes a prop while another still places it,

• one moves the prop while another keeps the original placement,

• multiple resources add near-duplicate props in the same location,

• one resource replaces the model while another keeps the original model.

The review panel shows the state contributed by each resource, such as:

• removed,

• moved / changed,

• added,

• unchanged.

How prop fixes work

The goal is to make every conflicting copy agree so the visible result no longer depends on FiveM's resource streaming order.

A chosen removal or movement can therefore be mirrored across the relevant copies.

Stale LOD

A resource may hide or remove a prop while another resource still contains its low-detail LOD version.

That can leave a distant "ghost" of a prop floating where the original object used to be.

Conflict Tool mirrors the LOD treatment across copies. If a removed prop leaves behind an orphaned LOD, the tool can sink that LOD out of sight using Config.Lods.SinkDropZ.

Re-modelled prop / archetype swap

Sometimes a resource keeps the same placement but replaces the actual model.

In this case, Conflict Tool can rewrite losing copies to use the chosen model instead of deleting the entity entirely.

Replacement overlap

Another special case is when a vanilla prop is removed and multiple resources add different replacements in approximately the same location.

Because these replacements may represent intentionally different authored content, some cases can require manual review.