Request for an optional 'player-limit'
KillaNilla opened this issue ยท 3 comments
As copied from the dev.bukkit.org page:
My understanding of the limit system in PreciousStones (as on the wiki) is that you can create groups that can place certain Pstones (and certain amounts of those Pstones).
But the problem is, when considering the fact that Pstones placed don't deactivate (even the player who placed them lost permission to place them), it is possible for this to occur:
PlayerA is in GroupA which can place 3 God Stones. PlayerA places 3 God Stones, then switches permission groups (I run a permission based class system) to GroupB, which can place 3 Shocker [stones]. PlayerA places 3 Shocker stones, and while he doesn't have permission to place God Stones, he now has 3 active shocker stones and 3 active god stones.
If there was an (optional) per-player limit in the config, (set to 3 in this example) PlayerA would have to destroy some of his God Stones before he could place any Shocker stones. While it's not a completely perfect solution, it's simple and would prevent hoarding of Pstones.
I know this isn't a feature the majority of Pstone users need, but I think it might be a nice optional setting which would add a little more configurability to the plugin.
(Of course, please correct me if I'm wrong and this feature already exists/the same desired effect can be achieved differently)
Just curious, if these are custom blocks, have you tried adding (in addition to limits) the permission node flag, where you can define permissions per block?
I'm curious because if this then makes the blocks "orphaned" you can type the PS command to delete orphaned blocks. You could even add a negative node after setting the flag, so the user doesn't benefit from the block (which doesn't solve the shocker given it's an offensive block).
Your idea does work as an alternative solution pretty well, albeit a little inconvenient especially when you have a lot of players using Pstones (and therefore in this case a lot of orphaned blocks).
However, a simple (optional) 'per-player' parameter would be a lot more powerful and convenient, and I can imagine it having uses beyond my specific situation.
