Multiverse-Inventories tasks

Task guides and troubleshooting for Multiverse-Inventories. Check the installed release before changing configuration or data.

Find conflicting Multiverse-Inventories groups before changing player profiles

When one world belongs to overlapping groups, its shared data can behave differently on different travel routes. Audit membership before editing player inventories. Keep players out of the test worlds so a new transition cannot overwrite the evidence you need.

Work through the change

  1. Back up the Multiverse-Inventories data and group configuration as one checkpoint while the relevant players are offline. Record the source and destination world names for the reported mismatch.
  2. Use the installed group list and information controls to map each world to its groups. Check the documented group-conflict diagnostic where your release provides it.
  3. Compare each overlapping group’s shares, disabled shares and any optional features. Draw the two-world route and write which inventory, experience or health state should persist across it.
  4. Reproduce the route on a staging copy with a marked test inventory. Change one conflicting membership or share rule only after selecting which existing profile should remain authoritative.

Check the result

The test account should retain or change each data type exactly as the intended route specifies. Test the reverse journey too: overlapping groups can affect saving and loading in different ways. Keep the original profile files alongside the before-and-after observations.

Conflicting groups can make arrival results depend on the route taken. Record source and destination worlds for each trial rather than saying only that an inventory vanished. Keep the player offline while checkpointing profile data so the saved files represent a consistent state.

Recover or stop safely

Restore the matching configuration and profile checkpoint if the revised membership loads an unexpected inventory. Restoring only the old YAML after players have travelled can leave their data altered. Do not delete a group or bulk-clear profiles merely to remove a diagnostic warning.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.

Share bed spawns between selected worlds without sharing every player statistic

Bed spawn data is a separate share from inventory contents. Select it deliberately for worlds that belong to the same survival experience. A shared bed can still point at a location that is unavailable or unsafe when the player respawns.

Work through the change

  1. Record the group’s current world members and shares, then back up its configuration and player profiles. Choose two test worlds with safe beds and a known return route.
  2. Read the bed_spawn share definition for the installed Multiverse-Inventories release. Add or retain that specific share only where your policy requires it, without changing an entire all or stats bundle blindly.
  3. Use an expendable account to set a bed in the first world and travel to the second. Record inventory, experience and health before and after the trip as separate control values.
  4. Test a controlled respawn and then a broken-bed case on the staging copy. Check Multiverse-Core bed and respawn-world settings if the bed share exists but another rule sends the player elsewhere.

Check the result

The intended bed location should carry across the selected route while unrelated player data follows its existing policy. Confirm the destination world loads and the bed remains valid. A stored coordinate does not by itself guarantee that Minecraft accepts the bed as a respawn point.

Use a valid bed in each relevant world when checking the shared bed-spawn policy. A destroyed or obstructed bed tests fallback respawn instead. Keep the inventory observations in the same test record so a successful bed link cannot conceal an unintended item-profile change.

Recover or stop safely

Restore the prior share configuration and matching test profile data if the trial changes more than intended. Return the account to a safe lobby first. Avoid deleting bed data or changing every world’s spawn to compensate for one invalid shared location.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.

Isolate experience between world groups while preserving their inventories

You can keep experience separate even when players share other data. Decide whether the policy covers the level, total experience and progress bar together, then test the full trip. Changing only the visible level may leave another experience value shared.

Work through the change

  1. Copy the group configuration and player data during a quiet checkpoint. Record which worlds should share inventory and which should maintain separate experience progress.
  2. Read the documented individual and grouped experience shares for the installed release. Inspect an all or stats group before excluding experience so you understand what the shorthand includes.
  3. On staging, use a test account with a distinctive inventory and experience amount. Travel between the selected worlds and change experience in only the destination before returning.
  4. Compare the level number, progress bar and inventory contents on both sides. Repeat after reconnecting, while keeping the account offline during any profile inspection or restoration.

Check the result

Each world group should restore its intended experience state while the inventory follows its unchanged sharing rule. Check the reverse trip and a second ordinary account. A permission bypass or a separate experience plugin can make an administrator’s result differ from normal players.

Compare displayed levels and the underlying experience progress before and after travel. A near-empty progress bar can be hard to judge visually. Use a known disposable experience amount, record both routes, and check a second group transition rather than relying on one outward trip.

Recover or stop safely

Restore both the earlier sharing rule and the matching profile checkpoint if the trial produces an unwanted state. Do not repair the result by granting experience to every player or clearing all profiles. Keep the recorded source amount so an individual recovery remains auditable.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.

Check why a staff account bypasses Multiverse inventory separation

