Nikedemos

Grid Power rust plugin allows players to harness electricity directly from the Power Grid on any map by climbing Power line Poles to upgrade Transformers with components and protect their grid section, while also enhancing vanilla visuals with realistic, adjustable slack on hanging wires and lights. Questions? Support? Join the discord: https://discord.nikhub.dev In short Draw electricity straight from the Power Grid in Rust - on any map, be it a procedurally generated or a custom one! Ladder up the Power line Poles to upgrade their Transformers with components like Root Combiners (to replace missing/stolen/destroyed outlets that you plug into) and Tech Trash (to permanently upgrade power output level, up to a configurable point). Maintain the service with long-lasting Fuses. But most importantly, protect your precious part of the grid from vandalism, theft and sabotage that will inevitably come from those jealous players! Whatever you do, just be careful up there... high voltage happens to be highly dangerous. Always wear protective gear (like a hazmat suit) and don't touch the wires while they're live! As a bonus, this plugin also improves vanilla visuals with realistically hanging wires / hoses / Xmas lights, the slack of which (how loose they appear to be hanging) can be adjusted while placing. And this feature is completely optional, too. Goodbye, straight lines that look like steel rods - hello, actual laws of physics! But don't take my word for it - let the video speak for itself: Still not convinced? Check out this in-depth, 20+ minutes long review and tutorial by srtbull! 1.0.2 UPDATE: Introducing working Street Lights for eligible poles! The lights go on between between 20:00 and 8:00 by default. Quick start (for admins) Upload the GridPower.cs file to your oxide/plugins folder and you should be good to go, it's all plug-and-play. No need to restart your server! If you're loading it for the first time or it's a new map wipe, the plugin will automatically locate all Power Line Prefabs on your map, randomly choose some of them (according to chances set in the default config) and attach extra electrical entities to them to make them functional. Those entities should persist throughout the wipe and will be replaced if missing, on every plugin reload/server restart. Each Power line Pole will be assigned a number and its position will be stored in the data. This will work on any map that contains at least one of the following prefabs: assets/bundled/prefabs/autospawn/decor/powerline-small/powerline_pole_a.prefab assets/content/props/powerline_poles/powerline_pole_a.prefab Quick start (for players) Locating functional Transformers Not all Power Line Poles were made equally. Only a percentage of them (by default, 33% on average) will be functional. How do you recognise a functional one? Look up - if you see a Button attached to the top of the Pole, and maybe even some pre-existing Root Combiner Outlets, that's it! [insert image here, maybe a player looking at a powerline pole with binoculars] Laddering Up Now that you have located a functional pole, you need to climb it. Normally you cannot deploy Ladders on Power Line Poles and many other places (but oddly enough, you CAN deploy them on the horizontal planks at the top of a Pole!). However, Grid Power re-implements all the client-sided deployment logic to allow bypassing of that arbitrary-seeming limitation. If you try to deploy a Ladder on a Power Line Pole, don't be discouraged by the fact that the "ghost guide" is red instead of blue/amber. Click anyway and it will force it through! Ignore the message in the chat saying that the deployment failed - just like the colour of the ghost guide, it's all client-sided and as such there's nothing the plugin can do about it, visually speaking. But trust me, everything works as intended, despite what the client messages are telling you. The Ladders can then be destroyed/picked up to be reused. Maintenance A Transformer can have up to 4 Outlets (Root Combiners). That's where the players draw the electricity from. Those Root Combiners can be damaged/destroyed/repaired/picked up with a hammer (if you have Building Privilege) any time. If there's less than 4 Outlets, right-click on a Root Combiner Item in your inventory or drag it into the Fuse Box of the Transformer. You will hear a deployment effect and the Root Combiner will be deployed on the pole. In order to be able to draw power from that Transformer, you need to put a Fuse inside. Right-click a Fuse in your inventory or drag it directly to the Fuse Box. Don't worry - inside of the Transformers, those Fuses will last for much, MUCH longer than inside regular monument Fuse Boxes. By default, a brand new Fuse inside of a Transformer Fuse Box will last you for 12000 seconds (= 200 minutes, = 3.33 hours). This value can be increased or decreased in the config. You can see how much time a fuse has left in the Transformer GUI. By default, the Power Grid will produce electricity between 8 AM and 8 PM. The power output will follow a smooth curve, being the lowest in the morning/evening, and peaking at 2 PM. Exactly how much RWs will be produced on each Outlet is determined by the Transformer's Tech Trash level. By default, each Tech Trash inserted increases the peak power output by 5 RWs (up until a certain point - by default, that level is capped at 50, which translates to 250 RWs per Outlet at peak hours). Upgrade the level by right-clicking the Tech Trash item in your inventory or dragging it directly into the Fuse Box. Inserting Root Combiners/Tech Trash is still possible even if there's already a Fuse inside of the Fuse Box. The Fuse won't be replaced as the sole Item in the slot, since Root Combiners/Tech Trash are consumed immediately. Hooking Up & Hanging Out Once there's at least 1 Outlet present, you have a Fuse at hand, and the Grid is currently producing power - you're all set. Take a Wire Tool, pick your favourite wire colour with the [RELOAD] button, typically R, and connect to the outputs of the Root Combiner Outlets to your own electrical devices, usually a Battery or another Root Combiner. You will notice the text on top of your screen telling you what the current Slack of your wire tool / hose tool is. You can increase it with the [DUCK] button, typically CTRL, and decrease it with the [SPRINT] button, typically SHIFT. Larger Slack value means that the wire/hose will appear to be hanging more loosely. Smaller values will make it look tighter. Values close to zero will make it look like they look in vanilla Rust - i.e. not so good in comparison The final Slack value will be applied the moment you finalise your wire/hose connection. This hanging improvement applies to anything you do with Wire Tools/Hose Tools, not just Transformer Outlet connections! For the Advanced Xmas Lights, it's even better: you can adjust the Slack of each segment individually! After you place the Advanced Xmas Lights segment down, and you're just about to place the next segment, adjust the Slack of the segment you have just placed down with [DUCK] and [SPRINT] buttons. You will see a preview of what it will make the segment look like. Placing the next segment down confirms the Slack for the segment before it. Danger! High Voltage! If the Grid is currently producing Power (by default, during daytime) AND a Fuse is inserted in the Transformer, all Root Combiner Outlets are considered live on that Transformer. You can tell whether a Transformer is live or not: first, check your electric devices plugged in directly to the Grid. If they're not currently receiving any charge, they're not live. Similarly, you can look at the diodes on the Root Combiner Outlets. If they're not on, the Transformer is not live either. Lastly, it's pretty clear from the Transformer GUI. If a player tries to connect/disconnect a wire to/from a live Outlet, or they're trying to pick up the Root Combiner Outlet with a hammer, and they're not wearing one of the items on a pre-approved list (see the Advanced Config section below), there is a 1.0 (100%) chance they will get electrocuted to death. Another way to guarantee electrocution is trying to clear connections named INTERNAL. Leave those alone! Wearing protective clothing reduces that chance to 1 in 10 (10%, according to the default permission profile - see below). You can set that chance to 0.0 (0%) if you want to give your players a peace of mind. Another way to guarantee 0% electrocution chance is making sure the Transformer is not live: either wait for the Grid to stop producing Power or take out the Fuse before doing anything else. Permissions (Oxide.Grant user YourName [permission name starting with gridpower.]) By default, the plugin generates 3 permission profiles in the config - one for admins, one for normal players with no specific permissions (default) and one for VIP. More on permission profiles and config values they can handle can be found in the section Advanced Config. Unless you have added more permission profiles, only these two below are going to be used by your config: gridpower.admin Holders of the admin permission will also be able to run the /gp_cfg and /gp_emergency_cleanup commands gridpower.vip1 Holders of this permission will follow settings and limits associated with with that permission profile. The permissions below are also registered, but not used by default. To use them, just create some permission profiles with those permissions as the key. gridpower.vip2 gridpower.vip3 gridpower.vip4 gridpower.vip5 Automatic street lights Depending on your map design, some power line poles might have lamps on them. All those lamps will now emit light, by default between 20:00 an 8:00, which just so happens to be the time when the grid production goes back to 0. You can also set the street lights to be always on, regardless of the time of day. The time settings for the street lights are independent of your power production time settings - they can overlap, one can start before midnight and end after midnight while the other one does not, etc. Those street lights will work even on non-functional power line poles, e.g those without a button on top of them. When on, the lights will flicker from time to time. How often they will flicker and how long individual flickers are going to be depends on your config - look below. Admin F1 console/chat commands (must have ownerid/moderatorid/gridpower.admin permission) If you're typing those commands from the F1 console or the server console, drop the preceding slash in the command name. /gp_cfg Will allow the admins to change non-permission profile related config values on the fly (see below) /gp_emergency_cleanup Instantly kills all the plugin-related entities: fuseboxes, admin generators, root combiners and buttons. It won't remove the power line entries in your data, however. All the killed entities will be re-generated according to your current generation settings in the config next time your server restarts or the plugin reloads. If you want to permanently get rid of them, unload the plugin, delete your oxide/data/GridPower.json, and load it back in. /gp_pole [add/remove] This command will allow admins to add or remove functional power line poles at any time. Just look directly at the pole you want to modify and type the command with an argument (either "add" or "remove", depending on what you want to achieve). If you want to add a pole and it already is functional, or if you want to remove a pole, but it isn't functional - you will get a warning. Same if you try to add a pole, but the pole you're looking at is building blocked by a nearby monument. "Ent killing" (or using a plugin like Remover) the power line fusebox is the equivalent of permanently removing it from the data and it won't be re-generated any more on next reload. Wiping your save file also automatically removes all the extra components and replaces them with new ones tailored to your map, in accordance to your generation settings. Configuration (oxide/config/GridPower.json and /gp_cfg console/chat command) Vast majority of the settings can be configured with the /gp_cfg chat command. Typing it in the chat/console with no parameters should dump a rundown of config fields and their values. In order to run any of the config commands, you will need to have ownerid or moderatorid (or the gridpower.admin permission). /gp_cfg GridConstantPower [logical values (true or false)] If set to true, the Grid will always produce electricity at its peak (100%), 24 hours a day (DEFAULT: false) /gp_cfg GridProductionStartAtHour [fractions (like 13.37) between 0.00 and 24.00] The hour of the day when the power production starts climbing up from 0 (DEFAULT: 8.0) /gp_cfg GridProductionEndAtHour [fractions (like 0.69, nice) between 0.00 and 24.00] The hour of the day when the power production settles back at 0 (DEFAULT: 20.0) /gp_cfg StreetlightsConstantPower [logical values (true or false)] If set to true, the Streetlights will be on 24 hours a day. (DEFAULT: FALSE) /gp_cfg StreetlightsTurnOnAtHour [fractions (like 20.4) between 0.00 and 24.00] The hour of the day when the street lights turn on (DEFAULT: 20.0) /gp_cfg StreetlightsTurnOffAtHour [fractions (like 8.2) between 0.00 and 24.00] The hour of the day when the street lights turn off (DEFAULT: 8.0) /gp_cfg StreetlightsReliability [fractions (like 0.5) between 0.00 and 1.00] The reliability of the streetlight. The less it is, the more often it will flicker. At 1, which represents 100%, it never flickers. (DEFAULT: 0.95) /gp_cfg StreetlightsFlickerLengthMin [fractions (like 1.2) between 0.00 and Positive Infinity] The minimum random length of the flicker, in seconds (DEFAULT: 0.1) /gp_cfg StreetlightsFlickerLengthMax [fractions (like 2.4) between 0.00 and Positive Infinity] The maximum random length of the flicker, in seconds (DEFAULT: 0.5) /gp_cfg GeneratorChancePowerlineFunctional [fractions (like 0.5) between 0.00 and 1.00] The chance that a valid Power Line Pole will be made functional during generation. (DEFAULT: 0.33) /gp_cfg FuseRequired [logical values (true or false)] If set to false, the Transformers won't need Fuses to produce power, just the right time of the day (if power is not 24/7) (DEFAULT: TRUE) /gp_cfg BuildingBlockPreventsButtonPress [logical values (true or false)] If set to true, if there's any Tool Cupboards in the range of the Transformer, you need to be authorised on all of them to open the Transformer GUI (DEFAULT: TRUE) /gp_cfg GeneratorInitialLevelMin [integers (like 7) between 0 and 1000] The lower limit for the random Tech Trash level of valid Power Line Poles during generation (DEFAULT: 1) /gp_cfg GeneratorInitialLevelMax [integers (like 7) between 0 and 1000] The upper limit for the random Tech Trash level of valid Power Line Poles during generation (DEFAULT: 5) /gp_cfg GeneratorInitialOutletsMin [integers (like 1) between 0 and 4] The lower limit for the random number of Outlets of valid Power Line Poles during generation (DEFAULT: 0) /gp_cfg GeneratorInitialOutletsMax [integers (like 3) between 0 and 4] The upper limit for the random number of Outlets of valid Power Line Poles during generation (DEFAULT: 4) /gp_cfg PowerlinePowerPerTechTrash [integers (like 7) between 0 and 1000] How much RWs at peak hours are provided per 1 Tech Trash Level upgrade (DEFAULT: 5) /gp_cfg PowerlineMaxTechTrashLevel [integers (like 7) between 0 and 1000] The maximum level that a Transformer can be upgraded to (DEFAULT: 50) /gp_cfg PowerlineFuseDurationSeconds [fractions (like 420.69, nice) between 0.0 and Infinity] How long (in seconds) a brand new Fuse inserted in the Transformer Fusebox will last (DEFAULT: 12000.0) /gp_cfg FuseItemShortname [strings (like "fuse")] The shortname of the item that acts as the Fuse for Transformer Fuseboxes, must be a valid Rust item shortname /gp_cfg FuseItemGuiName [strings (like "Transformer Fuse")] The custom GUI display name of the item that acts as the Fuse for Transformer Fuseboxes, can be anything, or left blank for default /gp_cfg FuseItemSkinID [positive long integers (like 2783151202)] The skin ID of the Fuse item if using custom, leave at 0 to accept any items of the shortname specified by FuseItemShortname Protective clothing (only editable through oxide/config/GridPower.json) "ProtectiveClothing": { "hazmatsuit": null, "scientistsuit_heavy": null, "hazmatsuit_scientist": null, "hazmatsuit_scientist_peacekeeper": null, "hazmatsuit.spacesuit": null, "boots.frog": null, "hazmatsuit.nomadsuit": null, "pants": [ 1581896222 ], "hoodie": [ 1581890527, 1582492745 ] }, Each entry has a key (the item shortname in quotes) and a value. If the value is null, it means all possible skins for that item shortname are accepted. In the example above, we're allowing all rubbery one-pieces (value is null, so any skin) and we're also allowing pants with 1 possible skin or a hoodie with 2 possible skins to be treated as protective clothing. You will see that there's no comma after the last entry on the list. BEFORE SAVING, ALWAYS VALIDATE YOUR JSON WITH A TOOL LIKE JSON LINT! Permission profiles Using profiles you can quickly create/edit different permissions for different players, for example, if you have more than 1 VIP tier on your server - just add some new profiles. Different players can have different limits and permissions associated with using the Power Grid. 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. That's the only one that you shouldn't remove! If you remove it, a new one with default values will be created. So if you don't want your default, non-VIP players to use the power grid, don't remove the default profile, just take away privileges in that profile (like upgrading/deploying ladders/pressing the button). You don't have to use the built-in VIP permissions - any REGISTERED permission from any plugin will do just fine! By default, three permission profiles are generate in the config: default, gridpower.admin and gridpower.vip1. The default permission profile will apply to any player who doesn't have any permissions listed in the profile list - let's have a look at it: "PermissionProfiles": { "default": { "PermissionRequired": "default", "GridCanDeployLadder": true, "GridCanDeployRootCombiners": true, "GridCanConnectDisconnect": true, "GridCanPressButton": true, "GridCanUpgrade": true, "GridDangerousWireElectricutionChance": 0.1, "HangingXmasLights": false, "HangingWiresAndHoses": false, "SubdivisionsPreview": 10, "SubdivisionsFinal": 50, "SlackMax": 5.0 }, PermissionRequired should contain an already existing permission registered by any plugin in the form of pluginname.permissionname GridCanDeployLadder allows players to deploy ladders on Power Line Poles GridCanDeployRootCombiners allows players to deploy Root Combiners on Power Line Pole transformers by inserting them into the Fuse Box GridCanConnectDisconnect allows players to use a Wire Tool to connect their own electrical devices to the Grid GridCanPressButton allows players to access the Transformer GUI GridCanUpgrade allows the players to upgrade the Transformer peak output by inserting Tech Trash into the Fuse Box GridDangerousWireElectricutionChance defines how likely it is that a player will die from electrical accidents, even while wearing protective clothing HangingXmasLights allows the players more control over how much the Advanced Xmas Lights will be hanging (purely visual) HangingWiresAndHoses allows the players more control over how much the Wires/Hoses will be hanging (purely visual) SubdivisionsPreview is the number of intermediary points used while showing the hanging Xmas Lights preview catenary curve of the last placed segment. The more points, the smoother it looks. (purely visual) SubdivisionsFinal is it the number of intermediary points used for the final catenary curve of the hanging wires/hoses/xmas lights. The more points, the smoother it looks (purely visual) SlackMax sets the maximum "looseness" of the wire/hose/xmas lights that the player is allowed. The more the slack, the longer the wire appears overall. API hooks (for plugin developers) All methods utilise the [HookMethod] attribute, which means you don't call them through Interface.Call, you need to first create this field in your plugin's main class... [PluginReference] private Plugin GridPower; Then, call the hooks like so. It's pretty self-explanatory what information they will provide you with. bool isPowerConstant = (bool) GridPower.Call("GridPowerIsConstant"); bool isGridProducing = (bool) GridPower.Call("GridIsProducing"); float productionHourStart = (float) GridPower.Call("GridGetProductionHourStart"); float productionHourEnd = (float) GridPower.Call("GridGetProductionHourEnd"); float currentGridEfficiency = (float) GridPower.Call("GridGetEfficiency"); bool areStreetlightsAlwaysOn = (bool) GridPower.Call("StreetlightsPowerIsConstant"); bool areStreetlightsOn = (bool) GridPower.Call("StreetlightsAreOn"); float streetlightsHourStart = (float) GridPower.Call("StreetlightsGetTurnOnHour"); float streetlightsHourEnd = (float) GridPower.Call("StreetlightsGetTurnOffHour"); Translation support (oxide/lang/en/GridPower.json) Almost every string the players see, including the text displaying in the chat and the GUI, can be edited. Just load the plugin and let it generate the file - after you edit it, reload the plugin.

