CanAssignMission
CanAssignMission is called from BaseMission.AssignMission right before a mission is written into the player's mission state, and a returned bool overrides whether the assignment happens.
object CanAssignMission(BasePlayer assignee, BaseMission mission, IMissionProvider provider)Parameters
| Parameter | Type | Description |
|---|---|---|
assignee | BasePlayer | The BasePlayer who is about to receive the mission. Never null at this point; use it to check team, permissions, position or inventory state. |
mission | BaseMission | The BaseMission instance being assigned. Its short name and provider identify which mission the game is handing out. |
provider | IMissionProvider | The IMissionProvider that supplies the mission, usually the mission system itself. Its ProviderID() string is the stable identifier for the source. |
Return value
Return null to keep the game's decision unchanged. Return a bool to replace the original result: false stops the mission from being assigned, true allows it. Non-bool values are ignored and the game continues its own assignment path.
How it works
The hook fires inside BaseMission.AssignMission, after the game has already run its own Server_CanAcceptMission check on the player. At that point the assignee, the mission and its provider are passed to plugins, and if any plugin returns a bool the game takes it as the assignment result and returns immediately, skipping mission state creation.
Use assignee to gate access by permission, team size, position or anything else stored on the player. mission exposes the concrete mission (for example a BaseMission subclass) so you can react to specific missions, and provider.ProviderID() gives a stable string for the mission source. Returning null (or not declaring the hook at all) leaves the decision entirely to the game; returning false blocks the assignment, returning true lets it proceed even when a plugin earlier in the chain would block it. Because the hook runs on every assignment, keep the body cheap and never log there.
Example plugin: Lock missions behind a permission
using System;
using System.Collections.Generic;
using Newtonsoft.Json;
using Oxide.Core;
using UnityEngine;
namespace Oxide.Plugins
{
[Info("MissionPermissionGate", "RustPluginGenerator", "1.0.0")]
[Description("Requires a permission before a player can be assigned a mission")]
public class MissionPermissionGate : RustPlugin
{
private const string PermUse = "missionpermissiongate.use";
private PluginConfig config;
public class PluginConfig
{
[JsonProperty("Notify blocked players")]
public bool NotifyBlocked { get; set; } = true;
}
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 need mission access before you can accept a mission."
}, this);
}
private string Msg(string key, string userId = null, params object[] args)
{
return string.Format(lang.GetMessage(key, this, userId), args);
}
private void Init()
{
permission.RegisterPermission(PermUse, this);
}
private object CanAssignMission(BasePlayer assignee, BaseMission mission, IMissionProvider provider)
{
if (assignee == null || mission == null || provider == null) return null;
if (permission.UserHasPermission(assignee.UserIDString, PermUse)) return null;
if (config.NotifyBlocked)
{
var player = assignee;
NextTick(() =>
{
if (player != null && player.IsConnected)
player.ChatMessage(Msg("NoPermission", player.UserIDString));
});
}
return false;
}
}
}The plugin registers a single permission and blocks every mission assignment unless the player has it, which lets admins hand out mission access selectively instead of leaving missions open to the whole server.
CanAssignMission returns false for players without missionpermissiongate.use and null for everyone else so the game's own logic still runs. Blocked players get a language-driven chat notice that is throttled with NextTick so the hook body stays cheap and the message is not repeated within the same frame chain. The permission is registered in Init, messages in LoadDefaultMessages, and the plugin unloads without timers or UI.
Common use cases
VIP-only missions
Return false unless the player has a permission or a group granted by a rank plugin, so missions become a paid or whitelisted feature.
Team-size requirements
Check
assignee.currentTeamwithRelationshipManager.ServerInstance.FindTeamand block missions for solo players or oversized groups.Zone-based mission rules
Block assignment while the player is inside a safe zone or building blocked area, then allow it once they leave.
Pitfalls
AssignMission runs on the server thread every call
The hook fires each time the game tries to assign a mission, including retries. Keep it to simple checks and never call Puts or PrintWarning inside it.
The game's own check already ran
Server_CanAcceptMissionis evaluated before the hook. A true return does not bypass that earlier check, so you cannot use this hook to force a mission onto a player the game already rejected.Blocking silently confuses players
Returning false gives the player no feedback on its own. Send a throttled message through the language file, or players will assume a bug.
Build a plugin with CanAssignMission
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 CanAssignMission
Generate