Re:Loop

Current description based on: Alpha Preview 9

Any problem or bug, please report it on the discord server or comment on the mod page, any tiny bug would help.

 https://discord.gg/9WZDxVY4m.

 

Re:Loop is an experimental Forge mod for Minecraft 1.20.1 that adds a Return by Death-inspired timeline rollback system.

Instead of working like a normal respawn mod, Re:Loop attempts to restore the player, the world, inventories, entities, time, important actions, and other parts of the timeline back to a previous checkpoint after death.

The mod is designed around surviving through repeated loops while the world reacts to dangerous situations, exploration progress, boss encounters, multiplayer activity, inventory changes, deaths, major actions, and everything that happened after the last checkpoint.

This description reflects the current state and systems of Re:Loop Alpha Preview 9.

Features, behavior, compatibility, and internal rollback systems may continue changing during future previews.

Re:Loop is still in Alpha. However, the latest previews are considerably more stable and complete than the earliest experimental builds and are becoming increasingly viable for normal survival gameplay.

There are still systems that need polishing, incomplete compatibility cases, and occasional bugs. Re:Loop is not perfect yet, but recent versions appear to be much less prone to the more dangerous rollback problems seen during early development.

There is still not enough testing to guarantee that severe edge cases cannot occur, especially in large modpacks, old test worlds, unusual modded environments, distant chunks, complex block entities, custom mechanics, or heavily modified entities.

Main Features

Return by Death System

Re:Loop assigns a Return by Death holder and uses that player as the main trigger for timeline restoration.

When the holder receives lethal damage or dies, the mod attempts to interrupt the normal death flow and restore the active timeline back to the latest valid checkpoint.

The player restoration system can restore:

• Player position
• Dimension
• Rotation
• Health
• Absorption
• Hunger
• Saturation
• Exhaustion
• Air supply
• Fire ticks
• Fall distance
• Frozen ticks
• Experience level
• Total experience
• Experience progress
• Inventory
• Selected hotbar slot
• Ender chest
• Active potion effects
• Forge player data
• Forge capabilities
• Portable equipment-style data
• Curios-like slots
• Accessories
• Artifacts
• Rings
• Belts
• Necklaces
• Relics
• Similar modded equipment systems

Re:Loop also performs additional restoration and synchronization work after the critical return so inventories, equipment capabilities, survival stats, and other restored data are less likely to be overwritten by delayed game or mod updates.

Staged Return System

Preview 9 uses a more structured return process instead of attempting to restore everything as one giant operation.

The return is internally divided into major stages:

PREPARE → RESTORE_CRITICAL → GAMEPLAY_COMMIT

PREPARE

Re:Loop prepares the timeline restoration, identifies what needs to return, gathers pending rollback work, and prevents unrelated changes from interfering with critical restoration.

RESTORE_CRITICAL

Important player and world state is restored first so Return by Death can complete without unnecessarily keeping the player trapped inside a large verification phase.

GAMEPLAY_COMMIT

Once the essential timeline state has been restored, gameplay can resume.

Less critical restoration work can continue afterward through background repair systems.

This makes returns more responsive and prevents large verification passes from unnecessarily delaying the entire Return by Death sequence.

Background Repair

Not every part of a heavily modded Minecraft world can always be restored instantly.

Instead of pretending unfinished restoration work does not exist, Preview 9 can keep that work as rollback debt and continue repairing the timeline after the critical return.

Background repair can continue working on things such as:

• Block rollback
• Block entities
• Containers
• Items
• Drops
• XP
• Entities
• Living entity state
• Unloaded chunks
• Falling blocks
• Explosives
• Fire
• Delayed verification
• Other incomplete rollback operations

This allows the player to return sooner while Re:Loop continues resolving non-critical timeline inconsistencies.

Adaptive Checkpoints

Re:Loop does not simply save the world every few seconds.

