VIP Permission Issue – Custom VIP2–VIP5 Functions Not Recognized in Upgrade Hook

Hello Nikedemos,

I’m running into an issue with the WaterBases plugin after extending it to support additional VIP levels.

Issue Summary
- VIP1 permissions work perfectly for upgrades.
- I added custom VIP levels (vip2, vip3, vip4, vip5) in both the config and the main plugin code.
- Despite this, the OnStructureUpgrade hook only recognizes: default, waterbases.vip1, and waterbases.admin.
- My custom permissions (waterbases.vip2, waterbases.vip3, etc.) are being ignored, preventing upgrades for those users.

What I’ve Modified
- Added full permission profile handling for VIP2–VIP5 in the C# plugin code.

private void ProcessConfigData(string versionFromConfig)
        {
            ///
            ////
            {
                /////
                {
                    ///
                    ///
                    ///
                    [PERM_VIP2] = VIP2PermissionProfile(),
                    [PERM_VIP3] = VIP3PermissionProfile(),
                    [PERM_VIP4] = VIP4PermissionProfile(),
                    [PERM_VIP5] = VIP5PermissionProfile(),
                };
               ///
            }
///
///
///
private PermissionProfile VIP3PermissionProfile()
        {
            return new PermissionProfile
            {
                PermissionRequired = PERM_VIP3,
               /////
            };
        }

- Extended the permission checking system to account for the new levels.
- Updated all relevant functions to recognize these extra VIP levels.
- Created JSON config profiles for each VIP level with correct permission names.

What I’ve Verified / Tried
- All code changes compile correctly (no syntax errors).
- JSON syntax is valid (checked commas/brackets).
- Reloaded the plugin.
- Confirmed permissions exist and are properly granted (oxide.grant shows them assigned).
- VIP1 and admin permissions work fine; VIP2–VIP5 remain unrecognized.

Suspected Problem
The issue may lie in the GetPermissionProfile method (or related permission iteration logic). It looks like the plugin may not properly handle dynamically added permission profiles beyond the original set, even when the code has been extended. There may be a hardcoded limitation or a specific naming/pattern requirement that prevents VIP2–VIP5 from being registered.

Environment
- WaterBases Version: 1.0.21 (with custom modifications for VIP2–VIP5)
- Rust Server Version: Protocol 2594.270.1 (Build Date: 08/28/2025 22:22:54, Unity 2022.3.41f1, Changeset 129647, Branch: release)
- Oxide Version: 2.0.6553 , Oxide.Rust Branch: master

Could you please review this and advise why the system isn’t recognizing custom-added VIP levels?

Thank you for your excellent work on this plugin!

Hi there!

Thank you for your extensive description of the issue.

What I suspect is happening here: according to the GetPermissionProfile logic, once a matching granted permission for a user is found, it's going to default to that one. So if a user that the permission is being checked for as a "waterbases.vip1" granted, it will not check if they have "vip2", "vip3" etc, it will just default to the first one found, without performing further checks.

Would you please test this theory by having yourself (or another player) WITHOUT the admin/vip1 permission (oxide.revoke user [name] waterbases.vip1) and then granting them one of the remaining unrecognised permissions?

In any case, I think it would be best to discuss this/test on Discord, I'm present in the Codefling server, or hit me up on my tech support one: https://discord.nikhub.dev)
 

Oh and also remember to revoke the group permission for that user, if applicable!

Well, it was done successfully after adding Vip2-5 in the configuration file only and revoke perms and giving only one perm for each VIP level. In fact, I had no idea, despite reading the plugin description, that only one permission should be given. I thought that the higher perm overrides the lower perm, and this is what I look forward to in the upcoming code updates.

thank you again.

Hello again,

The issue with introducing any sorting based on priority here is deciding which tier is "higher" and which is "lower"! Some server owners treat "vip1" as "the best", some treat it as "the worst". Hence I decided on the compromise, i.e. there's no "alphabetical" or rather "alpha-numerical" sorting;  the first item on the list is the first granted. If you'd like your Vip5 to take precedence over Vip4, Vip3 etc, I'd suggest swapping their order in your config file so that "admin" comes first, then Vip5, then Vip4 etc.

That way, each server owner can decide which permissions take precedence over which, i.e. the sorting order.

The "default" profile is not a permission, but a fallback to when the user hasn't got any admin/vip permissions, so its position in the order doesn't matter.

Hope that helps!

Changed Status from Pending to Closed

It was just an idea if it doesn't work there seems to be a reason for that.. I suggest adding the description of the plugin that only one perm should be given if possible.

To my knowledge, everything is working as expected, i.e. there's a good reason why precedence is decided in the way it is right now (i.e. based on the order in the config file).

I also already explain the precedence in the section "Permission Profiles" in the product description:
 

Quote

To check which permission profile the player should fall under, the plugin goes through all permission profiles and checks whether the player has that permission granted. The permissions are checked in order, meaning that if the player doesn't have the first permission, it will try the next permission on the list, etc (similar to how Auto Kits checks which kit to give to a player based on their permissions in order). If the player doesn't have any permissions from the list granted, they will fall back to the "default" profile.

Would you have any suggestions on how to re-phrase this better, or perhaps add some additional info so that there's no doubt about how the permission profile precedence works? My goal here is to avoid any confusion in the future. I wrote this several years ago without perhaps fully realising that it might not be obvious to everyone.

In any case, I appreciate your idea, and I will try to workshop some sort of a solution, like an extra config value that will help determine the precedence "sorting", for instance "by config order", "ascending order", "descending order".

Oh and good luck with the wipe tomorrow!