Any problem or bug please comment so i can fix it.
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 world, the player, and nearby important events back to a previous checkpoint after death.
The mod is designed around the idea of surviving through repeated loops while the world reacts to dangerous situations, exploration progress, boss encounters, multiplayer proximity, inventory changes, and major actions performed after a checkpoint.
Re:Loop is currently in Alpha. The mod is more stable than earlier test builds, but some systems are still incomplete or under active development, especially in large modpacks, old test worlds, complex modded environments, and worlds with many entities, block entities, custom loot systems, or dimension changes.
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 cancel the normal death flow and restore the current timeline back to the latest valid checkpoint.
The system can restore:
Re:Loop also includes verification passes after a return to make sure the player’s restored inventory, ender chest, portable equipment capabilities, and survival stats stay synchronized after the rollback.
Re:Loop does not simply save every few seconds. It uses an adaptive checkpoint director that tries to decide when a checkpoint makes sense based on the player’s situation.
The checkpoint system can recognize many different contexts, including:
The system also blocks bad checkpoints when the player or party is in an unsafe state, such as:
This is meant to avoid saving the player into impossible or unfair situations.
Re:Loop supports multiplayer timeline logic. When a return happens, the mod can restore connected players that are part of the active timeline context, not only the player who died.
It tracks player snapshots and can restore multiple players during the same return operation. It also considers proximity, shared progress, relevant player impact, and party safety before accepting a new checkpoint.
The mod includes shared fate-style checkpoint behavior for certain home-return situations, where other players may affect whether a checkpoint is accepted immediately or delayed until the group is safe.
Re:Loop stores world timeline state at checkpoints and attempts to restore:
This helps the return feel like a real timeline rollback instead of only moving the player.
Re:Loop tracks block changes after checkpoints and attempts to restore them during a return.
The block rollback system can track and process:
The rollback classifier separates simple blocks from more complex cases. It uses safety flags instead of blindly restoring everything the same way. This helps reduce corruption risk with fluids, block entities, modded blocks, inventories, gravity blocks, connected blocks, and complex block states.
Re:Loop can track block entity containers and restore their stored NBT during a return.
This includes container-like block entities such as chests and other inventory-based blocks, with special handling to avoid capturing already-modified states as the new truth.
The mod also tracks container interactions, deposits, withdrawals, slot changes, open containers, and close scans so item movement during a loop can be restored more accurately.
Re:Loop includes dedicated item return logic instead of treating all dropped items as generic entities.
It tracks:
The goal is to prevent common rollback bugs such as duplicated drops, deleted player-thrown items, missing picked items, or cleanup systems deleting items that were created during the return itself.
Re:Loop tracks experience orbs created after a checkpoint and attempts to clean or restore them correctly during a return.
It includes deferred return debt for XP orbs when chunks are not loaded, and it can request temporary chunk tickets so delayed XP cleanup can finish instead of silently being lost.
Re:Loop tracks several kinds of entities separately:
Living entities can be captured using snapshot transactions. Re:Loop attempts full NBT restoration when safe, and falls back to safer adapted restoration when full NBT could be risky.
For living entities, Re:Loop can restore or reapply:
If an entity appears structurally complex, such as multipart entities, mounted entities, entities with passengers, owned or tamed entities, boss-phase entities, brain or capability-heavy entities, or modded entities with risky internal data, Re:Loop avoids forcing unsafe full NBT restoration and keeps restoration debt instead of pretending the rollback is complete.
Re:Loop includes boss-aware rollback logic. It can detect possible boss activations through block interactions, entity interactions, spawner-like systems, portals, boss-like entities, and high-health or boss-named mobs.
The system tries to distinguish between:
This helps avoid deleting important modded boss controllers or breaking boss arenas while still cleaning temporary attacks, projectiles, hazards, and post-checkpoint entities that should not survive a return.
Re:Loop has dedicated handling for dangerous physics-like events.
It can track and process:
This is designed to make returns more consistent after explosions, falling blocks, TNT chain reactions, and fire-based damage.
Re:Loop does not simply give up when a rollback target is in an unloaded chunk.
The mod tracks deferred rollback debt for:
It can request temporary return chunk tickets so delayed rollback work can continue later when the needed area becomes available.
Re:Loop tracks unfinished return work as real rollback debt.
This includes debt for:
If critical rollback debt is still pending, Re:Loop can block new checkpoints so the mod does not save an incomplete or corrupted post-return state as the new timeline.
Re:Loop includes client-side feedback for the return experience.
Current client effects include:
The visual systems are tied to loop progression, memory, death pressure, and exposure to returns.
Re:Loop tracks player-specific loop data, including:
Death pressure can increase depending on the type of death, repeated deaths, valuable losses, boss-like progress, challenge advancements, and major post-checkpoint progress. It can also decay over time after surviving.
Re:Loop tracks important actions after a checkpoint to understand how meaningful the current loop has become.
Tracked impact includes:
This data is used for death pressure, checkpoint decisions, and loop progression.
Re:Loop is built with modded survival in mind. It does not try to solve compatibility by simply ignoring all modded content.
Instead, it uses classification, staged restoration, deferred debt, verification, and safer fallback behavior for difficult cases.
For risky modded content, Re:Loop may:
Re:Loop is still experimental, but the current builds are more stable than the earlier test versions.
Recent versions have improved several core systems, including checkpoint selection, player restoration, inventory and ender chest verification, block rollback scheduling, item/drop handling, return debt tracking, chunk-aware deferred rollback, and general performance during returns. The mod is now better at avoiding incomplete checkpoints, tracking unfinished rollback work, and preventing some older rollback bugs such as duplicated drops, unfinished block debt, and heavy chunk-ticket loops.
However, Re:Loop is still not finished. Some rollback systems are still being tested and improved, especially in heavily modded worlds.
Known areas that may still need testing and improvement include:
Complex modded entities
Multipart mobs
Mounted mobs and passenger relationships
Boss mechanics
Entity controllers
Hostile mob restoration after repeated returns
Mobs that place or break blocks
Mob drops created after a checkpoint
Lootr and Lootr-like storage variants
Modded storage blocks
Backpack-like systems
Curios-like systems
Portable equipment capabilities
Block entities
Containers
Drops
XP orbs
Tall blocks such as tall grass and similar multipart blocks
Support-dependent blocks such as lanterns, torches, rails, buttons, levers, and similar blocks
Dimensions and far-away rollback targets
World time, night/day, and weather edge cases
Portals
Explosions
Fluids
Falling blocks
Multiplayer returns
Large modpacks
Heavy survival servers
Old worlds created with earlier Re:Loop test builds
Important note about old worlds:
Worlds that were tested with older Re:Loop builds may contain old rollback data, unfinished chunk debt, or chunk areas affected by previous experimental versions. New worlds are expected to behave more consistently than old test worlds. If you are testing Re:Loop seriously, using a fresh world is recommended.
Please treat this version as an Alpha build. It is more stable than before, but it may still contain bugs, incomplete rollback behavior, compatibility issues, or edge cases that need more testing.
If you find a problem, please report it with:
Minecraft version
Forge version
Re:Loop version
Modpack or mod list
Logs
What happened before the checkpoint
What happened after death/return
What did not restore correctly
Whether the issue happened near or far from the checkpoint
Whether it happened in a new world or an old world from earlier Re:Loop builds
Recommended Use
Re:Loop is recommended for players who want an experimental, high-risk survival mechanic inspired by timeline loops and Return by Death-style consequences.
It is best used in testing worlds, fresh survival worlds, or modpacks where players are comfortable with Alpha behavior and willing to report issues.
This mod is not yet recommended for important long-term worlds without backups.
If you use Re:Loop in a serious survival world, make backups often.
