Investigate entity ticking and block-entity lag in a modded world.

Separate entities from block entities.

Mobs, dropped items and other entities can contribute server work, while machines and inventories often appear as block-entity or related automation work. The exact stacks depend on Minecraft, the loader and the mods involved. A broad category label is an entry point into the capture.

TickVisor groups uploaded profile data into readable systems to help you choose that entry point. Keep the original Spark file so you can examine the method context behind the group. A shared event handler may be dispatching work for several systems.

Count active work, not just placed blocks.

A large build that is unloaded may behave differently from a smaller factory held active by players or chunk-loading systems. Record which areas and dimensions are ticking during the incident. Ask whether activity changes when a particular base loads.

Look for repeated work rather than assuming visual size predicts cost. A network may scan inventories frequently, an entity population may remain active, or several systems may interact. Those possibilities need evidence from the actual pack and workload.

Design a controlled test around one area.

Preserve a baseline capture with representative activity. On a staging copy, test the same workload while one suspected area or network is inactive. Keep the version, player activity and other changes stable enough for comparison.

Do not use a broad entity-kill command or remove a mod as a first diagnostic step. Those actions may destroy pets, items, machines or world data and can make the second workload fundamentally different. Back up and obtain the owner’s approval for changes that affect a shared world.

• Record the loaded base and the activity that reproduces the issue.
• Inspect the surrounding stack, not only the package name.
• Choose a narrow and reversible staging test.
• Repeat the capture and note any gameplay cost.

Read attribution as a lead.

A high share of entity work does not establish that one mod is defective. Inclusive timing can include work beneath a common call path. Multiple systems may appear in overlapping timing categories, so their percentages are not always independent pieces to add together.

Compare overall tick pressure and capture conditions alongside the attributed share. If the second capture contains less player activity, a better grade does not isolate the cause. Record that difference and repeat the test where possible.

Keep the result useful to players.

If the evidence supports a configuration or design change, describe what it trades away. Lower activity limits or altered automation behavior can affect how a pack plays. Prefer a measured change that supports the owner’s goals over a generic recommendation to remove everything expensive.

Save the follow-up report and summarize the tested change. If the expensive work remains, carry the reproduction steps and relevant capture to the pack maintainer or hosting support team. Clear evidence helps the next reviewer avoid starting from a vague lag complaint.