Water Bases rust plugin enables players with permissions to construct and expand structures on and underwater without the need for pillars, incorporating vanilla-like mechanics, special features like underwater nettings, and customizable settings for different player tiers. Questions? Support? Join the discord: https://discord.nikhub.dev In short This Rust plugin enables players with the right permissions to construct structures on the water's surface and even extend them below water in a way that feels natural and in keeping with the game's original style. There's no need for tall, unstable pillars reaching down to the seabed; simply place your foundation on the water and use a building plan or hammer to expand it. These aquatic constructions adhere to the same principles of stability, upkeep, and decay as traditional bases on your server but also introduce unique elements like underwater nettings for gathering random items (with fully customizable loot tables) and innovative building techniques. The plugin accommodates various configuration profiles based on permissions, offering an excellent method to reward VIP players across different levels. It grants you control over who is allowed to build on the water, the size of their constructions, their proximity to the shore, and the highest tier of building blocks they can use, among other aspects. Additionally, the plugin is designed to alert players if their construction interferes with the Cargo Ship's route. With the Submarine update on the horizon, it's time to prepare your server for aquatic adventures with Water Bases! Watch the video below to see what water bases are all about. "What about Cargo Ship, will it destroy structures in the way?" By default, players will get a warning if they try to to build a water foundation in the path of the cargo ship, but their water foundation will stay. You can change this setting from "Warn" to "Prevent", and the player won't be able to build it in first place. Changing it to "None" will skip this check. Every ocean path node creates a "bubble" with a configurable radius. See Admin chat commands section below to visualise those bubbles and guide your players to areas where they will be able to build without issues. Quick start (for players and admins) Upload the WaterBases.cs file to your oxide/plugins folder and you should be good to go, it's all plug-and-play. No need to restart your server! Before you can build on water, you need some Water Foundations. Water foundations are re-skinned Inner Tube items (Shortname: innertube / Item ID: -697981032 ; mind the minus sign, it matters!) with a skin ID 2484982352 (https://steamcommunity.com/sharedfiles/filedetails/?id=2484982352) or 2485021365 (https://steamcommunity.com/sharedfiles/filedetails/?id=2485021365). That info is just in case you'd like to include those in your own Kits/Server Rewards shops/loot tables/custom crafting plugins. How to obtain those within the plugin? Crafting water base foundations (with Building Planner) By default, all players will be able to craft, deploy, expand and reinforce water foundations. More on the limits and how to change them (how far/close to the shore, min and max depth of the water, how many water foundations allowed per building etc) in the section Advanced Config. When a player equips a Building Plan, a small GUI will show in the bottom right (positions/colours etc can be changed in the config too). There, players will be able to craft deployable water foundations - both square and triangle. Those crafted items will also be consumed when players expand their already deployed foundations or reinforce them. The default permission profile requires a player to be close to a Level 2 Workbench - this requirement can be edited in the config to change the level needed, or you can turn off the need for a workbench altogether, per permission profile. If you don't want your players to be able to craft foundations - so they have to find them/buy them/earn them instead - you can disable it per-profile. In that case, they won't see the GUI. Giving with chat commands (admins only) Type /give_square [amount] or /give_triangle [amount] to give yourself some foundations of that type. If you don't specify an amount, you will only receive 1. Deploying a "starter" foundation on water Go out to the lake/ocean, select the water foundation as your active item and using the doughnut-shaped guide, deploy it on the water surface. After trying to deploy/expand upon an existing water foundation, a couple of checks will be performed according to global config and individual permission profile for that player: Does the player have permission to deploy the first foundation/expand existing one? Is the player building blocked? How far is the player trying to build from shore (based on the map topology)? Too close/too far? How deep is the water where the player is trying to build? Is it too deep/too shallow? Is the player trying to build too close to the path of cargo/Oil Rig? Is the player allowed to have this many water foundations in the building? If all the checks have been successful, a new twig floor, with a stability 100% (like normal foundations) will be built. It will have some indestructible floatation barrels attached to it, partially covering the water foundation's soft side (the bottom). Then, a water foundation can be expanded, upgraded, protected with a Tool Cupboard (like any other buildings, really), or reinforced. Expanding Once you've deployed your first "starter" water foundation, all the subsequent foundations will be placed using vanilla building mechanics - just take a building plan and build some floors neighbouring your water foundation on the sides! If you have enough water foundation items of the required kind in your inventory, those newly placed floors will also turn into water foundations. And they can call be demolished/upgraded, just like normal twig structures, as soon as you place a Tool Cupboard. Expanding a single-sided water foundation requires 1 proper water foundation item, expanding a double sided water foundation (reinforced one) requires two. Reinforcing Reinforcing a water foundation means making it double sided - so it fully covers the soft side AND gives you the ability to build from the surface down, to the seabed/lakebed! To reinforce, make sure a built water foundation is fully repaired, and them hit it with a hammer. If you have a required water foundation item in your inventory, it will be consumed and the foundation will be reinforced: you will see another floor with floatation barrels attached upside down. If you try to expand a reinforced foundation (by attaching a floor at the bottom, reinforced side) and there's no water foundation above it (normal orientation), it will try to create one, provided you have enough items in your inventory. Reinforcements (upside down water foundations) are always associated with the water foundation they're attached to and cannot exist on their own - if you destroy the water foundation, its reinforcement will be destroyed too. However, destroying the reinforcement will not destroy is water foundation. Upgrading Water base structures Building blocks inside your water bases have certain tier limits associated with them - it's to help balance things out. By default, non-VIP and non-admin players will be able to upgrade water foundations to sheet metal tier, floor frames and wall frames to stone tier, and everything else (including walls, floors and reinforcement foundations) to wood tier. You can easily decide which permission profile has which max tier (per type of building block) in the config. Water Base exclusive features Because water foundations are treated as floors with the stability of a foundation, you can place roofs at "ground level", which is not possible with normal foundations! Similarly, you can leave a "hole" where a water foundation would be and place a floor frame with a hatch instead - now you can enter your base from the bottom, underwater! Reinforcing a water foundation means you'll be able to build down from the surface to the bottom of the water to create extra layers of protection, or... Nettings deployed in wall frames underwater will collect random junk items with editable loot tables, including fish and diving equipment! This feature is heavily configurable and can even be disabled. But also Sharks! Read just below. NEW IN 1.0.5: Beware the Netting Sharks! If enabled, Sharks will randomly spawn around Nettings underwater. Especially ones that have accumulated a lot of items, but only if there's at least 1 player within the distance of 100 meters from the Netting. As soon as the first item is caught in an empty Netting, a random silent timer will be set. Every additional item spawning reduces the timer left by a certain percentage (default by 8%). When it hits 0, AND local/global Netting Shark population limits haven't yet been reached (all in the config), a Shark will spawn somewhere near that Netting. The sharks have a configurable aggro distance and multipliers for speed and health. They will linger around the position of the netting that attracted them and try to pursue anyone in sight. Harvesting a Netting Shark corpse with a proper tool will yield some free items from its entrails - by default 5 times more than you'd normally get from a netting full of items from the default loot tables. Of course the default Shark loot tables in the config are, just like the Netting loot tables, completely configurable - check the config section below. All in all, it's like any other base... just on water, without annoying seafloor supports. The stability of the water foundation is always 100% and goes down the higher you built. The stability of a reinforcement foundation also starts at 100% and goes down the deeper towards the seafloor you build. All the decaying things (walls, floors, doors etc) will require appropriate upkeep materials in the Tool Cupboard. Structures can be repaired, demolished, upgraded and removed using plugins. Bases can be raided, taken over or left to decay. Water Bases Permissions (Oxide.Grant user YourName [permission name starting with waterbases.]) By default, the plugin generates 3 permission profiles in the config - one for admins, one for normal players with no specific permissions (default) and one for VIP. More on permission profiles and config values they can handle can be found in the section Advanced Config. Unless you have added more permission profiles, only these two below are going to be used by your config: waterbases.admin Holders of the admin permission will also be able to run the /wb_cfg, /give_square and /give_triangle commands. Also, by default, they will be associated with the permission profile that has no limits on placing water foundations. waterbases.vip1 Holders of this permission will follow settings and limits associated with with that permission profile. The permissions below are also registered, but not used by default. To use them, just create some permission profiles with those permissions as the key. waterbases.vip2 waterbases.vip3 waterbases.vip4 waterbases.vip5 Admin chat commands (must have ownerid/moderatorid/waterbases.admin permission) /give_square [optional arg: amount of items to receive] Will give the player a given amount of square-shaped water foundations. If no amount is provided, only 1 will be received. /give_triangle [optional arg: amount of items to receive] Will give the player a given amount of triangle-shaped water foundations. If no amount is provided, only 1 will be received. /draw_cargo This will draw a "bubble" (only for you, not every player) around every path node, and the bubble's radius will be taken from your config. If a player tries building inside one of these bubbles, they might get a warning or get prevent from doing so (because cargo ship destroys all structures in its way). Useful to visualise where your players can and cannot build, based on the cargo ship path. /shore_distance This will show you the current distance from the shore, to help you decide how close to/far from the shore to allow players to build. The unit used by Rust to measure shore distance is not in meters, it's something roughly equivalent to 1/10th of a map grid length. Mind you though, it's based off of the map's topology, so it should be fine on procgens, but if you have a custom map without topology layers reflecting the actual shoreline, you might want to disable relying on shore distance in your config. Admin console / chat command This command will work both from the chat (in that case, prefix it with a forward slash / ) and the console, (F1 or server/RCON console). Running this command as a player will require the waterbases.admin permission for players that are not moderatorid/ownerid enabled. wb.give [square/triangle] [partial player name or full steam ID] If a player executes it in the chat or console in-game and they don't specify a recipient, it will be given to the player executing this command. Executing from the server console requires specifying the player. Configuration (oxide/config/WaterBases.json and /wb_cfg chat command) Vast majority of the settings can be configured with the /wb_cfg chat command. Typing it in the chat with no parameters should dump a rundown of config fields and their values. In order to run any of the config commands, you will need to have ownerid or moderatorid (or the waterbases.admin permission). /wb_cfg RelyOnShoreDistance [logical values (true or false)] /wb_cfg GlobalOceanLevelCheckBeforePlacing [logical values (true or false)] /wb_cfg GlobalOceanLevelBaseline [fractions (like 1.2345) between -1000.00 and 1000.00] /wb_cfg CargoShipPathHandling ["Warn", "Prevent" or "None"] /wb_cfg MinDistanceFromCargoShipNode [fractions (like 1.2345) between 0.00 and 10000.00] /wb_cfg UnderwaterNetsCollectJunk [logical values (true or false)] /wb_cfg UnderwaterNetsRandomTimerMin [fractions (like 1.2345) between 0.00 and 10000.00] /wb_cfg UnderwaterNetsRandomTimerMax [fractions (like 1.2345) between 0.00 and 10000.00] /wb_cfg UnderwaterNetsItemLimit [integers (like 12345) between 0 and 100] /wb_cfg UnderwaterNetsSpawnSharks [logical values (true or false)] /wb_cfg UnderwaterNetsSharkRandomTimerMin [fractions (like 1.2345) between 1.00 and 100000.0] /wb_cfg UnderwaterNetsSharkRandomTimerMax [fractions (like 1.2345) between 1.00 and 100000.0] /wb_cfg UnderwaterNetsSharkTimerShortenByPercent [fractions (like 1.2345) between 1.00 and 100000.0] /wb_cfg UnderwaterNetsSharkSpawningMinDistance [fractions (like 1.2345) between 2.00 and 100000.0] /wb_cfg UnderwaterNetsSharkSpawningMaxDistance [fractions (like 1.2345) between 2.00 and 100000.0] /wb_cfg UnderwaterNetsSharkPopulationLimitLocal [integers (like 12345) between 0 and 1000] /wb_cfg UnderwaterNetsSharkPopulationLimitGlobal [integers (like 12345) between 0 and 1000] /wb_cfg UnderwaterNetsSharkSleepDespawnTimer [fractions (like 1.2345) between 2.00 and 100000.0] /wb_cfg UnderwaterNetsSharkHealthMultiplier [fractions (like 1.2345) between 0.001 and 100.0] /wb_cfg UnderwaterNetsSharkSpeedMultiplier [fractions (like 1.2345) between 0.001 and 100.0] /wb_cfg UnderwaterNetsSharkAggroRange [fractions (like 1.2345) between 0.001 and 100.0] /wb_cfg SharkHarvestingLootEnabled [logical values (true or false)] /wb_cfg GuiNEW1AnchorMinX [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW2AnchorMinY [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW3AnchorMaxX [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW4AnchorMaxY [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW5OffsetMinX [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW6OffsetMinY [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW7OffsetMaxX [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiNEW8OffsetMaxY [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiTextSize [integers (like 12345) between 0 and 100] /wb_cfg GuiButtonColor [hexadecimal numbers WITHOUT preceding # (like 3db4b3)] /wb_cfg GuiTextColor [hexadecimal numbers WITHOUT preceding # (like 3db4b3)] /wb_cfg GuiButtonAlpha [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg GuiTextAlpha [fractions (like 1.2345) between 0.00 and 1.00] /wb_cfg EnableBarrelEntities [logical values (true or false)] Advanced config (only editable through oxide/config/WaterBases.json) Water foundation crafting cost Here you can adjust how much it costs to craft water foundations. Make it more expensive, less expensive, or add/remove required materials. The cost will stay the same for all permission profiles. A full list of short names for items can be found at https://www.corrosionhour.com/rust-item-list/ "CraftingCostSquare": [ { "Shortname": "wood", "Amount": 100 }, { "Shortname": "metal.fragments", "Amount": 200 } ], "CraftingCostTriangle": [ { "Shortname": "wood", "Amount": 50 }, { "Shortname": "metal.fragments", "Amount": 100 } ], Shortname should belong to one of the available items in-game. The amount should be a whole number larger than 0 and smaller than the limit of a signed 32-bit integer (2 147 483 647). Permission profiles Using profiles you can quickly create/edit different permissions for different players, for example, if you have more than 1 VIP tier on your server - just add some new profiles. Different players can have different limits and permissions associated with building water bases. 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. That's the only one that you shouldn't remove! If you remove it, a new one with default values will be created. So if you don't want your default, non-VIP players to build water bases, don't remove the default profile, just take away privileges in that profile (like deploying/expanding/reinforcing). You don't have to use the built-in VIP permissions - any permission from any plugin will do just fine! By default, three permission profiles are generated in the config: default, waterbases.admin and waterbases.vip1. The default permission profile will apply to any player who doesn't have any permissions listed in the profile list - let's have a look at it: "PermissionProfiles": { "default": { "PermissionRequired": "default", "MaxBuildingGradeGeneric": "Wood", "MaxBuildingGradeFrames": "Stone", "MaxBuildingGradeWaterFoundations": "Metal", "WaterDepthMin": 2.0, "WaterDepthMax": 100.0, "MaxWaterFoundationsPerBuilding": 25, "MinDistanceFromOilrig": 200.0, "MinDistanceFromShore": 2.0, "MaxDistanceFromShore": 20.0, "CanDeployWaterFoundations": true, "CanReinforceWaterFoundations": true, "CanExpandWaterFoundations": true, "CanExpandReinforcedFoundations": true, "CanCraftWaterFoundations": true, "RequireMaterialsForCrafting": true, "WorkbenchLevelRequired": 2.0, "CanDeployUnderwaterNets": true, } PermissionRequired should contain an already existing permission registered by any plugin in the form of pluginname.permissionname MaxBuildingGradeGeneric, MaxBuildingGradeFrames andMaxBuildingGradeWaterFoundations define the highest allowed grade for a particular part of a water base. Generic means anything that's not a water foundation or a door/floor frame (that includes normal floors, walls, half walls, and inverse foundations). For those 3 settings, the accepted options are "Twigs", "Wood", "Stone", "Metal" or "TopTier". Set all of them to "TopTier" if you don't want any tier limits on water bases. WaterDepthMin and WaterDepthMax define the allowed range for water depth when placing water foundations - to make sure that certain players are not building in water that is too shallow/too deep. The unit meters. MaxWaterFoundationsPerBuilding is what it sounds like it will prevent a player under this permission profile from adding more water foundations to a water base, limiting their size. Set to a large value like 100000 for virtually no limits. MinDistanceFromOilrig will define the minimum distance from the closest oilrig (in meters) that has to be respected before placing a water foundation down. Decrease to let players build closer, increase to make them build farther away. MinDistanceFromShore and MaxDistanceFromShore both rely on your map topology. If you're sure that you're quite close to the shore, but the /shore_distance command shows you ridiculous values, it means your map does not have the topology map painted properly (contact the map dev and let them know!). In that case, you should set the RelyOnShoreDistance option in the config to false and instead rely on water depth (if shore distance is enabled, it will rely on both). The unit here is not a meter, but roughly 1/10th of a map grid (around 15 meters). CanDeployWaterFoundations if set to true, will allow players using this profile to deploy newly started foundations (using the doughnut guide, provided they have a properly shaped water foundation item to be consumed). CanReinforceWaterFoundations if set to true, will allow players using this profile to reinforce water foundations by hitting them with a hammer (provided they have a properly shaped water foundation item to be consumed). CanExpandWaterFoundations if set to true, will allow players using this profile to build more water foundations upon already existing ones by placing neighboring floors with their building plan (provided they have a properly shaped water foundation item to be consumed). CanExpandReinforcedFoundations if set to true, will allow players using this profile to attach a floor to the side of a reinforcement foundation - and as long as they have 2 water foundation items in their inventory, they will expand that reinforced foundation along with its water foundation. CanCraftWaterFoundations if set to true, will allow players using this profile to craft water foundations using a GUI in the bottom-right (showing while a Building Plan is equipped). Profiles with this setting set to false won't display those GUIs and players will have to find other ways of obtaining water foundations (loot, kits, server rewards etc). RequireMaterialsForCrafting if set to true, players using this profile will need to have required crafting materials in their inventory when trying to craft a Water Foundation. If set to false, the player will be able to craft an infinite amount of water foundations for free, so use them with caution. WorkbenchLevelRequired Set to 0.0 (no workbench nearby required), 1.0 (Level 1 required), 2.0 (Level 2 required) or 3.0 (Level 3 required) for crafting Water Foundations. CanDeployUnderwaterNets if set to true, players will be able to deploy nettings in underwater wall frames. Those settings will slowly accumulate underwater junk items if the feature is enabled on your server - look below for the loot table configuration. Underwater junk & Netting Shark loot tables If you have not disabled underwater nets collecting junk, this is where you can adjust the kind and rarity of certain items. You can even remove entries and add your own, including a custom skin and item name! A "loot table" is perhaps not the right term, as the list contains individual chances of a "caught" item being of a particular kind. There can be only 1 item caught at a time, and the table defines random weights for every possible entry. The larger the weight (compared to the sum of all weights), the bigger chance of encountering a particular item. So if you have 10 entries and each of them have a weight of 1, each item will have an equal 10% chance of being one of the random entries in the list (as the weights sum up to 10). Thus you can have some items really common, and some of them really rare. Here are 2 sample entries from the list: { "Shortname": "innertube", "CustomName": null, "SkinID": 2484982352, "RandomChanceWeight": 1.0, "MinRandomAmount": 1, "MaxRandomAmount": 1 }, { "Shortname": "innertube", "CustomName": null, "SkinID": 2485021365, "RandomChanceWeight": 1.0, "MinRandomAmount": 1, "MaxRandomAmount": 1 }, Shortname is the most important bit - make sure it's correct! You can find a link to a full list of those names above. CustomName lets you give items caught in the netting different names. You can leave that null to leave a default item name. In this example, the two items are water foundations - the proper name for those items will be applied automatically by the plugin anyway. Whatever you type there, make sure to encompass it in quotes, like "CustomName": "My Custom Item Name" if it's not null! SkinID is pretty self-explanatory - it's the long number in the URL of a Steam Workshop item. By default, it's 0 (no skin). RandomChanceWeight lets you decide the item's rarity when spawning - relative to the rarity of other items. Increase or decrease this number (it can be fractional) to make the item more or less rare. MinRandomAmount and MaxRandomAmount are what they sound like - they should both be larger than 0 (whole numbers) and when that particular item is caught, the stack will contain an amount between these two numbers. Translation support (oxide/lang/en/WaterBases.json) Almost every string the players see, including names for the water foundation items and messages displaying in the chat and the GUI, can be edited. Just load the plugin and let it generate the file - after you edit it, reload the plugin.

