DEUF Wiki

Every entity in a Minecraft world — every cow, boat, item frame, dropped item and armour stand — carries a UUID, a long identifier that is supposed to be unique for the whole save. The game relies on that: when it adds an entity whose UUID is already in use, it refuses the newcomer outright.

DEUF sits at exactly that moment. Instead of letting the game reject the entity, it hands the newcomer a freshly generated UUID and lets it in. Both entities then exist side by side and behave normally.

The mod adds no items, blocks, recipes or screens; it has a single config option and otherwise never announces itself.

A healthy world does not normally produce them, because new entities get random identifiers. They appear when something copies entity data verbatim:

• a world folder or region file copied between saves, or restored from a backup on top of a running world
• structures or schematics pasted with an outside editor that kept the original entity data
• a mod that spawns entities with a hard-coded or reused UUID
• a crash or an incomplete save that leaves the same entity written into two chunks

Once two entities share an identifier, the server keeps rejecting one of them each time the chunk loads, and writes a warning every single time. In heavy cases the log fills with those warnings and the world can fail to load properly.

When an entity is added to a world, DEUF checks whether its UUID is already taken:

1. Players are skipped — their identifiers must never change.
2. If the UUID is free, nothing happens at all.
3. If it is taken, a new UUID is rolled (and re-rolled until it is genuinely unused), assigned to the newcomer, and the entity is added normally.

The repaired entity keeps everything else — its position, health, inventory, name and behaviour. Only the internal identifier changes, and only for the entity that arrived second.

Without the mod that second entity would simply not be added: it disappears, and the log records a duplicate-UUID warning in its place.

The config file is created on first launch at config/deuf_refabricated.json:

{
  "enable_logging": false
}

Turning logging on is the quickest way to find out whether a world really has duplicate identifiers, and which entities are involved. A line looks like:

Changing UUID of entity minecraft:pig that already existed from 11223344-... to e39269c1-...

The config is re-read whenever data packs reload, so you can flip the option without restarting the server.

The check runs where entities are added, which is the server side — install it on the server (or on the host in single-player) and it covers everyone. Clients need nothing.

It is safe to add to an existing world: it never touches entities that are already fine, and it stores no data of its own. Removing it puts the original behaviour back, though any identifiers it repaired stay repaired, which is exactly what you want.

Because it only acts on a clash, a world with no duplicates behaves as if the mod were not installed.

• Install it before merging or restoring world files — that is when duplicates are usually created.
• Turn enable_logging on for one session after a big world edit; if nothing is logged, the save is clean.
• Silent log plus missing entities usually means something other than UUIDs is at fault; this mod only ever fixes identifier clashes.
• Pair it with regular backups. It repairs the symptom neatly, but a save that keeps producing duplicates has a source worth finding.