Skip to content
RustPluginGenerator

OnItemRepair

OnItemRepair is called when a player uses a Repair Bench on an item, after the bench has validated the item and before the repair cost is calculated. Returning a non-null value cancels the repair entirely.

Signature
object OnItemRepair(BasePlayer player, Item itemToRepair)

Parameters

Hook parameters
ParameterTypeDescription
playerBasePlayerThe BasePlayer who triggered the repair at the repair bench. Null-check it before use; in the repair bench flow it is the owner of the bench.
itemToRepairItemThe Item instance being repaired. Use itemToRepair.info.shortname, amount, condition and maxCondition to decide whether to allow, block or modify the repair.

Return value

Returning null (or nothing) lets the repair bench continue and charge the normal repair cost. Any non-null return value makes RepairAnItem return immediately, so the item is not repaired and no cost is taken.

How it works

The hook fires inside RepairBench.RepairAnItem, after the early bail-out checks (whether the item can be repaired at all) and before the game computes RepairCostFraction and spends components. Because it runs before cost calculation, you can block a repair without the player losing scrap or components, and you can also stop the whole bench interaction for that item.

Both parameters are useful: player identifies who is repairing (permissions, team, economy checks), and itemToRepair gives you the item definition, condition, max condition, skin and amount. You cannot change the repair result from this hook since it returns an object only used as a cancel signal; use the item itself if you need to adjust condition data, but be careful because the bench code continues reading the item afterwards.

Declaring player as BasePlayer is already the actual type, so dispatch always matches. If you want the hook to fire only for a narrower scenario (for example only weapons), inspect itemToRepair.info.category or the shortname inside the hook rather than relying on parameter type narrowing. Do not spawn entities or send heavy UI from here; keep it to a permission lookup, balance check or rate limit.

Example plugin: Limit repairs by permission and player cooldown

RepairBenchLimit.cs
using UnityEngine;
using System;
using System.Collections.Generic;
using Newtonsoft.Json;
using Oxide.Core;

namespace Oxide.Plugins
{
    [Info("RepairBenchLimit", "RustPluginGenerator", "1.0.0")]
    [Description("Restricts repair bench use by permission and per-player cooldown.")]
    public class RepairBenchLimit : RustPlugin
    {
        private const string PermUse = "repairbenchlimit.use";

        private PluginConfig config;
        private readonly Dictionary<ulong, float> nextAllowedRepair = new Dictionary<ulong, float>();

        private class PluginConfig
        {
            [JsonProperty("Require permission to repair")]
            public bool RequirePermission { get; set; } = true;

            [JsonProperty("Cooldown between repairs (seconds)")]
            public float CooldownSeconds { get; set; } = 30f;
        }

        protected override void LoadDefaultConfig() => config = new PluginConfig();

        protected override void LoadConfig()
        {
            base.LoadConfig();
            try
            {
                config = Config.ReadObject<PluginConfig>();
                if (config == null) throw new Exception();
            }
            catch
            {
                PrintWarning("Configuration file is invalid, using defaults");
                LoadDefaultConfig();
            }
            SaveConfig();
        }

        protected override void SaveConfig() => Config.WriteObject(config);

        protected override void LoadDefaultMessages()
        {
            lang.RegisterMessages(new Dictionary<string, string>
            {
                ["NoPermission"] = "You do not have permission to use the repair bench.",
                ["Cooldown"] = "You must wait {0} more seconds before repairing again."
            }, this);
        }

        private string Msg(string key, string userId = null, params object[] args)
            => string.Format(lang.GetMessage(key, this, userId), args);

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

        private object OnItemRepair(BasePlayer player, Item itemToRepair)
        {
            if (player == null || itemToRepair == null) return null;

            if (config.RequirePermission && !permission.UserHasPermission(player.UserIDString, PermUse))
            {
                player.ChatMessage(Msg("NoPermission", player.UserIDString));
                return true;
            }

            if (config.CooldownSeconds > 0f)
            {
                float now = UnityEngine.Time.realtimeSinceStartup;
                float readyAt;
                if (nextAllowedRepair.TryGetValue(player.userID, out readyAt) && now < readyAt)
                {
                    player.ChatMessage(Msg("Cooldown", player.UserIDString, Math.Ceiling(readyAt - now)));
                    return true;
                }
                nextAllowedRepair[player.userID] = now + config.CooldownSeconds;
            }

            return null;
        }

        private void Unload()
        {
            nextAllowedRepair.Clear();
        }
    }
}

The plugin blocks repair-bench use unless the player has the repairbenchlimit.use permission, and enforces a configurable cooldown between repairs. OnItemRepair is the single check point: if the permission is missing or the cooldown is still active, it returns a non-null value so the bench code exits before cost is calculated, and the item stays unrepaired. The cooldown is stored per player ID in memory only, so it resets on reload, which is fine for a rate-limit feature. Chat feedback goes through lang messages so it can be localized. The class registers the permission in Init, reads two config values, and never touches the item itself.

Common use cases

  • VIP-only repair access

    Gate the repair bench behind a group or permission so only paying or trusted players can restore item condition. Returning a non-null value blocks the repair cleanly.

  • Anti-abuse cooldown

    Track the last repair time per player and refuse rapid repeat repairs, which stops scripts that spam broken gear to farm upkeep-free condition.

  • Economy-gated repairs

    Check a currency balance via an Economy plugin reference before allowing repair, and charge on success. Since the hook fires before cost, you can abort without double-charging scrap.

Pitfalls

  • Returning true blocks every repair

    Any non-null value cancels the repair. If you return false you still block it; only null lets the bench proceed. Check this carefully when writing conditional early returns.

  • Hook fires before the cost is taken

    Because the cost calculation happens after the hook, changing the item's condition inside the hook affects the charged amount. Avoid mutating the item here unless you intend that side effect.

  • No reverse hook on cancel

    There is no separate callback when a repair is refused by your plugin, so send player-facing feedback through player.ChatMessage or lang messages from inside this hook if needed.

Build a plugin with OnItemRepair

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

Prompt: VIP-only repair access using the OnItemRepair 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 OnItemRepair

Generate