Instead, it uses an adaptive checkpoint director that attempts to understand whether a moment actually makes sense as a Return by Death checkpoint.

The checkpoint system can recognize many different contexts, including:

• Stable safe areas
• Player homes
• Sleeping in a bed
• Returning home after surviving danger
• Safe idle or pause-like moments
• Logout-safe situations
• Movement-based exploration progress
• Escaping from danger
• Desperate escape situations
• Safe areas near danger
• Safe pockets inside dangerous areas
• Wounded-but-stable danger moments
• Dangerous standoffs
• Cave entries
• Dungeon entries
• Structure entries
• Structure unlock moments
• Structure threshold moments
• Cleared structures
• Cleared dungeons
• Temporary camps
• Temporary homes inside dangerous areas
• Secured paths
• Loot secured after exploration
• Valuable loot secured
• Base defense moments
• Survived raid or event-like situations
• Boss hunt progress
• Boss boundary entries
• Boss entries
• Boss resolved situations
• Boss exit safety
• Teleport transitions
• Safe teleport arrivals
• Dimension entries
• Secured dimension arrivals
• Pre-dimension entry moments
• Home teleport arrivals
• Prepared departures before important actions
• Commitment actions before risky events

The checkpoint director also tries to reject dangerous or unfair checkpoints.

A checkpoint may be blocked when the player or relevant party members are:

• Dead or dying
• On fire
• Inside lava
• Falling
• Recently damaged
• Inside an unsafe open container
• Riding or carrying another entity
• Too new to capture safely
• Inside an unstable transition
• Surrounded by unresolved rollback work
• Near players that are still in danger
• In situations where creating a checkpoint could lock the timeline into an unfair state

Critical unresolved rollback debt can also prevent a new checkpoint from being accepted.

This helps avoid saving the player into impossible, corrupted, or unfair situations.

Checkpoint Testing Tools

Preview 9 also includes development and testing functionality for checkpoints.

A checkpoint can be manually forced with:

/reloop checkpoint force

This is mainly intended for testing rollback behavior and reproducing bugs without waiting for the adaptive checkpoint director to naturally select a new checkpoint.

Checkpoint notifications can also be controlled separately and are disabled by default, so normal gameplay is not constantly interrupted by development-style checkpoint messages.

Multiplayer Timeline Restoration

Re:Loop supports multiplayer timeline logic.

When a Return by Death occurs, the mod can restore connected players that belong to the active timeline context instead of treating the dead player as the only thing that changed.

Re:Loop tracks player snapshots and can restore multiple players during the same return.

The checkpoint system can consider:

• Player proximity
• Shared progress
• Relevant player impact
• Party safety
• Players affected by the current timeline
• Dangerous situations involving nearby players

Certain home-return situations also use shared-fate-style checkpoint behavior.

If an important player is still in danger, Re:Loop may delay the checkpoint instead of immediately saving the rest of the group into a timeline where that player has been abandoned.

Multiplayer restoration continues to be an experimental area and will receive more testing in later previews.

World Time and Weather Rollback

Re:Loop stores world timeline information at checkpoints and attempts to restore:

• World day time
• Weather state
• Rain state
• Thunder state
• Rain timer
• Thunder timer
• Clear weather timer

This helps Return by Death feel like an actual timeline rollback instead of simply teleporting the player back to an old position.

Some dimension, nighttime, sleeping, portal, and distant-world timing edge cases are still being tested.

Block Rollback System

Re:Loop tracks block changes performed after a checkpoint and attempts to undo them during a return.

The block rollback system can process many kinds of changes, including:

• Broken blocks
• Placed blocks
• Replaced blocks
• Block state changes
• Block entity NBT changes
• Crop growth
• Farmland trampling
• Tool-based block modifications
• Fluid block placement
• Neighbor block updates
• Nether portal area changes
• Explosion-affected blocks
• Fire and combustion changes
• Gravity-sensitive blocks
• Waterlogged states
• Redstone-like states
• Multipart-style blocks
• Support-dependent blocks
• Connectivity-sensitive blocks
• Inventory blocks
• Block entities
• Changes caused by players
• Changes caused indirectly by game mechanics
• Some changes caused by mobs