A staff player may keep items between worlds because a bypass permission applies, while ordinary players switch profiles as intended. Diagnose that difference without deleting the staff member’s inventory or weakening the world-group policy for everybody.

Work through the change

  1. Record the account’s source world, destination world and current inventory. Make a matched backup of player data and configuration before any travel intended to reproduce the problem.
  2. Check the installed plugin’s enable-bypass-permissions setting and its documented group or world bypass nodes. Inspect inherited staff roles, including broad grants that may imply a bypass.
  3. Compare the same route using a non-operator test account with no bypass. Keep the test inventory distinct from real player items so an unexpected transfer remains easy to recognise.
  4. Remove only the trial account’s unwanted bypass or apply a documented explicit denial through your permission manager. Reconnect and repeat the complete out-and-back journey before touching the live staff role.

Check the result

The ordinary test account and the limited staff account should follow the same separation policy where you intend that behaviour. Verify inventory, armour and ender chest according to the configured shares. A working result for an operator with a broad permission grant is not a valid control.

An administrator’s bypass can make separated worlds appear broken while ordinary players are working correctly. Keep the exact account and effective nodes in the test record. Test without operator privileges and recheck after reconnecting so cached access does not blur the result.

Recover or stop safely

Restore the prior role grants and matched profile checkpoint if the trial loads an unexpected inventory. Do not turn bypass support on merely to debug a staff role. Keep the previous permission evidence so future role changes do not silently reintroduce cross-world transfers.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.

Add an existing world to an inventory group with a profile checkpoint

Adding a world to a group can change which stored inventory players receive when they cross its boundary. Treat that membership change as a data migration. Choose the intended authoritative state before allowing anyone to travel through the newly grouped world.

Work through the change

  1. Close access to the affected route and take a completed checkpoint of world player data, Multiverse-Inventories profiles and the group configuration. Record the existing group membership and shares.
  2. On a staging copy, identify a test player with recognisable items in both the ungrouped world and the target group. Record which set you expect to keep when they first join the combined route.
  3. Use the installed add-worlds or group-management workflow documented by the maintainer. Change only that world’s membership, keeping unrelated share policies and optional features unchanged.
  4. Test first entry, return entry and reconnect with the test player. Inspect all configured data types, including armour, ender chest and experience where those shares matter to the group.

Check the result

The chosen profile should appear on every intended transition without duplicating or replacing it with an unexpected world-local state. Document the first-entry result because later successful trips can hide an incorrect initial migration. Keep regular players out until the staging result matches your policy.

Before admitting players, compare one named test profile across the old and proposed group memberships. Keep the original group definitions alongside the checkpoint. Adding a world changes which profile is selected; it should not be treated as a harmless menu-label edit for active inventories.

Recover or stop safely

Restore configuration and player profiles from the same checkpoint if the result differs from the intended authority. Removing the new membership alone may not restore data already saved during a trip. Avoid bulk migration commands without a separate tested recovery copy.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.

Diagnose an optional last-location share that overrides a portal destination

An optional last-location share can redirect a player after another plugin chooses a destination. This can look like a broken portal even when the portal’s target is correct. Compare the first and second arrival positions on a test route before changing either system.

Work through the change

  1. Record the portal’s intended destination, the player’s actual arrival and the relevant world groups. Back up configuration and test profiles before changing their travel state.
  2. Read the installed plugin’s last_location share behaviour and optional-share toggle. Check whether the share appears in a group but remains inactive, or is active through a broader configuration.
  3. On staging, set a marked last position in one world, leave it and return through the portal. Record whether the player appears there immediately or moves again after the initial teleport.
  4. Trial the intended last-location policy for that group while keeping the portal target unchanged. Repeat first entry, return entry and travel from an ungrouped control world.

Check the result

The player should follow the chosen policy consistently: either the saved group location or the explicit portal route. Document which behaviour your server promises. A group can send a returning player to a different world than the portal’s target, so inspect the world name as well as coordinates.

Write down the expected destination for a first visit and a return visit separately. Last-location sharing can make those experiences intentionally different. A portal is not necessarily malfunctioning if the inventory plugin redirects a returning player to a previously recorded place under the enabled policy.

Recover or stop safely

Restore the earlier optional-share configuration and matched profile state if the trial confuses travel. Do not move the portal landing repeatedly to counteract a later redirect. Keep the reproduction route and timestamps so support can trace both teleport decisions.

For the broader setup, read Separate creative and survival inventories with Multiverse-Inventories. Check the installed plugin version before applying syntax from the official Multiverse-Inventories documentation.