Re:Loop
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, so some systems may still be incomplete, unstable, or incompatible with certain heavily modded setups.
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 cancel the normal death flow and restore the current timeline back to the latest valid checkpoint.
The 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, including support for portable equipment-style data such as Curios-like slots, accessories, artifacts, rings, belts, necklaces, relics, and similar modded equipment systems
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.
Adaptive Checkpoints
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:
- 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 system also blocks bad checkpoints when the player or party is in an unsafe state, such as:
- Being dead or dying
- Being on fire or in lava
- Falling
- Recently taking damage
- Being inside an unsafe open container
- Being in a vehicle or passenger relationship
- Being too new to capture safely
- Being in an unsafe transition
- Having unresolved rollback debt from a previous return
- Having nearby players in unsafe states when they are part of the checkpoint context
This is meant to avoid saving the player into impossible or unfair situations.
Multiplayer Timeline Restoration
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.
World Time and Weather Rollback
Re:Loop stores world timeline state at checkpoints and attempts to restore:
- World day time
- Weather state
- Rain state
- Thunder state
- Rain timer
- Thunder timer
- Clear weather timer
This helps the return feel like a real timeline rollback instead of only moving the player.
Block Rollback System
Re:Loop tracks block changes after checkpoints and attempts to restore them during a return.
The block rollback system can track and process:
- 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-related changes
- Gravity-sensitive blocks
- Waterlogged states
- Redstone-like states
- Multipart-style blocks
- Support-dependent blocks
- Connectivity-sensitive blocks
- Blocks with inventories or block entities
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.
Block Entity and Container Restoration
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.
Item, Drop, and Pickup Handling
Re:Loop includes dedicated item return logic instead of treating all dropped items as generic entities.
It tracks:
- Items tossed by players after a checkpoint
- Items picked up after a checkpoint
- New item entities created after a checkpoint
- Block drops created after block breaks
- Item entities that should be cleaned during return
- Items that should be restored if they were picked up after the checkpoint
- Deferred item return debt when chunks are not loaded
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.
Experience Orb Handling
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.
Entity Rollback System
Re:Loop tracks several kinds of entities separately:
- 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
- Modded mobs
- Boss-like entities
- Runtime boss effects
- Falling blocks
- Primed TNT
- Transient explosives
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:
- Entity type
- Position
- Rotation
- Motion
- Gravity state
- Ground state
- Health
- Absorption
- Air supply
- Fire ticks
- Frozen ticks
- Fall distance
- Main hand item
- Offhand item
- Armor
- Active effects
- Basic AI combat cleanup, such as clearing targets and aggression after restoration
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.
Boss and Dangerous Event Handling
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:
- Main boss entities
- Runtime boss attacks
- Projectiles
- Hazards
- Persistent boss mechanics
- Visual or interaction entities
- Static decoration entities
- Activator-like entities
- Boss arena mechanics
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.
Explosions, TNT, Falling Blocks, and Fire
Re:Loop has dedicated handling for dangerous physics-like events.
It can track and process:
- Explosion-affected blocks
- Post-explosion drop cleanup zones
- Primed TNT created after checkpoints
- Checkpoint TNT and explosive entities
- Falling block entities
- Checkpoint falling block restoration
- Fire spread and combustion-related blocks
- Post-checkpoint fire cleanup
This is designed to make returns more consistent after explosions, falling blocks, TNT chain reactions, and fire-based damage.
Chunk-Aware Deferred Rollback
Re:Loop does not simply give up when a rollback target is in an unloaded chunk.
The mod tracks deferred rollback debt for:
- Unloaded block rollback records
- Block entity container restoration
- Item restoration
- XP orb cleanup
- Entity restoration
- Living entity verification
- Block rollback verification
- Chunk-based return work
It can request temporary return chunk tickets so delayed rollback work can continue later when the needed area becomes available.
Return Verification and Debt System
Re:Loop tracks unfinished return work as real rollback debt.
This includes debt for:
- Items
- Item chunk work
- Container slot restoration
- Block entity containers
- Block drops
- Block rollback queues
- Unloaded block rollback
- Return chunk tickets
- XP
- Falling blocks
- Explosives
- Fire
- Entities
- Block rollback verification
- Block state checks
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.
Client Effects
Re:Loop includes client-side feedback for the return experience.
Current client effects include:
- Return by Death sound
- Short return fog effect
- Vanilla-style return effects
- Death pressure visuals
- Monochrome exposure system
- Monochrome awakening progression
- Shader-based monochrome effect buckets
- Network packets for return fog, death pressure, monochrome state, and forced respawn handling
The visual systems are tied to loop progression, memory, death pressure, and exposure to returns.
Loop Progression
Re:Loop tracks player-specific loop data, including:
- 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, block, and entity impact after checkpoint
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.
Impact Tracking
Re:Loop tracks important actions after a checkpoint to understand how meaningful the current loop has become.
Tracked impact includes:
- Block breaking
- Block placing
- Item pickups
- Item tosses
- Entity kills
- Boss kills
- Advancements
- Advanced advancements
- Challenge-like advancements
- Valuable item loss
- Inventory value changes
- Ender chest value changes
This data is used for death pressure, checkpoint decisions, and loop progression.
Safety-Oriented Mod Compatibility
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:
- Restore full state when safe
- Restore partial physical or vital state when full state is unsafe
- Use adapted restoration for equipment and effects
- Keep debt for later verification
- Soft-protect entities after repeated rollback failures
- Avoid forcing unsafe NBT on complex mechanics
- Avoid saving a new checkpoint while critical restoration work is unfinished
Current Alpha Status
Re:Loop is still experimental.
This version may still contain bugs, crashes, incomplete rollback behavior, or compatibility issues, especially in large modpacks or with complex modded systems.
Known areas that may still need testing and improvement include:
- Complex modded entities
- Boss mechanics
- Multipart mobs
- Entity controllers
- Modded inventories
- Backpack-like systems
- Curios-like systems
- Portals
- Dimensions
- Explosions
- Fluids
- Block entities
- Drops
- XP orbs
- Multiplayer returns
- Large modpacks
- Heavy survival servers
Please treat this version as an early Alpha build and report issues with logs, reproduction steps, Minecraft version, Forge version, modpack information, and a clear explanation of what happened before and after the return.
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 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.