Re:Loop does not blindly restore every block using the same method.

The rollback classifier attempts to separate simple changes from more dangerous cases and assigns restoration behavior depending on the type of block involved.

This is especially important for:

• Fluids
• Containers
• Block entities
• Modded blocks
• Gravity blocks
• Connected blocks
• Multipart blocks
• Support-dependent blocks
• Blocks with custom state
• Blocks controlled by other mods

This reduces the risk of restoring a block visually while leaving its internal state corrupted.

Mob-Caused Block Changes

Preview 9 includes continued work toward recognizing world modifications caused by mobs instead of only changes directly caused by players.

This includes situations where mobs:

• Break blocks
• Place blocks
• Trigger block changes
• Cause drops to appear
• Modify the environment indirectly

The goal is for those changes to be treated as part of the post-checkpoint timeline and reversed together with everything else.

This system is still being improved.

Some mob-created blocks or mob-broken blocks may currently restore with delays, and drop cleanup from mob block destruction remains an area under active testing.

Block Entity and Container Restoration

Re:Loop can capture block entity state and restore stored NBT during a return.

This includes container-style block entities such as:

• Chests
• Barrels
• Furnaces
• Storage blocks
• Modded containers
• Other inventory-based block entities

The system tracks more than just the existence of the block.

Re:Loop can observe:

• Container interactions
• Deposits
• Withdrawals
• Slot changes
• Open containers
• Container closing
• Inventory state
• Block entity NBT

Special safeguards are used to avoid accidentally capturing an already-modified container as the new checkpoint truth.

Complex modded block entities remain one of the most difficult compatibility areas and continue to receive dedicated testing.

Item, Drop, and Pickup Handling

Re:Loop uses dedicated timeline handling for items rather than treating every dropped item as a normal entity.

It can track:

• Items tossed by players after a checkpoint
• Items picked up after a checkpoint
• New item entities created after a checkpoint
• Block drops
• Mob-related drops
• Items created by explosions
• Item entities that should disappear during a return
• Items that should return after being picked up
• Deferred item restoration in unloaded chunks

A major goal of this system is preventing common rollback exploits and bugs such as:

• Duplicated drops
• Items surviving from a timeline that was erased
• Player-thrown items being incorrectly deleted
• Picked-up checkpoint items disappearing permanently
• Post-return cleanup deleting legitimate new items
• Block drops being duplicated after block restoration

Preview 9 contains several improvements to drop tracking and cleanup, although certain modded or mob-created drop situations are still being refined.

Experience Orb Handling

Re:Loop tracks experience orbs created after a checkpoint and attempts to clean or restore them correctly during a return.

It can also keep deferred XP restoration debt when the required chunk is unavailable.

Temporary return chunk tickets can be requested when necessary so XP cleanup does not simply disappear because an area was unloaded during the return.

Entity Rollback System

Entity rollback is still in an early stage of development in Preview 9.

Re:Loop can already detect, classify, track, remove, and restore different types of entities, but living entity restoration is intentionally being kept relatively simple for now.

During development, more aggressive restoration of living entities caused an important bug where some mobs could begin teleporting or rapidly jumping between positions after a Return by Death.

Because of this, advanced living entity restoration is currently being developed conservatively instead of forcing complete internal state restoration and risking unstable entities.

For now, Re:Loop focuses primarily on restoring safer and more important parts of an entity while avoiding aggressive modification of systems such as:

• AI
• Navigation
• Brain state
• Complex capabilities
• Internal controllers
• Mod-specific behavior
• Passenger systems
• Ownership information
• Other complex runtime data

Tracked entity categories currently include:

