docs(InvSwitcher): document conflicts with other inventory plugins

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc

[tastybento]

Why

A server admin reported island inventories being wiped on every world change: get an item on the island, go to the lobby, come back, item gone. They had tested three InvSwitcher versions and found the same behaviour on each, and had ruled out Multiverse-Inventories because none of their BentoBox worlds were in an MV-I inventory group.

Reproduced locally against BentoBox 3.21.1 with MV-Core 5.7.3 + MV-Inventories 5.3.5. It is a plugin conflict, not an InvSwitcher bug.

What the testing showed

With MV-I loaded and the BentoBox worlds in no group, the island inventory was not lost — it was misfiled. All 8 items were written under the lobby storage key, and an empty inventory under the island key. Each plugin faithfully saves a player state the other has already rewritten, so nothing is logged and it looks like data loss.

Three findings that admins are unlikely to work out on their own:

1. Groups do not control involvement. MV-I wrote a per-world profile for acidisland_world while it was in no group and default-ungrouped-worlds was false. Groups control which worlds share an inventory.
2. /mv remove does not stick. Multiverse-Core re-registers BentoBox worlds as they load. From the server log: MV-Core enabled at 19:16:29, BentoBox created the worlds at 19:16:30, worlds.yml was rewritten at 19:16:31 with all of them back. auto-import-3rd-party-worlds: false only suppresses the sweep at MV-Core startup, which happens before BentoBox creates its worlds.
3. Operators do not get the bypass node implicitly. An op-only test failed; the same test passed once the node was granted explicitly via LuckPerms. Anyone testing as an op will conclude the fix does not work.

Granting mvinv.bypass.world.<world> (with share-handling.enable-bypass-permissions: true) fixed it — verified from a cleared database, with InvSwitcher's own store holding the correct island contents afterwards.

Changes

Adds a Compatibility with other inventory plugins section to the InvSwitcher page, placed directly after How to use so it is found before an admin starts changing InvSwitcher settings that are not the problem. Covers the general rule, the symptom, the two misleading dead ends, and the working MV-I fix.

Verification

mkdocs build passes; the new section and both admonitions render. --strict aborts on pre-existing warnings in other pages (GitHub API 403s on the translations macro, older relative links) that are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXnYDGiASdSUZFtNyS4jbc