Skip to content
RustPluginGenerator
Player hookOxide + CarbonCompiled against Rust 2635.289.1 / Oxide 2.0.7839 · checked Oct 26, 2026

CanUseWires

CanUseWires is called from WireTool.CanPlayerUseWires to decide whether a player may place or connect wires with the Wire Tool. Returning a bool overrides the game's normal answer, including creative-mode unlimited IO.

Signature
object CanUseWires(BasePlayer player, bool cached, float cacheDuration, IOEntity targetIoEnt)

Parameters

Hook parameters
ParameterTypeDescription
playerBasePlayerThe BasePlayer attempting to place, connect or upgrade a wire with the Wire Tool. May be null in edge cases, so null-check before reading anything from it.
cachedboolWhether the game intends to serve the answer from a short-lived cache. Passed through from WireTool.CanPlayerUseWires; you can ignore it for permission logic.
cacheDurationfloatHow long, in seconds, the game would cache a cached result. Only relevant when cached is true and you are reproducing the caching behavior yourself.
targetIoEntIOEntityThe IOEntity being wired to, or null when the player is starting a fresh wire or the target is not an IO entity yet. Use it to allow or block specific electrical entities.

Return value

Return a bool to replace the result of WireTool.CanPlayerUseWires entirely: true lets the player wire, false blocks it. Return null (or any non-bool value) and the original method continues with its own privilege and creative-mode checks.

How it works

The hook fires inside WireTool.CanPlayerUseWires, which the game runs whenever a player operates the Wire Tool: placing the first endpoint of a wire, connecting to a second endpoint, or re-checking access to the entity they are wiring. player is the tool user, targetIoEnt is the destination IO entity (or null on the first click), and cached/cacheDuration describe the game's short result cache. Return a bool to force the answer; return null to let the game's own rules run (building privilege, entity ownership checks, and the creative-mode Creative.unlimitedIo bypass).

Declaring player as BasePlayer is already the natural type here. You cannot meaningfully narrow targetIoEnt because Oxide skips the hook when the argument is not an instance of your declared type, which would silently disable your check for the null first-click case. Read targetIoEnt defensively with as on members like OwnerID if you need owner filtering.

Example plugin: Restrict wire tool use to building-authed players

WireToolAuthOnly.cs
using UnityEngine;
using Oxide.Core;

namespace Oxide.Plugins
{
    [Info("Wire Tool Auth Only", "RustPluginGenerator", "1.0.0")]
    [Description("Blocks Wire Tool use unless the player is building-authed on the target entity's base.")]
    public class WireToolAuthOnly : RustPlugin
    {
        private const string PermBypass = "wiretoolauthonly.bypass";

        private void Init()
        {
            permission.RegisterPermission(PermBypass, this);
        }

        private object CanUseWires(BasePlayer player, bool cached, float cacheDuration, IOEntity targetIoEnt)
        {
            if (player == null || player.IsAdmin || player.IsInCreativeMode)
                return null;

            if (permission.UserHasPermission(player.UserIDString, PermBypass))
                return true;

            if (targetIoEnt == null)
                return null;

            BuildingPrivlidge privilege = targetIoEnt.GetBuildingPrivilege();
            if (privilege == null)
            {
                // No foundation under the target: fall back to the player's own position.
                privilege = player.GetBuildingPrivilege();
                return privilege != null && privilege.IsAuthed(player);
            }

            return privilege.IsAuthed(player);
        }
    }
}

The plugin denies wiring unless the player is building-authed on the target entity's building, is an admin, or has the wiretoolauthonly.bypass permission. OnServerInitialized registers that permission. In CanUseWires we null-check the player, always allow admins and bypass holders, and then inspect targetIoEnt: if the target has a building privilege we test IsAuthed; if it does not (an unfounded entity, or the null first click) we also require the player to be authed on the entity's own building via GetBuildingPrivilege. Everything is returned as a bool so the hook fully controls the wire tool result.

Common use cases

  • Raid-proof electrical bases

    Block enemy players from cutting or reconnecting wires inside a compound by requiring building auth on the target IO entity's privilege.

  • Per-entity wiring whitelist

    Inspect targetIoEnt and compare OwnerID against a stored list of allowed players for that specific turret, door controller or solar panel.

  • PvP server grief prevention

    Deny wire placement for players outside their own base while leaving admins and a staff permission exempt.

Pitfalls

  • targetIoEnt can be null

    The first click of a wire has no target yet. Always null-check before calling GetBuildingPrivilege or reading OwnerID.

  • Returning null keeps creative IO

    Returning null lets player.IsInCreativeMode && Creative.unlimitedIo bypass your rules, so return false explicitly if you want creative servers restricted too.

  • Narrowing the parameter disables the hook

    Declaring targetIoEnt as a subtype like ElectricSwitch makes Oxide skip the hook whenever the argument is anything else, including null.

Build a plugin with CanUseWires

Describe what should happen and get a compiled plugin that uses this hook.

Prompt: Raid-proof electrical bases using the CanUseWires hook, with a config file and a permission
Generate this plugin

Edit the prompt on the next screen. 2 free plugins a month, no card.

Last updated Oct 26, 2026. Found a mistake? Email support@rustplugingenerator.com.

Build a plugin with CanUseWires

Generate