• Temporary entities
• Projectiles
• Area effect clouds
• Lightning
• Arrows
• Tridents
• Snowballs
• Eggs
• Ender pearls
• Experience bottles
• Potions
• Fireballs
• Wither skulls
• Shulker bullets
• Fishing bobbers
• Decoration entities
• Armor stands
• Item frames
• Paintings
• Display-like entities
• Living entities
• Passive mobs
• Hostile mobs
• Modded mobs
• Boss-like entities
• Runtime boss effects
• Falling blocks
• Primed TNT
• Transient explosives

For living entities, Preview 9 currently concentrates on safer restoration of basic state such as:

• Position
• Rotation
• Motion
• Health
• Absorption
• Air supply
• Fire ticks
• Frozen ticks
• Fall distance
• Main hand equipment
• Offhand equipment
• Armor
• Active effects
• Basic combat state
• Basic target cleanup
• Basic aggression cleanup

This means living entities may not yet return exactly to every internal state they had at the checkpoint.

For example, advanced AI state, navigation, mod-specific behavior, brain data, capability state, and other internal systems may not yet be completely restored.

The entity rollback system will gradually become more advanced once the teleportation and post-return AI problems can be solved reliably without introducing new instability.

Until then, keeping living entity restoration relatively simple is intentional.

Complex Entity Protection

If an entity appears structurally dangerous to restore, Re:Loop avoids pretending that it is a normal mob.

Examples include:

• Multipart entities
• Mounted entities
• Passenger relationships
• Owned entities
• Tamed entities
• Boss-phase entities
• Brain-heavy entities
• Capability-heavy entities
• Modded entities with unusual internal data
• Entities controlled by external systems

In those situations, Re:Loop may use partial restoration, safer physical restoration, delayed repair, or keep rollback debt rather than forcing unsafe NBT and potentially corrupting the entity or world.

This protection is especially important while the more advanced entity rollback system is still under development.

Boss and Dangerous Event Handling

Re:Loop includes boss-aware rollback logic.

Possible boss activation can be detected through systems such as:

• Block interactions
• Entity interactions
• Spawner-like systems
• Portals
• Boss-like entities
• High-health mobs
• Boss-named entities
• Arena-related activity

The system attempts to distinguish between:

• Main boss entities
• Runtime boss attacks
• Projectiles
• Hazards
• Persistent mechanics
• Visual entities
• Interaction entities
• Static decoration
• Activator-like entities
• Boss arena systems

This distinction is important because blindly removing every post-checkpoint entity could destroy a modded boss controller or permanently break an arena.

At the same time, temporary attacks, projectiles, hazards, and entities created only during the erased timeline should normally not survive the return.

Boss restoration remains experimental, particularly when the boss uses custom entities, controllers, phases, or mod-specific arena systems.

Explosions, TNT, Falling Blocks, and Fire

Re:Loop contains dedicated handling for physics-like and destructive events.

It can track and process:

• Explosion-affected blocks
• Post-explosion drop cleanup zones
• Primed TNT created after checkpoints
• TNT that already existed at the checkpoint
• Explosive entities
• Falling block entities
• Checkpoint falling blocks
• Fire spread
• Combustion-related blocks
• Post-checkpoint fire

These systems are designed to make Return by Death more consistent after:

• Explosions
• TNT chain reactions
• Falling sand or gravel
• Gravity blocks
• Fire spreading through structures
• Large destructive events

Chunk-Aware Deferred Rollback

Re:Loop does not simply abandon restoration because something is far away or located inside an unloaded chunk.

The mod can track deferred rollback work for:

• Unloaded block rollback
• Block entity restoration
• Container restoration
• Item restoration
• XP cleanup
• Entity restoration
• Living entity verification
• Block verification
• Chunk-based return operations

Temporary return chunk tickets can be requested so important restoration work has another opportunity to complete.

