Nikedemos

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: 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!

Changed Status from Pending to Closed

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!

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

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)

In that case I would recommend you got in touch with the map creator to investigate this issue - looks like it's happening on an inland lake? This is unfortunately not something I would be able to solve with Water Bases, as this water detection is performed entirely client-side. My suspicion is that either the map creator is using the wrong prefab for the lake or there's something else going on, for example with map topology - in either case, the client side is treating this position as being under water. Out of curiosity, what's the name of the map, and who's the creator?

Howdy! Are you using a custom map, or a proocedurally generated one?

Changed Status from Pending to Closed

Changed Status from Pending to No Response

Changed Status from Pending to Closed

Sure, that sounds like a reasonable suggestion, and relatively easy to implement. Will incorporate it in the next update. Appreciate you reaching out!

Changed Status from Pending to Not a Bug

Unfortunately placing the foundations any higher would make the barrels float in the air, breaking the immersion, and allowing players to swim underneath of them (thus allowing to use raid weapons that would normally not be usable if the player was completely submerged). Statistically, half of the time the water foundation should be under the water level (allowing for deployment), and half of the time it should be over the water level. Many players build a half-floor "honeycomb" layer over the flat water foundations for raid protection reasons, anyway. Hope this helps!

Changed Status from Pending to Closed

Changed Status from Pending to Closed

Hopefully the issue is no longer present, so I'm going to close the ticket if that's okay. Messaged you on Discord to confirm, too!

Changed Status from Pending to Closed

I'm guessing everything is fine, then? If not, again, find me on DIscord, but for now, I'm going to close the ticket.

Hi there! There's no conflicts, but of course you can't convert a Water Base to a Pocket Dimension because water bases utilise regular floors instead of foundations, and foundations are required for a dimensional pocket. But you can still deploy a dimensional box inside of your water base, no issues with that! If you got any more questions, hit me up on Discord, but for now, I'll close this ticket if that's okay!

Changed Status from Pending to Closed

Hi there! This is certainly strange and unexpected. Hit me up on Discord (https://discord.nikhub.dev), or I'm available on Codefling Discord, and let's see what's up!

Changed Status from Pending to Not a Bug

Hi there! Indeed, `powerline_pole_a` it is not a spawnable entity in vanilla Rust. Custom Entities does not have the power to make any prefab existing in-game spawnable. It can only register new spawnable prefab names with custom server-side logic - but only those based on other, already existing spawnable entities. I highly encourage you to read the product page to get the full idea of its capabilities! As such, Custom Entities is a framework/dependency meant for other plugin developers, and NOT end users (server owners, admins). On its own, it doesn't do anything - only combined with dependant plugins. But even such a dependant plugin would not be able to bypass the limitations of normal Rust. Entities are special prefabs that have networking enabled both in the server and the client, so they can be spawned/moved/killed at any time. Non-entity prefabs, however, must be pre-placed on the map where they stay forever as permanent fixtures. Hope this clears any misunderstandings!

Changed Status from Pending to Not a Bug

Hi there! Thanks for your report, sorry I'm only responding now, I was out out of town this weekend. Yeah, normally players shouldn't be able to access the "soft side" of the the water foundations covered with barrels, hopefully there's no new exploits regarding that. Hit me up on Discord (https://discord.nikhub.dev, or DM me through the Codefling Discord) if you notice anything sus, since it looks like you've done some thorough testing on the underwater raiding mechanics