# PremiumVanish tasks Task guides and troubleshooting for PremiumVanish. Check the installed release before changing configuration or data. # Check PremiumVanish layered visibility after changing staff ranks Layered visibility can let senior staff observe junior vanished staff while preserving the reverse boundary. Test the actual rank combination after a change rather than relying on broad staff inheritance. ## Follow the procedure 1. Confirm the installed PremiumVanish release and read its layered-permission instructions. The maintainer documents `LayeredSeeAndUsePermissions` alongside `pv.use.levelX` and `pv.see.levelX` nodes. 2. Write the intended relationship between two staff ranks. Record their effective use and see levels, including direct grants that may remain after a promotion or demotion. 3. Enable or review the documented layered mode without changing unrelated vanish settings. Give the test accounts only the explicit levels required by that relationship. 4. Rejoin the affected accounts where required by the release. Vanish each in turn while the other account checks visibility, then repeat from an ordinary player account. 5. Test the opposite direction deliberately. A senior account seeing a junior one does not prove the junior account cannot also see the senior one. 6. Remove the temporary trial grants and record the final rank policy. Avoid assigning `pv.*` as a shortcut because broad permissions can change how the hierarchy resolves. ## Check the result The two staff accounts should see each other only in the directions your policy allows, while the ordinary account sees neither when vanished. Keep the observed matrix with the rank configuration. Rejoining is important when a release caches visibility levels on login. ## If the result is wrong If both accounts see everything, inspect operator status, inherited permissions and the layered-mode setting. If neither sees the intended colleague, check the documented level comparison rather than guessing a higher wildcard. Restore the previous explicit levels if the hierarchy becomes less restrictive. ## References and related help - [PremiumVanish maintainer reference](https://www.spigotmc.org/threads/premiumvanish-stay-hidden-bungee-velocity-support-paid.102401/page-127) - [PremiumVanish maintainer reference](https://www.spigotmc.org/resources/premiumvanish-stay-hidden-bungee-support.14404/) - [Set up SuperVanish for a limited staff role](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/set-up-supervanish-for-a-limited-staff-role) - [Set up a Velocity network with protected backend servers](https://help.cloudexa-hosting.com/books/game-hosting/page/set-up-a-velocity-network-with-protected-backend-servers) # Verify PremiumVanish network vanish across Velocity backends A vanished state on one backend does not establish network-wide visibility. PremiumVanish’s documented network feature requires compatible proxy and backend components with the intended shared storage. ## Follow the procedure 1. Check the installed PremiumVanish release against the maintainer’s Velocity instructions. Confirm that the network-vanish command exists in that version rather than borrowing an older Bungee-only procedure. 2. List the proxy and participating backends, their plugin versions and the shared MySQL connection they are meant to use. Keep credentials out of screenshots and public logs. 3. Use read-only connection and startup logs to establish that each component reaches the intended database. Do not point unrelated servers at a shared schema merely to test visibility. 4. Give a test moderator the documented `pv.networkvanish` permission and use the release’s `/networkvanish` command. Keep ordinary observers on two participating backends. 5. Move the moderator through the public proxy between those backends. Check entity visibility, tab entries and join or switch messages from both observer accounts. 6. Reappear through the supported network control and repeat the movement. Confirm normal visibility returns across the same backend set before staff rely on the feature. ## Check the result The hidden state should follow the moderator across every backend included in the supported configuration. Record the tested proxy version and backend versions. A successful command on the proxy does not prove an omitted or disconnected backend received the state. ## If the result is wrong If one backend leaks the moderator, inspect that component’s version, shared storage and startup errors before changing permission levels. Avoid disabling backend connection protection to simplify testing. Restore the previous visibility state and use local vanish only within the verified scope until integration is corrected. ## References and related help - [PremiumVanish maintainer reference](https://www.spigotmc.org/threads/premiumvanish-stay-hidden-bungee-velocity-support-paid.102401/page-127) - [PremiumVanish maintainer reference](https://www.spigotmc.org/resources/premiumvanish-stay-hidden-bungee-support.14404/) - [Set up SuperVanish for a limited staff role](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/set-up-supervanish-for-a-limited-staff-role) - [Set up a Velocity network with protected backend servers](https://help.cloudexa-hosting.com/books/game-hosting/page/set-up-a-velocity-network-with-protected-backend-servers) # Check vanished staff interactions before a live investigation Hidden staff can still affect gameplay if their interaction settings allow it. Test the specific actions your moderators use so observing an incident does not change the evidence. ## Follow the procedure 1. Inspect the installed PremiumVanish configuration and its matching documentation for interaction controls. Identify whether your policy allows staff to open containers, break blocks, attack or pick up items while vanished. 2. Build a small disposable test area containing ordinary blocks, a counted chest and a few harmless dropped items. Keep real player possessions outside this trial. 3. Use a non-operator staff account with its actual moderation role. Enter vanish and attempt each action once while another account records visible effects. 4. Compare the actions with the intended configuration and permission bypasses. Change only the supported setting responsible for the unexpected action, not every interaction option together. 5. Repeat the restricted actions and an explicitly permitted staff action. Confirm the change prevents disruption without making the approved investigation workflow unusable. 6. Reappear and verify normal play. Record any action that requires a separate investigation tool rather than granting broader vanish permissions to make it convenient. ## Check the result The vanished account should affect the test area only in ways your staff policy permits. The chest count and block state should match the expected result. Observer invisibility alone is insufficient when an accidental pickup or block break can alter a real case. ## If the result is wrong If an action remains possible, inspect effective bypass permissions and integrations with protection plugins. Restore the trial area from its recorded state, not by rolling back unrelated player activity. Return the configuration to its previous value if the change creates unexpected normal-play restrictions. ## References and related help - [PremiumVanish maintainer reference](https://www.spigotmc.org/resources/premiumvanish-stay-hidden-bungee-support.14404/) - [PremiumVanish maintainer reference](https://www.spigotmc.org/threads/premiumvanish-stay-hidden-bungee-velocity-support-paid.102401/page-127) - [Set up SuperVanish for a limited staff role](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/set-up-supervanish-for-a-limited-staff-role) - [Set up a Velocity network with protected backend servers](https://help.cloudexa-hosting.com/books/game-hosting/page/set-up-a-velocity-network-with-protected-backend-servers) # Recognize the PremiumVanish API jar before installing an integration The public PremiumVanish API project is a development dependency, not a replacement for the licensed server plugin. Installing the wrong jar can produce a startup failure without providing vanish functionality. ## Follow the procedure 1. Read the integration developer’s installation requirements and the PremiumVanish API repository notice. Determine which jar is the actual server plugin and which is only a compile-time API artifact. 2. Open the game panel Files view and list existing vanish-related jars. Record filenames, versions and their legitimate download sources before moving anything. 3. If an API-only jar was uploaded accidentally, stop the server for a controlled correction. Keep a copy outside the plugin load directory rather than deleting unrelated plugin data. 4. Install the supported actual plugin from the authorized source, together with the integration version it supports. Do not use an unverified third-party fork as a substitute for the licensed dependency. 5. Start the server and read the first plugin-loading messages. Confirm the vanish plugin and integration both enable without a stub-API warning or missing-class error. 6. Exercise one read-only integration feature with a test account, then confirm ordinary vanish still works. Preserve the previous working jar and configuration until the check is complete.
![CloudExa game panel: server file manager](https://help.cloudexa-hosting.com/cloudexa/guides/20261108/game-files.png)
CloudExa game panel reference. This image shows the panel, not the PremiumVanish interface.
## Check the result The server should load the actual PremiumVanish plugin and the integration should find its runtime API. A jar named after an API does not establish that the feature is installed. Verify the startup result and one practical integration action before closing the maintenance task. ## If the result is wrong If class-loading errors persist, restore the matched previous plugin set and capture the first exception for the integration maintainer. Do not keep multiple versions of the same plugin in the load directory or remove configuration folders to force a clean startup. ## References and related help - [PremiumVanish maintainer reference](https://github.com/LeonMangler/PremiumVanishAPI) - [PremiumVanish maintainer reference](https://www.spigotmc.org/resources/premiumvanish-stay-hidden-bungee-support.14404/) - [Set up SuperVanish for a limited staff role](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/set-up-supervanish-for-a-limited-staff-role) - [Set up a Velocity network with protected backend servers](https://help.cloudexa-hosting.com/books/game-hosting/page/set-up-a-velocity-network-with-protected-backend-servers)