The chunk system has also been changed over time to reduce unnecessarily aggressive chunk loading and heavy return-time loops.

Distance-related rollback remains one of the systems being continuously tested and optimized.

Return Verification and Rollback Debt

One of Re:Loop's main safety systems is rollback debt.

If something could not be restored correctly, the mod attempts to remember that unfinished work instead of silently considering the timeline fixed.

Rollback debt can exist for:

• Items
• Item chunk work
• Container slots
• Block entity containers
• Block drops
• Block rollback queues
• Unloaded block changes
• Return chunk tickets
• XP
• Falling blocks
• Explosives
• Fire
• Entities
• Living entities
• Block verification
• Block state checks
• Other delayed restoration work

Critical rollback debt can prevent the creation of a new checkpoint.

This is extremely important because saving a new checkpoint while the old timeline is only partially restored could permanently convert a rollback bug into the new timeline state.

Rollback Mutation Isolation

Preview 9 also includes additional internal safeguards for distinguishing between:

1. Changes originally performed during the timeline.
2. Changes performed by Re:Loop while restoring that timeline.

Without this distinction, a rollback system can accidentally detect its own restoration work as brand-new world modifications.

Re:Loop now uses additional timeline identity and rollback mutation tracking so restoration operations can be separated from normal gameplay mutations.

This helps reduce:

• Recursive rollback behavior
• Incorrect drop tracking
• Duplicated restoration work
• Cleanup affecting restoration-created objects
• Re:Loop recording its own changes as new timeline mutations

Client Effects

Re:Loop includes client-side feedback to make Return by Death feel different from a normal Minecraft respawn.

Current systems include:

• Return by Death sound
• Short return fog effect
• Vanilla-style return effects
• Death pressure visuals
• Monochrome exposure
• Monochrome awakening progression
• Shader-based monochrome effect levels
• Network synchronization for return effects
• Forced return/respawn handling

These visual systems are connected to loop progression, memory, death pressure, and repeated exposure to Return by Death.

Loop Progression

Re:Loop tracks player-specific timeline information such as:

• Return holder status
• Awakened Return holder status
• Return affinity
• Loop memory
• Witch scent
• Last return time
• Death pressure
• Death pressure streak
• Exposure count
• Monochrome exposure
• Monochrome lock state
• Loop count
• Checkpoint impact
• Advancement impact
• Boss kill impact
• Item impact
• Block impact
• Entity impact

Death pressure can increase depending on:

• Type of death
• Repeated deaths
• Valuable losses
• Boss progress
• Challenge advancements
• Major post-checkpoint progress
• Important actions performed before dying

It can also decay after the player manages to survive for longer periods.

Impact Tracking

Re:Loop tracks important actions performed after a checkpoint to understand how meaningful the current timeline has become.

Tracked impact can include:

• Breaking blocks
• Placing blocks
• Picking up items
• Tossing items
• Killing entities
• Killing bosses
• Advancements
• Advanced advancements
• Challenge-like advancements
• Valuable item loss
• Inventory value changes
• Ender chest value changes
• Major exploration progress

This information can affect:

• Checkpoint decisions
• Death pressure
• Loop progression
• The importance of the current timeline

Modded Equipment and Capability Restoration

Re:Loop is also being designed to handle information that does not live directly inside the vanilla player inventory.

This can include Forge capabilities and equipment systems used by mods for:

• Accessories
• Relics
• Rings
• Necklaces
• Belts
• Artifacts
• Portable inventories
• Additional equipment slots
• Curios-like systems

Capability restoration is much more complicated than copying a vanilla inventory because every mod may store and synchronize its information differently.

Because of this, capability handling includes additional restoration and synchronization safeguards.

Mod Compatibility Philosophy

Re:Loop is being developed specifically with modded Minecraft in mind.

The long-term goal is not to manually create one enormous compatibility patch for every individual Minecraft mod.

Whenever possible, Re:Loop attempts to understand the underlying mechanics shared by many mods.

