Hi,

I would please like to request that the "Initial size" key in dynamic profile configuration be treated more as a "minimum size" rather than actual "initial size". By that, I mean that slots given to a dynamic profile user when on dynamic profile "test_6-12" should not be lost when later giving the player dynamic profile "test_8-24" as long as their current slot count is within the range of the new profile's "Initial size" and "Max size". If their existing slot count is outside that range, then they should gain slots or lose them depending whether the new profile's minimum is greater than their current slot count or their new profile's maximum is less than their current slot count.

Allowing users to retain slots that are within the "Initial size" and "Max size" range of a dynamic profile is necessary to enable shops to offer profile upgrades. Well, not necessary, but if my starting profiles differ based on VIP status, I have to choose for my shop whether to allow players to shortcut slot purchases if they buy an upgrade before hitting max slots of their existing profile or to lose slots (because I have to set the "Initial size" to the default profile's initial size as the only means of mitigating the first issue of getting free slots).

Is this possible?

That is actually how I designed it, for initial slots to function as the minimum. For example, if the player has 6-12, and has upgraded to 12, switching to 8-24 should keep them at 12. It sounds like what you are saying is that when switching capacity profile to the latter, the size is reducing to 8.

What steps did you take to reproduce this issue? In what order were the permissions granted/revoked?

1) I set up a profile "vip-lifetimes-basic-144-144" with initial size 144 and max size 144 and granted this permission to myself
2) I filled ~92 slots of my backpack with items
3) I set up a second profile "test" with initial size 48 and max size 240 and reloaded the plugin
4) I granted myself the "test" permission

On granting the "test" permission, my backpack was reduced to 48 slots (one page), and items that were on the second page all dropped to the ground.

Also I should note I did NOT revoke the VIP privilege. I assumed that because the VIP privilege's initial size was larger than the test profile's intiial size but smaller than its maximum, this would not be a problem. Could this issue have perhaps happened because the slot count of my backpack on the VIP profile was just based on the initial size of the VIP profile and had not had any extra slots given to it?

Oh I see. Since you were at the current minimum of 144, there was no data file entry recording that you had 144, so you automatically got the initial size of the new profile. I suppose this should only happen if you switch to a profile that has a lower initial capacity that the one you came from.

WhiteThunder

Oh I see. Since you were at the current minimum of 144, there was no data file entry recording that you had 144, so you automatically got the initial size of the new profile. I suppose this should only happen if you switch to a profile that has a lower initial capacity that the one you came from.

Yeah that would do it. Would it be possible to record backpack size to a player's data when Backpacks initializes a new profile for that player if no size already exists?

Yes. When the plugin determines which profile to assign to a player, if no capacity is saved for that player, the plugin could record the initial amount at that time. I'll probably make that a configurable (toggle-able) behavior since it could result in significant data file growth over time on populated servers (though not too bad since it resets on wipe).

Isn't there a setting to make it not reset on wipe?

Another possibility is you could make permissions overlap. So if permission A gives a higher initial and permission B gives a higher max, use permission A's initial and permission B's permission max as the player's individual initial and max sizes.

This would remove the need to save the backpack size to data on new permission initialization and would give more permission-oriented control to real max and real minimum allowed for that player. Then if the data file records number of slots added rather than "size", you could always add slots added to player's determined initial to get actual.

I have no idea how much of a breaking change that would be though. :D

Currently, dynamic size always resets on wipe. Perhaps this should be configurable though, to let server owners decide the wipe schedule for dynamic capacity.

Raising the minimum/initial capacity (and possibly maximum) to the highest of all granted profiles sounds reasonable overall. It will work as long as the player maintains access to multiple profiles. It could potentially be confusing to server owners though, as it becomes more complex to estimate what size a given player's backpack will have. It also makes it harder to basically downgrade capacity, though that would be a niche use case.

Recording the number of bonus capacity, instead of the actual capacity, is an interesting idea. I will think more about it.

As for breaking changes, this feature is still experimental, so breaking changes are basically allowed, though I will do my best to mitigate them automatically (e.g., upgrade data files intelligently if applicable).

Re: saving backpack size when using dynamic profiles between wipes, oh yeah, that would be quite nice for admins to control. Would really love to see that. Maybe even having a similar setting to the normal backpack keep on wipe settings which let you specify number of slots to keep. Dyanmic profile settings to "remember" slots given via command and keep that number rolling between wipes until an admin manually wipes it would make dynamic sizes more dynamic and way cooler!

Re: overlapping permissions, I think there's already some confusion about how permissions in general work in Oxide. I see this problem all the time in systems that offer permissions alongside a role or user group system because it's never clear whether overlapping permissions will take most restrictive, most permitting, or "whichever permission loaded last" heh. IMO it would be clearer what's happening if they added since from the admin perspective, it would give a known meaning to overlapping permissions. Like in my backpack test case, I was surprised my backpack got smaller because I do still have the VIP permission.

Re: breaking changes, I'm good with breaking changes! I think these ideas would make dynamic profiles overall more useful to server admins, both for rewarding playtime and player engagement and for monetization. I appreciate you taking the time to talk through these. Thanks! :)

any chance this could happen?  I'd love the ability to save backback bonus sizes across wipes.  Would solve the upgrade issue as well.  Another cool thing would be, say my inital group was 6-24, and I ended up earning 48 upgrade slots.  I would have a capacity of 24, but say I upgraded to another profile of say, 12-48 I'd have the full 48 on upgrade since I've earned them.  Also, in a 24-96 I would have 72, or
Minimum + upgrade slots = total;
Capacity = MIN(MaxSlots, total);