Nikedemos

I would definitely trust the console version rather than whatever says in your user panel. I think your user panel might be showing the latest AVAILABLE version rather than the one actually installed?

And when you type o.version in your server console, does it also show 2.0.7022 as well?

Btw I just checked my o.version: Oxide.Rust Version: 2.0.7022 Oxide.Rust Branch: master So it looks like your Rust Server is up to date, but not your Oxide installation. @moulinch you said your o.version is: Oxide. Rust Version: 2.0.7008 Which seems out of date (should be 2.0.7022) I think this must be the answer right here. Have you tried manually forcing the install of latest Oxide build?

This is utterly bizarre and honestly I'm flabbergasted. I tested both 1.0.18 and 1.0.19 on Oxide and Carbon and 1.0.19 compiles fine. On 1.0.18 I get this message: [CSharp] Started Oxide.Compiler v successfully Error while compiling CustomEntities: 'CustomEntities.CustomBaseEntity' does not implement interface member 'CustomEntities.ICustomEntity.Kill(BaseNetworkable.DestroyMode)' | Line: 2829, Pos: 53 I guess we'll have to wait for the next Rust server update and see which version works then

Here's the 1.0.18 version - does it compile for you both? https://www.dropbox.com/scl/fi/xgbjgynpiwauovxz481ea/CustomEntities.cs?rlkey=nkyvcnkw8kfavx0uyu1rj6mva&st=68pkisbi&dl=1 @LeDonjon59 do you also have Oxide by any chance?

Changed Status from Pending to Fixed Changed Fixed In to 1.0.23

Thanks for reporting the issue! Sorry it took me a while until I figured out what was wrong. Pushed out the 1.0.23 update to address this. Turns out, Ghost Ships are just larger Junkpiles - who knew!

Yeah looks identical to mine. Honestly I have no idea why it doesn't compile on your server and it does on mine. So what about version 1.0.18? Does that one compile for you?

Ah, I had no clue Oxide didn't print the game protocol version as well - but you can check that with the `version` command. Mine is Protocol: 2621.281.1 Build Date: 02/08/2026 19:24:07 Unity Version: 2022.3.41x1 Changeset: 142893 Branch: release What about yours?

Weird, it compiles just fine on my test server. Do you have Carbon installed? Could you please check the version with the `c.version` command? Here's mine for comparison Carbon 2.0.232.0/linux/2026.02.05.1 [production] [production_build] on Rust 988/2621.281.1 (02/08/2026 19:24:07)

The 1.0.19 version was for the Hotfix 5 update earlier today released by FP. Is your Rust server up to date?

Changed Fixed In to 1.0.19

Changed Status from Pending to Closed

Hi there! Thanks for reporting the issue. The 1.0.19 fix has been released on GitHub and Codefling, give it a go!

Changed Status from Pending to Not a Bug

Hi there! Yes it's possible to disable all the Power Line poles, although this is the main functionality of the plugin and the reason people purchase it! However, if you're sure, what you need to do, in order: 1) Load GridPower 2) Type the command `gp_emergency_cleanup` in the server/RCON console 3) You will see a message informing you about removing all the Power Line entities 4) Unload GridPower completely (NOT reload) 5) Edit your /config/GridPower.json file and set `GeneratorChancePowerlineFunctional` to `0.0` (as opposed to default 0.33), save the config file 6) Delete your /data/GridPower.json file completely from the server 7) Load GridPower After you load, no Power Lines will become usable, and won't allow players to connect to them. You can then look at each pole and use the command `/gp_pole add` to manually make them functional, or `/gp_pole remove` to disable them. Now to your second question: the streetlights becoming active (i.e. actually producing light) rely on the generated map itself. EVERY SINGLE pole on the map that has the static streetlights prefab on them will start shining - no more, no less. Which poles have the static streetlights, and which don't, relies on the vanilla random map generation which cannot be controlled by a plugin. The only way to increase the number of poles that have those streetlight "extensions" on top, and thus allowing too shine, is to create your own custom map and explicitly utilising the appropriate prefabs. There's also no way to change the intensity/size of the lights produced by Grid Power, as modding is purely server-sided and we rely on entities existing in-game that we spawn. We can't really change the properties of those entities. Hope this helps!

Hi there! Thanks for reporting. Sadly this doesn't tell me much, it's a generic hook error with many possible causes. Please hit me up on Discord and let's see what's going on! You can find me on the Codefling Discord or you can join mine at https://discord.nikhub.dev - make sure you quote your CF username and the purchase date to get verified!

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?