Examples include:

• Inventories
• Block entities
• Tanks
• Fluids
• Energy storage
• Capability data
• Custom block states
• Connected blocks
• Multipart structures
• Machine inventories
• Persistent entities
• Controllers
• Internal NBT
• Custom equipment
• Custom loot systems
• Modded AI
• Other common Forge systems

By learning how these common systems behave, improvements made while supporting one complicated mod may eventually improve compatibility with many unrelated mods at the same time.

The objective is for Re:Loop to increasingly understand the systems used by mods instead of requiring the developer to manually add every block from every mod.

Upcoming Create Compatibility and Universal Mod Rollback

One of the next major compatibility targets is Create.

Create is especially valuable for Re:Loop development because it combines many different types of complex modded mechanics inside the same mod.

Its systems include things such as:

• Complex block entities
• Inventories
• Fluid tanks
• Processing blocks
• Moving or connected machinery
• Multiblock-like behavior
• Kinetic systems
• Custom block states
• Internal machine data
• Controllers
• Machines whose visible block state represents only part of their real internal state

Because of this, the goal of working on Create is not only to make Re:Loop compatible with Create.

Create will also act as an important development target for discovering and implementing reusable rollback techniques.

For example, while adding Create compatibility, Re:Loop may learn how to safely recognize and restore:

• Common fluid storage systems
• Item handlers
• Machine inventories
• Forge capabilities
• Energy systems
• Connected block structures
• Machine controllers
• Persistent block entity data
• Complex block states
• Common modded synchronization patterns

Those discoveries can then become part of Re:Loop's general compatibility layer.

If another mod uses a similar inventory, tank, capability, machine structure, or block entity system, Re:Loop may eventually be able to restore it automatically without requiring a dedicated compatibility update for that specific mod.

Create will not be the only mod used for this.

Other complex mods will also be studied over time so Re:Loop can identify more reusable systems shared across the modded Minecraft ecosystem.

The long-term objective is for Re:Loop to build a progressively larger understanding of common Forge and Minecraft systems so compatibility improvements can apply to many mods at once.

Universal Compatibility + Specific Adapters

Universal compatibility does not mean dedicated mod compatibility will disappear.

Some mods contain mechanics that are simply too specialized to restore safely using generic rules.

Because of this, Re:Loop is planned around two complementary compatibility layers.

Universal Restoration

Used whenever Re:Loop recognizes a system shared by many mods.

Examples may include:

• Forge capabilities
• Inventories
• Fluid handlers
• Energy storage
• Common block entity patterns
• Standard NBT structures
• Item handlers
• Common machine structures
• Common equipment systems
• Common synchronization behavior

Improvements to these systems could automatically benefit many different mods.

Mod-Specific Compatibility

Used when a mod contains special mechanics that require dedicated knowledge.

Examples may include:

• Unique controllers
• Custom multiblock logic
• Special boss systems
• Unusual loot ownership
• Custom synchronization systems
• Custom entity lifecycles
• Machines with unique restoration requirements
• Systems where normal NBT restoration is unsafe
• Mechanics that cannot be reliably identified through generic Forge systems

These mods can still receive explicit Re:Loop compatibility when necessary.

The goal is therefore:

Make the universal system strong enough that a large number of mods work automatically, while preserving dedicated compatibility for mods that genuinely need special handling.

This should allow Re:Loop's mod compatibility to expand much faster than maintaining thousands of independent patches.

Current Modded Testing

Preview 9 is already being tested against increasingly complicated modded situations.

Testing includes systems such as:

• Modded storage
• Backpack-style inventories
• Portable equipment
• Lootr-style containers
• Custom block entities
• Mob-controlled world changes
• Modded mobs
• Bosses
• Custom drops
• Capability data
• Fluids
• Machines
• Containers
• Multipart or connected blocks

