OnTurretAssigned
OnTurretAssigned is called after a player is added to an AutoTurret's authorized list through the normal in-game authorize action. It fires once per successful assignment, after the ID is stored in the turret and before the server sends the network update.
void OnTurretAssigned(AutoTurret autoTurret, ulong playerId, BasePlayer player)Parameters
| Parameter | Type | Description |
|---|---|---|
autoTurret | AutoTurret | The AutoTurret entity the player was just added to. Use its transform, OwnerID or net.ID to identify which turret the authorization belongs to. |
playerId | ulong | The Steam/player ID that was added to the turret's authorized list. This is the raw ulong written into authorizedPlayers, not an entity reference. |
player | BasePlayer | The BasePlayer who performed the authorization, taken from the authorization message source. Can be null in edge cases (for example when the caller is not a connected player), so null-check before use. |
Return value
The return value is ignored. This hook is patched with a continue behavior into a void method, so returning null or any value does not change whether the player is added to the turret's authorized list or whether the network update is sent.
How it works
The hook fires inside AutoTurret.AssignToFriend on the server, in the same block that records the new entry in the turret's authorizedPlayers list and updates the max auth capacity. It runs after the analytics event and the list add, so reading autoTurret.authorizedPlayers already reflects the new entry. Because the only injection site is the friend/assign path, it does not fire for deauthorization, clearing the list, or state changes such as mode toggles or power.
The parameters cover the whole picture: autoTurret is the entity, playerId is the ulong that was written to the auth list, and player is the player who performed the action. That lets you distinguish self-authorization from a third party adding someone else by comparing playerId against player.userID. Declaring a more specific type for the first parameter (for example a subclass of AutoTurret) would filter out valid calls since the argument is always an AutoTurret.
Typical uses are logging authorized users per turret, restricting who may be authorized by permission, or syncing external records. The hook fires only on real assignments, so it is safe for occasional database writes but not for per-tick work.
Example plugin: Restrict turret authorization with a permission and audit it
using System;
using System.Collections.Generic;
using Newtonsoft.Json;
using Oxide.Core;
using UnityEngine;
namespace Oxide.Plugins
{
[Info("Turret Auth Guard", "RustPluginGenerator", "1.0.0")]
[Description("Audits AutoTurret authorizations and enforces a permission for sharing turrets")]
public class TurretAuthGuard : RustPlugin
{
private const string PermAllow = "turretauthguard.allow";
private PluginConfig config;
private StoredData data;
private class PluginConfig
{
[JsonProperty("Require permission to authorize turrets")]
public bool RequirePermission = true;
[JsonProperty("Log every authorization to data file")]
public bool LogAuthorizations = true;
}
private class StoredData
{
[JsonProperty("Authorizations")]
public List<AuthEntry> Entries = new List<AuthEntry>();
}
private class AuthEntry
{
[JsonProperty("Turret network id")] public ulong TurretId;
[JsonProperty("Added player id")] public ulong AddedId;
[JsonProperty("Acting player id")] public ulong ActingId;
[JsonProperty("UTC time")] public string Utc;
}
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);
private void Init()
{
permission.RegisterPermission(PermAllow, this);
}
private void OnServerInitialized()
{
data = Interface.Oxide.DataFileSystem.ReadObject<StoredData>(Name) ?? new StoredData();
}
private void Unload()
{
if (data != null)
Interface.Oxide.DataFileSystem.WriteObject(Name, data);
}
private void OnTurretAssigned(AutoTurret autoTurret, ulong playerId, BasePlayer player)
{
if (autoTurret == null || player == null) return;
if (config.RequirePermission && !permission.UserHasPermission(player.UserIDString, PermAllow))
{
autoTurret.authorizedPlayers.Remove(playerId);
autoTurret.SendNetworkUpdate();
player.ChatMessage("You are not allowed to authorize this turret.");
return;
}
if (!config.LogAuthorizations || data == null) return;
data.Entries.Add(new AuthEntry
{
TurretId = autoTurret.net.ID.Value,
AddedId = playerId,
ActingId = player.userID.Get(),
Utc = DateTime.UtcNow.ToString("u")
});
// Keep the file bounded on long-running servers.
if (data.Entries.Count > 5000)
data.Entries.RemoveRange(0, data.Entries.Count - 5000);
}
}
}The plugin registers a permission turretauthguard.allow. In OnTurretAssigned it checks player, then verifies they hold the permission. Because the return value does not affect the game, the plugin cannot block the assignment from inside the hook; instead it records the event and, when the acting player lacks permission, deauthorizes them with autoTurret.authorizedPlayers.Remove(playerId) and calls SendNetworkUpdate so the client sees the change. Any legitimate assignment is written to a data file with the turret's network ID, the added player ID and a UTC timestamp via Interface.Oxide.DataFileSystem. The file is loaded on startup and saved on unload, matching the standard persistence pattern.
Common use cases
Audit authorized users per turret
Store which player IDs were added to each turret and when, so admins can trace griefing or shared base issues without reading logs manually.
Enforce a permission for turret sharing
Deauthorize or notify the acting player when they lack the required permission, since the hook cannot block the assignment itself.
Notify a team or owner
Send a chat or console message to the base owner when a new player is authorized on their turret, giving visibility over shared defenses.
Pitfalls
The hook cannot prevent the assignment
It fires after the ID has been written into authorizedPlayers and only has a continue return behavior, so you must undo the change explicitly and send a network update if you want to reject it.
player can be null
The third argument comes from the authorization message source, so guard against null before reading userID or sending messages.
Not fired for removals or resets
Deauthorize, clear list and similar actions use other hooks, so do not expect this hook to keep an external member list accurate on its own.
Build a plugin with OnTurretAssigned
Describe what should happen and get a compiled plugin that uses this hook.
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 OnTurretAssigned
Generate