Introduction Custom Entities is a framework meant as a hard dependency for other plugins to register their own Types of spawnable entities under arbitrary server-sided prefab names (e.g. `"/assets/custom/changeme.prefab"`). Developers can extend BaseEntity and BaseCombatEntity classes (using provided wrapper Types) with their own logic that’s supposed to provide more or less functionality than desired. Once spawned, those custom entities will network an existing vanilla prefab name to the clients - and that networked prefab name can even be switched to a different one dynamically during run-time. Custom prefab names are registered with the GameManager, GameManifest and StringPool. This means that any admin, plugin (like CopyPaste) or even the server command "spawn" will treat it just like vanilla entity prefabs would be treated, and that prefab will show up on the list of spawnable entity prefabs. As long as the plugin is still loaded in! This framework does all the heavy lifting associated with registering prefab names unregistering prefab names saving custom entities to plugin-specific, separate savefiles loading and spawning custom entities from plugin-specific datafiles addressing some nuances and edge cases for common case scenarios hiding the unorthodox hackery involved to make it work behind a comfortable curtain of abstraction so that the developers get to focus on the fun bits NOTE: This plugin utilises Reflection in 2 or 3 places (CTRL+F for the comments "//naughty reflection") in order to force the BaseEntity._prefabName field to its custom, registered prefab name, instead of the prefab name of the original entity it was based on. This field is private and changing its accessor to public leads to less than stellar results, according to WhiteThunder's experiments with patching Oxide. In my opinion there is no point in turning the entire plugin into a compiled extension for the sole purpose of addressing the BaseEntity._prefabName field without breaking the "unbreakable" rule of not allowing Reflection. Localization The plugin registers default messages in English. Find them in /oxide/lang/en/CustomEntities.json Permissions customentities.admin - Required to execute the `spawn_at`, `purge_prefab` and `purge_plugin` commands. Admin commands spawn_at <short prefab name> - spawn a new instance of a given entity by its short prefab name at the position of the executing admin’s head. Useful for spawning a vanilla or a custom entity when not looking at any solid colliders. You don’t need to provide the complete short prefab name - just the initial portion will do, as long as it’s unique. It’s only a wrapper for the vanilla `spawn` command, after all. purge_prefab <short prefab name>` - this command can also be executed from the server console/RCON or by a plugin. It will find and kill all entities currently spawned in with a matching short prefab name. Same name matching rules apply as above. CAUTION: this will kill given vanilla and custom entities alike and cannot be reverted. Only really meant for emergency debugging situations. There’s no safeguarding for this command apart from the required customentities.admin permission. You have been warned. purge_plugin <plugin name> similar to the command above and also requires the customentities.admin permission. The difference is that instead of filtering by prefab name, it kills all the entities registered by a certain dependent plugin. In case of the example plugin (see below), it will clear all the waypoints (and brushes). Data Custom Entities have a "take only memories, leave only footprints" approach to handling the game state. When a dependent plugin registers a custom prefab bundle, all the entity data from that bundle will be stored in its own, separate savefile under /oxide/data/CustomEntities/<PluginName>.sav This includes the custom entity instances as well as the purely vanilla entities somehow connected with the custom ones. We’re mainly talking about all the vanilla entities related to Items that could be stored/handled by the bundle savefile: held entities, sub entities, instance data subentities, all checked recursively. When a dependent plugin needs to spawn a vanilla entity - for example, to have it parented or referenced later by Net.Id to a custom one, a built-in API method allows the developers to permanently place those entities in the same custom savefile as the one belonging to the plugin. This custom savefile is populated (if there’s anything to save to it, that is) every time a normal server save happens - so usually during set intervals and on server shutdown. It’s also saved when the relevant dependent plugin is unloaded. During plugin unload, all the instances of custom entities (and any vanilla entities associated with them) are removed from the world, as if they never existed. Then the savefile can be safely removed/copied/replaced without affecting anything else or wiping the vanilla save. The custom savefiles are serialised in a format similar to vanilla ones, utilising memory streams and native ProtoBufs. This allows a CustomBaseEntity or a CustomBaseCombatEntity implementation to override Save and Load methods to take advantage of the vast collection of native serialisable ProtoBufs. In addition to this, custom entities inside of a savefile can have any extra data about them serialised and deserialised using BinaryWriters and BinaryReaders. The Net.ID of the last known Community Instance is also stored in the datafile. On plugin load, it will try and detect if the one currently present on the server matches it. If it doesn’t, which is usually caused by wiping a savefile manually or restarting the server with a different map, it won’t load any stale entities and instead generate a new savefile under the same name. Just like in vanilla, whenever an existing savefile is about to be overwritten, its contents are copied and shifted to iterative backups. The number of those backups stored is the same as the current vanilla one - by default it’s 2, but it can be controlled with the server.saveBackupCount convar. HOW TO: Example dependent plugin The best way to convey how to utilise Custom Entities as a dependency for your plugins is by having a look at the provided example, which can be viewed/downloaded from Custom Entities on GitHub This example features Waypoints, a collection of nodes in 3D space, grouped into graphs that can dynamically join and split.When a player puts a Map Item in their belt and switches to it, it activates a brush tool that allows the player to create/erase Waypoints in front of their eyes. Left-click to place a new waypoint where you’re looking, right-click to erase the one you’re currently looking at (if there is one). New Waypoints can only be placed if they don’t collide with other Waypoints or the terrain. When a waypoint is placed, it will automatically connect to other waypoints in the radius of 30 metres - provided there’s a direct, unobstructed line of sight on a pretty arbitrarily chosen layer mask, using a spherecast which is 0.5 m thick. The graphs currently serve no purpose, but in the future I could see it as a way to visually edit traversable 3D navigation meshes. Both the Waypoint and the Waypoint Brush are custom entities. The licence of the example is the same as the licence of Custom Entities - that is, MIT.