Some systems already behave significantly better than in previous previews, but this does not mean complete compatibility is guaranteed yet.

Create compatibility in particular should currently be considered an upcoming development target, not finished support.

Safety-Oriented Mod Compatibility

Re:Loop does not attempt to solve compatibility by simply ignoring modded content.

For risky situations it can use:

• Full restoration when safe
• Partial restoration when necessary
• Adapted physical or vital restoration
• Equipment restoration
• Capability restoration
• Deferred rollback
• Background verification
• Rollback debt
• Safer fallback behavior
• Protection against repeatedly failing restoration
• Avoidance of dangerous NBT writes
• Checkpoint blocking while critical restoration is unfinished

The objective is to prefer an incomplete but recoverable rollback over aggressively forcing data into a modded object and potentially corrupting the world.

Current Alpha State — Preview 9

Re:Loop is still an Alpha mod, but the latest previews are becoming much more viable for normal survival gameplay.

Compared with the earliest experimental versions, Preview 9 contains significantly more safeguards, better rollback tracking, more controlled restoration, background repair, rollback debt, improved synchronization, and better protection against incomplete returns.

Recent testing suggests that the latest builds are no longer limited only to short technical testing worlds.

A normal survival playthrough is now considerably more practical, particularly when using a fresh world.

However, this does not mean Re:Loop is finished or perfectly safe.

There are still systems that need additional polishing, incomplete compatibility cases, and bugs that may appear during unusual situations.

Some systems are also intentionally still in relatively early stages of development. Living entity rollback is one of the clearest examples because advanced entity restoration is currently being held back while teleportation and AI-related problems are investigated.

The bugs observed in the latest previews generally appear to be less dangerous than some of the problems encountered during the earliest experimental versions.

Earlier development versions could occasionally produce more serious rollback inconsistencies, while newer versions include several systems specifically designed to prevent incomplete restoration from silently becoming permanent.

These protections include:

• Staged restoration
• Rollback debt
• Background repair
• Safer restoration fallbacks
• Mutation isolation
• Checkpoint blocking when critical restoration is unfinished
• Reduced aggressive chunk handling
• More conservative handling of complex entities
• More conservative handling of complex block entities
• Additional restoration verification

However, there is not enough testing yet to guarantee that severe rollback bugs can never occur in Preview 9 or later Alpha previews.

So far, the latest builds appear much safer, but unexpected edge cases may still exist and simply have not been discovered yet.

Re:Loop should therefore currently be considered:

Playable for normal survival, but still experimental.

Players should still expect occasional bugs, incomplete restoration, or mod compatibility problems while development continues.

Known Areas Still Being Tested

Current areas that may still contain incomplete behavior or edge cases include:

• Living entity rollback — still in early development
• Entity teleportation or unstable movement after some returns
• Advanced mob AI restoration
• Mob navigation restoration
• Complex modded entities
• Multipart mobs
• Mounted mobs
• Passenger relationships
• Boss mechanics
• Boss controllers
• Entity controllers
• Hostile mob AI after repeated returns
• Mob aggression restoration
• Mobs that place blocks
• Mobs that break blocks
• Drops created when mobs break blocks
• Lootr
• Lootr-like storage variants
• Custom loot systems
• Modded storage blocks
• Complex backpacks
• Curios-like systems
• Portable equipment capabilities
• Complex block entities
• Containers
• Drops
• XP orbs
• Tall or multipart blocks
• Support-dependent blocks
• Lanterns
• Torches
• Rails
• Buttons
• Levers
• Connectivity-sensitive blocks
• Distant rollback targets
• Unloaded chunks
• Dimensions
• World time
• Sleeping and nighttime restoration
• Weather edge cases
• Portals
• Explosions
• Fluids
• Fluid containers
• Falling blocks
• Multiplayer returns
• Large modpacks
• Heavy survival servers
• Old worlds created with earlier Re:Loop previews
• Complex modded machines
• Machine controllers
• Mod-specific synchronization

Some of these systems already partially work and are listed because edge cases are still being investigated.

Being listed here does not necessarily mean the system is completely broken.

Important Note About Old Worlds

Worlds that were repeatedly tested using older experimental Re:Loop versions may contain:

• Old rollback data
• Unfinished rollback debt
• Old chunk restoration information
• World areas affected by previous experimental behavior

Because the mod has changed significantly between early previews, old testing worlds may behave differently from fresh worlds.

New worlds are currently expected to behave more consistently than worlds heavily used with older Re:Loop test builds.

If you encounter unusual behavior in a world that has been used across many old previews, reproducing the same situation in a fresh world can help determine whether the problem still exists in the current version.

Bug Reports

Please remember that Preview 9 is still an Alpha preview.

It is considerably more mature than the earliest versions, but bugs, incomplete restoration, compatibility problems, and unusual edge cases are still possible.

If you encounter a problem, please report:

• Minecraft version
• Forge version
• Re:Loop version
• Modpack or mod list
• latest.log
• What happened before the checkpoint
• What happened after death or Return by Death
• What failed to restore
• Whether the problem happened near or far from the checkpoint
• Whether the affected chunk was loaded
• Whether the problem happened in a new world
• Whether the world had previously been used with older Re:Loop builds
• Which mod was involved, if applicable
• Clear steps to reproduce the problem if possible

Detailed reports are extremely useful for improving both specific compatibility and Re:Loop's universal rollback systems.

Recommended Use

The latest Re:Loop previews are now considerably more suitable for players who want to experience Return by Death during a normal survival playthrough, rather than only inside dedicated testing worlds.

Preview 9 is significantly more viable for regular survival than the earliest Alpha builds.

Re:Loop is currently suitable for:

• Normal experimental survival worlds
• Fresh modded survival worlds
• Testing worlds
• Modpacks
• Multiplayer testing
• Players who understand that some rollback systems are still unfinished
• Players willing to report unusual restoration behavior

However, Re:Loop is still Alpha software and is not perfect yet.

Some bugs and compatibility problems remain.

Certain systems, especially:

• Advanced living entity restoration
• Complex modded block entities
• Distant rollback
• Custom machines
• Unusual mod mechanics
• Certain multiplayer situations

still need additional development and testing.

The latest versions appear to have significantly reduced the risk of some of the more dangerous rollback problems seen during early development.

However, this does not guarantee that similar problems are completely impossible.

There may still be rare bugs or combinations of mods that have simply not been encountered yet.

For important or long-term survival worlds, regular backups are still strongly recommended.

The goal of the current previews is to continue moving Re:Loop from an experimental rollback system toward something reliable enough to become a normal part of long-term modded survival.

Future Development

Future Re:Loop previews will continue expanding:

• Rollback accuracy
• Performance
• Multiplayer restoration
• Entity restoration
• Entity AI restoration
• Mob-caused world changes
• Distant chunk restoration
• Block entity support
• Fluid restoration
• Machine restoration
• Modded inventories
• Capability support
• Boss compatibility
• Create compatibility
• Compatibility with additional major mods
• Universal recognition of common mod systems
• Dedicated adapters for mods with unique mechanics

A major part of future development will involve studying complex mods such as Create and extracting reusable solutions from their mechanics.

Instead of only adding support for one mod at a time, Re:Loop will attempt to turn those discoveries into more universal systems capable of understanding similar mechanics used by many different mods.

The long-term objective is for Re:Loop to understand enough common Minecraft and Forge systems that a large amount of modded content can be reverted automatically, even when Re:Loop has never received an update specifically for that individual mod.

At the same time, dedicated compatibility systems will remain available for mods whose mechanics are too specialized to restore safely through generic rules.

Preview 9 represents another major step toward making Return by Death behave like a real rollback of an entire modded Minecraft timeline rather than simply a modified respawn system.