Search the Community

A useful API plugin that mimics in-game status bars and allows the addition of custom ones. Note: AdvancedStatus does not display any bars on its own. This is done by other plugins that work with it. An example plugin demonstrating interaction with AdvancedStatus. The ability to specify the frequency of calculating the number of bars; The ability to specify the order of the bar; The ability to change the height of the bar; The abillity to customize the color and transparency of the background; The ability to set a material for the background; The ability to switch between CuiRawImageComponent and CuiImageComponent for the image; The ability to get images from the local folder(*SERVER*\oxide\data\AdvancedStatus\Images); The abillity to set own image and customize the color and transparency of the image; The abillity to set sprite instead of the image; The ability to specify custom text; The ability to customize the color, size and font of the text; No need to pass all parameters; No need to manually delete your bar when unloading your plugin. advancedstatus.admin - Grants access to the chat command(by default /bar). { "Chat command": "bar", "Is it worth enabling console notifications for the successful loading of local images?": false, "Interval(in seconds) for counting in-game status bars": 0.5, "Interval(in seconds) for counting Building Privileges status bars. Note: Calculating Building Privileges is resource-intensive": 1.0, "Is it worth counting Vehicle Privilege? Useful if you don't have a Tugboat or PlayerBoat": true, "Is it worth counting Entity Privilege? Useful if you don't have a Legacy Shelter": true, "Ui layer for displaying bars. For button bars, it is recommended to use the 'Hud' layer(https://docs.oxidemod.com/guides/developers/basic-cui/basic-cui#layers)": "Under", "Is it worth displaying bar components left to right?": true, "Vertical spacing between bars": 2, "The height of the bar by default": 26, "The background color of the bar by default": "#505F75", "The background transparency of the bar by default": 0.7, "The background material of the bar by default, leave empty to disable": "", "The image of the bar by default": "AdvancedStatus_Default", "The color of the bar image by default": "#6B7E95", "The transparency of the bar image by default": 1.0, "The outline color of the bar image by default": "#000000", "The outline transparency of the bar image by default": 1.0, "The outline distance of the bar image by default. Example '0.75 0.75'": "", "The size of the bar text by default": 12, "The color of the bar text by default": "#FFFFFF", "The transparency of the bar text by default": 1.0, "The font of the bar text by default(https://docs.oxidemod.com/guides/developers/basic-cui/basic-cui#fonts)": "RobotoCondensed-Bold.ttf", "The horizontal offset of the bar text by default": 0, "The outline color of the bar text by default": "#000000", "The outline transparency of the bar text by default": 1.0, "The outline distance of the bar text by default": "", "The size of the bar subtext by default": 12, "The color of the bar subtext by default": "#FFFFFF", "The transparency of the bar subtext by default": 1.0, "The font of the bar subtext by default": "RobotoCondensed-Bold.ttf", "The outline color of the bar subtext by default": "#000000", "The outline transparency of the bar subtext by default": 1.0, "The outline distance of the bar subtext by default": "", "The color of the bar progress by default": "#89B840", "The transparency of the bar progress by default": 0.7, "The OffsetMin of the bar progress by default": "25 2.5", "The OffsetMax of the bar progress by default": "-3.5 -3.5", "Version": { "Major": 0, "Minor": 1, "Patch": 27 } } EN: { "MsgDays": "d", "MsgHours": "h", "MsgMinutes": "m", "MsgSeconds": "s" } RU: { "MsgDays": "д", "MsgHours": "ч", "MsgMinutes": "м", "MsgSeconds": "я" } images reload *ImageName* - Reloads the specified image from the image folder; all - Reloads all local images from the image folder. Example: /bar images reload all Note: To access the commands, the player must be an admin(console or owner) or have the advancedstatus.admin permission. OnAdvancedStatusLoaded: Called after the AdvancedStatus plugin is fully loaded and ready. OnPlayerGainedBuildingPrivilege: Called after the player enters their building privilege. OnPlayerLostBuildingPrivilege: Called after the player exits their building privilege. void OnAdvancedStatusLoaded() { Puts("The AdvancedStatus plugin is loaded and ready to go!"); } void OnPlayerGainedBuildingPrivilege(BasePlayer player) { Puts($"{player.displayName} entered the authorized building privilege zone."); } void OnPlayerLostBuildingPrivilege(BasePlayer player) { Puts($"{player.displayName} exited the authorized building privilege zone."); } [PluginReference] private Plugin AdvancedStatus; There are 15 methods: IsReady CreateBar UpdateContent DeleteBar DeleteCategory DeleteAllBars GetTotalClientBars GetTotalPlayerBars LoadImages LoadImage CopyImage DeleteImages DeleteImage BarExists InBuildingPrivilege There are 5 types of bar: Default - A simple bar that displays the provided information. Does not update the value of SubText by itself; Timed - Similar to the default bar, but it automatically disappears after the specified time in the TimeStamp parameter; TimeCounter - The SubText shows the remaining time until TimeStamp. Also automatically removed upon expiration of the TimeStamp; TimeProgress - Similar to the Timed bar, but additionally features an automatically filling progress bar; TimeProgressCounter - Similar to the TimeCounter bar, but additionally features an automatically filling progress bar. IsReady: Used to check if the AdvancedStatus plugin is loaded and ready to work. The IsReady method returns true if it is ready, or null if it is not. (bool)AdvancedStatus?.Call("IsReady");//Calling the IsReady method. If the result is not null(bool true), the plugin is ready. CreateBar: Used to create a bar or update bar values for a player. To call the CreateBar method, you need to pass 2 parameters. The first one is BasePlayer or <ulong>playerID. The second one is a dictionary with the parameters you need. In the CreateBar method, all parameters are optional, except for two: Id; Plugin. Parameters not specified when creating a new bar will use the values set in the AdvancedStatus plugin's configuration file. Parameters not specified during bar update will retain the values they had before the update. Note: The plugin does not update values automatically, you need to manually send new values. Dictionary<string, object> parameters = new Dictionary<string, object> { { "Id", "AdvancedStatusDemo_1" }, //<string>Unique identifier for the bar in your plugin. ***This is a required field. { "BarType", "Default" }, //<string>Type of the bar. There are 4 types: Default, Timed, TimeCounter and TimeProgress. { "Plugin", "AdvancedStatusDemo" }, //<string>Name of your plugin. ***This is a required field. { "Category", "Default" }, //<string>Internal plugin category of the bar. { "Order", 10 }, //<int>The position of your bar relative to others. Order is determined by increasing values(ASC). { "Height", 26 }, //<int>The height of your bar. A standard bar is 26 pixels. { "Main_Color", "#505F75" }, //<string>HTML Hex color of the bar background. { "Main_Transparency", 0.7f }, //<float>Transparency of the bar background. { "Main_Material", "assets/content/ui/uibackgroundblur.mat" }, //<string>Material of the bar background(empty to disable). { "Image", "scrap" }, //<string>Name of the image saved in the ImageLibrary or a direct link to the image if ImageLibrary is not used. { "Image_Local", "AdvancedStatusDemo_Scrap" }, //<string>The name of the image file(without its extension) located in *SERVER*\data\AdvancedStatus\Images. Leave empty to use Image. { "Image_Sprite", "" }, //<string>Sprite image of the bar. Leave empty to use Image_Local or Image. { "Is_RawImage", true }, //<bool>Which type of image will be used? True - CuiRawImageComponent. False - CuiImageComponent. { "Image_Color", "#6B7E95" }, //<string>HTML Hex color of the bar image. { "Image_Transparency", 1.0f }, //<float>Transparency of the image. { "Text", "Scrap" }, //<string>Main text. { "Text_Size", 12 }, //<int>Size of the main text. { "Text_Color", "#FFFFFF" }, //<string>HTML Hex color of the main text. { "Text_Font", "RobotoCondensed-Bold.ttf" }, //<string>Font of the main text. { "Text_Offset_Horizontal", 0 }, //<int>Horizontal offset for the main text. { "SubText", "35" }, //<string>Sub text. { "SubText_Size", 12 }, //<int>Size of the sub text. { "SubText_Color", "#FFFFFF" }, //<string>HTML Hex color of the sub text. { "SubText_Font", "RobotoCondensed-Bold.ttf" }, //<string>Font of the sub text. { "TimeStampStart", Network.TimeEx.currentTimestamp }, //<double>Responsible for specifying the start point of the time reference and 0% for TimeProgress and TimeProgressCounter bars. Used if the bar type is Timed, TimeCounter, TimeProgress or TimeProgressCounter. { "TimeStamp", Network.TimeEx.currentTimestamp + 6 }, //<double>Specifies the end time point after which the bar will be destroyed and 100% for TimeProgress and TimeProgressCounter bars. Used if the bar type is Timed, TimeCounter, TimeProgress or TimeProgressCounter. { "TimeStampDestroy", Network.TimeEx.currentTimestamp + 3 }, //<double>If TimeStampDestroy is specified and it is less than TimeStamp, the bar will be destroyed by TimeStampDestroy. Used if the bar type is Timed, TimeCounter, TimeProgress or TimeProgressCounter. { "Progress", (float)35 / 100f }, //<float>Progress. From 0.0 to 1.0. { "Progress_Reverse", false }, //<bool>Progress reverse. A value of false means that the progress will increase. Used if the bar type is TimeProgress or TimeProgressCounter. { "Progress_Color", "#89B840" }, //<string>Progress color. { "Progress_Transparency", 1f }, //<float>Progress transparency. { "Progress_OffsetMin", "25 2.5" }, //<string>Progress OffsetMin: "*left* *bottom*". { "Progress_OffsetMax", "-3.5 -3.5" }, //<string>Progress OffsetMax: "*right* *top*". { "Command", "kit" } //<string>If the field is not empty, the bar becomes clickable, and the specified command is executed upon clicking. Note: the command must be covalence. }; AdvancedStatus?.Call("CreateBar", player.userID.Get(), parameters); //Calling the CreateBar method with the passing of BasePlayer/playerID and a dictionary containing the required parameters. UpdateContent: Used to update only the content of an existing status bar. To call the UpdateContent method, you need to pass 2 parameters. The first one is BasePlayer or <ulong>playerID. The second one is a dictionary with the parameters you need. In the UpdateBar method, all parameters are optional, except for two: Id; Plugin. var parameters = new Dictionary<string, object> { { "Id", "MyID" }, //<string>Unique identifier for the bar in your plugin. ***This is a required field. { "Plugin", Name }, //<string>Name of your plugin. ***This is a required field. { "Text", "MyText" }, //<string>Main text. { "SubText", "MyText" }, //<string>Sub text. { "Progress", (float)amount / 100f }, //<float>Progress. From 0.0 to 1.0. }; AdvancedStatus?.Call("UpdateContent", player.userID.Get(), parameters); //Calling the UpdateContent method with the passing of BasePlayer/playerID and a dictionary containing the required parameters. DeleteBar: Used to remove the bar for a player. There are two methods for removing a bar by ID: with specifying a particular player; To call this method, you need to pass 3 parameters. The first one is BasePlayer or <ulong>playerID. The second one is Id of your bar and the third one is name of your plugin. without specifying a particular player (which removes it for all players) To call this method, you need to pass 2 parameters. The first one is Id of your bar and the second one is name of your plugin. AdvancedStatus?.Call("DeleteBar", player.userID.Get(), barID, Name); //Calling the DeleteBar method with the passing of BasePlayer/playerID, ID of the bar and the name of your plugin. AdvancedStatus?.Call("DeleteBar", barID, Name); //Calling the DeleteBar method with the passing of ID of the bar and the name of your plugin. If you try to delete a bar that doesn't exist, nothing bad will happen. So feel free to delete the bar without checking its existence. P.S. When unloading your plugin, there is no need to manually delete bars for players, AdvancedStatus will handle it automatically. DeleteCategory: Used to remove all bars associated with the plugin's category. To call the DeleteCategory method, you need to pass 2 parameters. The first one is category and the second one is name of your plugin. AdvancedStatus?.Call("DeleteCategory", "Default", Name);//Calling the DeleteCategory method by passing the category and name of your plugin DeleteAllBars: Used to remove all bars associated with the plugin. To call the DeleteAllBars method, you need to pass only 1 parameter. It is name of your plugin. AdvancedStatus?.Call("DeleteAllBars", Name);//Calling the DeleteAllBars method, passing the name of your plugin GetTotalClientBars: Used to get the number of client bars for the player. To call the GetTotalClientBars method, you need to pass only 1 parameter. It is BasePlayer or <ulong>playerID. (int)AdvancedStatus?.Call("GetTotalClientBars", player.userID.Get());//Calling the GetTotalClientBars method, passing the name of BasePlayer/playerID GetTotalPlayerBars: Used to get the number of active custom bars for the player. To call the GetTotalPlayerBars method, you need to pass only 1 parameter. It is BasePlayer or <ulong>playerID. (int)AdvancedStatus?.Call("GetTotalPlayerBars", player.userID.Get());//Calling the GetTotalPlayerBars method, passing the name of BasePlayer/playerID LoadImages: Used to check if the local images specified in the list are loaded. If any of the images are not loaded but their files exist in the images folder, the plugin will load them. To call the LoadImages method, you need to pass only 2 parameters. The first one is the <List<string>>list of image's name and the second one(optional) is <bool>force, which, if set to true, will force reload the image even if it already exists. AdvancedStatus?.Call("LoadImages", list, false);//Calling the LoadImages method, passing a list of image names LoadImage: Used to check if the local image is loaded. If the file is not loaded and exists in the images folder, the plugin will load it. To call the LoadImage method, you need to pass 2 parameters. The first one is the <string>image's name and the second one(optional) is <bool>force, which, if set to true, will force reload the image even if it already exists. AdvancedStatus?.Call("LoadImage", imgName, false);//Calling the LoadImage method, passing an image's name CopyImage: Used to create and load a copy of an existing image. To call the CopyImage method, you need to pass 3 parameters. The first parameter is the <string>source image's name, the second parameter is the <string>new image's name and the third one(optional) is <bool>force, which, if set to true, will force copy and reload the image even if it already exists. AdvancedStatus?.Call("CopyImage", "ZoneStatus_Default", "ZoneStatus_NewZone", false);//Calling CopyImage, passing the source image name and the new image name. DeleteImages: Used to delete a list of images and their files. To call the DeleteImages method, you need to pass 2 parameters. The first one is the <List<string>>list of image's name and the second one(optional) parameter is <bool>deleteFile, which, if set to true, will delete image's file too. AdvancedStatus?.Call("DeleteImages", list, true);//Calling DeleteImages, passing a list of image names. DeleteImage: Used for removing the image and the image file. To call the DeleteImage method, you need to pass 2 parameters. The first parameter is the <string>image's name and the second one(optional) parameter is <bool>deleteFile, which, if set to true, will delete image's file too. AdvancedStatus?.Call("DeleteImage", "ZoneStatus_NewZone", true);//Calling DeleteImage, passing the image name. BarExists: Used to check if the specified bar exists. To call the BarExists method, you need to pass 3 parameters. The first one is BasePlayer or <ulong>playerID. The second one is Id of your bar. And the third one is name of your plugin. (bool)AdvancedStatus?.Call("BarExists", player.userID.Get(), barID, Name);//Calling the BarExists method with the passing of BasePlayer/playerID, ID of the bar and name of your plugin. InBuildingPrivilege: Used to check if the player has authorized building privileges. To call the InBuildingPrivilege method, you need to pass BasePlayer or <ulong>playerID. (bool)AdvancedStatus?.Call("InBuildingPrivilege", player.userID.Get());//Checking if the player has Building Privilege.

A server-side interaction framework for Rust plugin developers. It traces the player's look target, splits USE into quick / long presses, serves the game's native radial pie menus with per-plugin lifecycle, and adds server-authoritative attack input — everything another plugin needs to build console-quality interactions without touching UI libraries or hooking input itself. It is a foundation, not a feature: install it, and your plugins gain a ready-made interaction layer — look-target detection, crosshair feedback, pie menus with automatic cleanup, and a safe dispatch pipeline that never lets a misbehaving callback take down the server. Features Quick / long USE dispatch — server-side detection from OnPlayerInput: a press under 0.2s fires the quick interaction, a held press opens the pie menu. Mirrors vanilla quick/long-press behavior with no client-side input hooks. Look-target tracing — 2m reach across 14 physics layers (deployables, ragdolls, vehicles, constructions, terrain, bushes and more) with proper line-of-sight validation, nearest-valid-entity selection, and full ray pooling for zero garbage. Native pie menus — options render through the game's own radial menu system (CustomPie network message): name, description, sprite or skin image ID, color with built-in color modes, disabled/selected states. No CUI, no image libraries. Nested sub-menus — options can drill into sub-menus and walk back, built lazily per level through callbacks. Per-plugin ownership — menus opened via ServerInteraction.For(this) hang off the owning plugin's context and are unregistered as a unit when that plugin unloads, when the player disconnects, when a new menu replaces them, or on click. Orphaned console commands are impossible. Interaction crosshair — a HUD crosshair indicator appears when the looked-at entity is interactable, prewarmed per connection with cached, change-only CUI payloads so toggling costs nothing. Server-authoritative attacks — held entities implementing IServerAttack get FIRE_PRIMARY read by the server itself, not from a client-sent launch RPC: press / hold / release callbacks, configurable hold-to-fire time, one shot per hold. Item-side interactions — an abstract ItemModInteraction lets active-slot items define quick-use behavior and their own pie menus, with automatic fallback from the look target to the held item. Loot entity ID override — any entity can substitute the entity ID the loot window opens on, letting you proxy or virtualize containers without breaking the client's loot UI. Safe callbacks — consumer plugin exceptions in menu callbacks and option populators are caught and logged; the menu still closes and the console executor survives. Zero configuration — no config, no data files, no permissions to grant. Drop it in and load. Integrations Carbon — built for Carbon, with a Harmony patch into Carbon's ModLoader.UninitializePlugin so consumer plugins get automatic cleanup on unload. Native Rust UI — pie menus and the crosshair use the game's built-in systems (CustomPie, CUI), no UI dependency plugins. Consumer plugins — anything you build against IInteractionEntity, IServerAttack, ItemModInteraction, or ILootEntityIdOverride. API for developers Implement opt-in interfaces on your entities — the framework registers them automatically during its input pass: IInteractionEntity — quick USE (CanQuickUse → OnUse) and long USE (CanLongUse → GetMenuOptions) on any entity the player looks at. IServerAttack — hold-based attacks on the held entity: AttackHoldTime (0 = instant), OnServerAttackPress for charge-up cues, OnServerAttack to fire, OnServerAttackRelease with held duration. ItemModInteraction — the item-mod counterpart for items in the active slot. ILootEntityIdOverride — GetLootEntityId(player) returns the NetworkableId the client's loot window should open on. PieMenuOption — one menu entry: text, description, sprite/image, color and color mode, disabled/selected flags, a leaf Function, or NextMenuOptions/PrevMenuOptions for sub-menus. Open menus through your plugin's context, CID-style: this.ServerInteraction().PieMenus.Open(player, options) — owned menu, auto-cleanup on your plugin's unload. ServerInteraction.OpenPieMenu(player, options) — ownerless, cleaned up by the standard replace/disconnect/click rules. ServerInteraction.IsPieMenuOpen(player) / PieMenus.IsOpen(player) / PieMenus.Close(player) — state checks and explicit close. FAQ What does the plugin do on its own? Nothing visible beyond crosshair hints — it's a framework. Every interaction, menu and attack comes from consumer plugins you install or write against its API. Can plugins use it without Carbon's pie-menu features? The pie menus go straight through the game's native CustomPie message, so they render exactly like vanilla radial menus. What happens if my callback throws? The exception is logged, the menu closes cleanly, and the server's console executor keeps running. A buggy consumer plugin cannot brick input handling. How do you keep console commands secure? Menu options bind to hidden server commands with unique random GUID names, registered only while the menu is open and removed the moment it's clicked, replaced, or the player leaves. Players can't invoke stale commands. Compatibility notes The loot entity ID override uses a compiled IL pattern match on PlayerLoot.SendUpdate; if the game build reshuffles that method, the patch fails safe with a logged error and vanilla behavior continues. Support Discord: https://discord.gg/8nztXhvgDe — bug reports and API questions welcome.

Need a robust foundation for creating custom Rust entities and prefabs from your own plugins? ServerPrefabs is a powerful library plugin for Oxide/uMod and Carbon that lets plugin developers register custom server-side prefabs and entities, with support for custom networking, persistent save/load, built-in inventories, and runtime scaling. What Is ServerPrefabs? ServerPrefabs is not a standalone gameplay plugin — it’s a developer library. It does nothing on its own. Instead, other plugins use its API to define, register, and manage their own custom prefabs and entities on the server. If you’re building advanced Rust systems with custom deployables, persistent world objects, or specialized networked entities, ServerPrefabs provides the core framework you need. Core Features Custom Server-Side Prefab Registration: Create and register fully custom prefabs directly from your plugin. Once registered, they become usable and spawnable by the game. Custom Entity Component Support: Attach your own BaseEntity-derived component to a prefab and define custom entity logic exactly how your plugin needs it. Persistent Save / Load System: Custom entity save data is written to: oxide/data/ServerPrefabs/<prefab>.sav Custom Network Serialization: Provide your own network save behavior so clients receive the exact entity state they need. Arbitrary Per-Entity Data Storage: Implement stream-based save/load methods for custom entity state and plugin-specific data. Built-In Inventory Component: Use EntityInventory for a built-in, network-replicated item container with configurable capacity and optional handler callbacks. Runtime Scaling Support: Use Scaler to persist and replicate transform scale for custom entities. Lightweight Stub Entities: Use StubEntity for lightweight, non-saving entities with RPC and save event hooks, plus a helper factory for cloning visuals and bounds from a base prefab. Per-Entity Behavior Flags: Opt into special behaviors such as disabling disk saving or excluding entities from spawn command lists via CustomFlags. Public API The main entry point is: ServerPrefabs.For(plugin) This returns a per-plugin context you can use to create and register prefabs. Example usage: var prefab = ServerPrefabs.For(this) .CreatePrefab("my_thing") .AddEntityComponent<MyEntity>(clientPrefabId) .Register(); This workflow allows a consumer plugin to: Create a custom prefab Attach a custom BaseEntity component Register it with the game Make it available for spawning and runtime use Bundles Use CreateBundle() to group multiple prefabs so they are registered and loaded together as one save batch. This is ideal when one custom entity references, depends on, or is parented to an entity from another prefab. Registers all prefabs first Preloads all save files in one batch Spawns all bundled entities in a single pass You can also add an existing prefab with bundle.Add(prefab). If one prefab fails to register or load, the rest of the bundle will still continue. var bundle = ServerPrefabs.For(this).CreateBundle(); bundle.CreatePrefab("station").AddEntityComponent<StationEntity>(stationClientId); bundle.CreatePrefab("module").AddEntityComponent<ModuleEntity>(moduleClientId); bundle.Register(); Extension Interfaces ICustomPrefab Calls OnCustomPrefabRegistered() once the prefab is registered. ICustomEntity Calls OnCustomEntityRegistered() when the custom entity is registered. ICustomEntity.SaveForNetwork Lets you customize the network proto sent to clients. ICustomEntity.SaveData Adds Save(Stream) and Load(Stream) support for arbitrary per-entity data. Entity Flags Optional behaviors are controlled through the EntityFlags CustomFlags property on ICustomEntity. By default, the value is EntityFlags.None, so you only override it when special behavior is needed. The property is named CustomFlags specifically to avoid colliding with BaseEntity.Flags. Example: class MyEntity : BaseEntity, ServerPrefabs.ICustomEntity { public void OnCustomEntityRegistered() { } public ServerPrefabs.EntityFlags CustomFlags => ServerPrefabs.EntityFlags.DisableSaving | ServerPrefabs.EntityFlags.NoSpawnCommand; } Available flags: EntityFlags.None No special behavior. EntityFlags.DisableSaving Excludes the entity from disk saving by setting enableSaving = false. EntityFlags.NoSpawnCommand Prevents the entity from being added to the spawnable-entity command list. Included Components EntityInventory A built-in, network-replicated item container. Set Capacity and optionally assign an EntityInventory.IHandler with callbacks such as: OnCreated OnInventoryDirty OnItemAddedOrRemoved ItemFilter Scaler Persists and replicates entity transform scale. StubEntity A lightweight, non-saving entity with onRpcMessage and onSave events, plus a StubEntity.Create<T>(...) factory for cloning visuals and bounds from a base prefab. Installation Drop ServerPrefabs.cs into: oxide/plugins/ or carbon/plugins/ The server will compile and load it automatically. On first load, a config file is generated. Dependent plugins can reference it via: [PluginReference] Plugin ServerPrefabs; or the static API Configuration Configuration file: oxide/config/ServerPrefabs.json Allow outdated saves Default: false Allows loading .sav files written by a different Rust save protocol version. Enable debug logging Default: false Enables verbose [ServerPrefabs] [DEBUG] log output for troubleshooting. Safe Config Recovery: If the config becomes invalid or unreadable, it is automatically backed up as ServerPrefabs.json.bak. A new default config is then generated, so a broken manual edit won’t silently destroy your settings. Compatibility Notes ServerPrefabs uses Harmony IL transpilers against Rust internals, specifically: SaveRestore.Load SaveRestore.WriteEntities Because these patches rely on specific internal instruction patterns, a Rust update can break compatibility. After a force wipe or game update, check the server console during load for errors like: Phase 1 failed! Phase 2 failed! Phase 3 failed! or other patch-related errors If those appear, the plugin likely needs to be updated to match the current Rust version. Why Use ServerPrefabs? Create advanced custom entities directly from your plugin Add server-side prefabs with persistent save/load support Customize network behavior for non-standard entities Use built-in inventory and scaling systems instead of building your own Control save and spawn-list behavior with simple entity flags Perfect for framework plugins, deployables, machines, automation systems, and persistent world objects ServerPrefabs is a core utility library for Rust plugin developers who want deeper control over custom entities and prefab-based systems. One library. Custom prefabs. Persistent entities. A powerful base for advanced Rust modding.

Stop writing plugin code in a single file. Alloy is a folder-plugin compiler for Oxide/uMod and Carbon. It turns a folder of C# source files into a single living plugin — compiled in-memory with Roslyn, loaded without a restart, and hot-reloaded in under a second every time you save. Write code in your IDE. Hit save. The plugin is already running the new version. What Is Alloy? Alloy is a developer toolchain — it does nothing for players on its own. Everything it does is for you: faster iteration, real project structure, and debuggable code on a live server. A regular Rust plugin is one .cs file. That works until it doesn't — 5,000 lines in, navigating the file becomes the slowest part of development. Alloy adds the folder plugin format: multiple files, nested folders (Core/, UI/, …), conditional compilation, dependencies and assembly references — all described in a single alloy.json manifest. Edit any .cs file in the folder and Alloy recompiles and hot-reloads the plugin automatically. Classic single-file plugins keep working untouched. Alloy only manages folders that contain an alloy.json. Core Features Folder Plugins A plugin is a folder, not a file. Split code across as many .cs files and subfolders as you want — Alloy compiles them into one plugin. Hot Reload on File Change A file watcher rebuilds the plugin ~300–500 ms after you save. No restart, no console commands, no waiting. Atomic Reload with Rollback A broken edit never kills the running version — the last good build keeps working until you fix the errors. In-Memory Roslyn Compilation The real Roslyn compiler, in-process: full C# language features, #if directives, glob-based file selection. Real Stack Traces PDBs are generated for every build, so exceptions show the actual File.cs(42,17) — no more guessing from a merged blob. Manifest-Driven Configuration alloy.json controls included/excluded files (globstar patterns), plugin dependencies (requires), assembly references and conditional-compilation symbols (define). Dependency-Aware Lifecycle requires plugins load in dependency order. A plugin whose dependency is missing waits instead of failing — and loads itself the moment the dependency appears. Unloading a dependency unloads everything that depends on it. Conditional Compilation Alloy always defines ALLOY plus OXIDE or CARBON depending on the framework — one codebase targets both. One Core, Both Frameworks A shared Alloy.Core (netstandard2.0) with thin adapters per framework — identical behavior and manifest format on Oxide and Carbon. Console Commands alloy.list, alloy.load, alloy.unload, alloy.reload, alloy.build, alloy.verbose — full lifecycle control without leaving the console. The Folder Format oxide/plugins/MyPlugin/ ├── alloy.json ← manifest (required) ├── MyPlugin.cs ← entry class ├── Core/ │ └── Storage.cs └── UI/ └── Panels.cs { "name": "MyPlugin", "files": ["**/*.cs"], "exclude": ["Tests/**"], "requires": ["ServerPrefabs"], "references": ["0Harmony", "Facepunch.Steamworks"], "define": ["DEBUG"], "reload": { "watch": true, "debounceMs": 500 } } Dependencies and assembly references are declared only in the manifest — Alloy does not parse // Requires: / // Reference: directives in sources. [Info]/[Description] attributes remain the source of plugin metadata — the manifest never duplicates them. Debugging Compiler Diagnostics Real folder-relative paths: MyPlugin/UI/Panels.cs(42,17): error CS1002: ; expected — in the console and in the log. Runtime Exceptions Exceptions point to real files and lines thanks to generated PDBs. Log File logs/Alloy.log — Carbon FileLogger format: [yyyy.MM.dd HH:mm:ss] message. Verbose Mode alloy.verbose on — detailed pipeline logging: scan, globs, compilation, registration, watcher events. Installation Download Alloy.zip from this page and extract it. Inside are two folders — Oxide/ and Carbon/ — that mirror your server's directory layout. Pick the one for your framework and copy its contents into your server's root folder, then restart the server. The two folders never conflict. Oxide Copy the contents of Oxide/RustDedicated_Data/Managed/ into RustDedicated_Data/Managed/: Oxide.Ext.Alloy.dll, Alloy.Core.dll and the bundled Roslyn assemblies (Microsoft.CodeAnalysis.dll, Microsoft.CodeAnalysis.CSharp.dll, System.Collections.Immutable.dll, System.Reflection.Metadata.dll, …). Restart the server — the log will show Alloy initialized. Carbon Copy the contents of Carbon/carbon/extensions/ into carbon/extensions/: Alloy.dll and Alloy.Core.dll. Roslyn is already loaded by Carbon — no extra DLLs needed. Restart the server. Alloy plugins are registered in their own Alloy ModLoader package — one group in Carbon's plugin lists, never mixed with single-file plugins. Console Commands Command Action alloy.list Folder plugins: state, folder name, file count, build time alloy.load <name> Build and register the plugin alloy.unload <name> Disable and unload alloy.reload <name> Rebuild with atomic rollback alloy.build <name> Compile only — verify errors without loading alloy.verbose on|off Toggle detailed pipeline logging Perfect For Plugins that have outgrown a single .cs file Iterating on a live server without restarts Sharing one codebase between Oxide and Carbon builds of the same plugin Structured plugin projects with internal modules (Core, UI, Data…) Debugging with real file/line stack traces Framework and library plugins with complex internals Good to Know Alloy is a development tool — run it on your dev/staging server, not as a player-facing feature. Only folders with an alloy.json are managed; everything else behaves exactly as before. No // Requires: / // Reference: comment parsing — the manifest is the single source of truth by design. Alloy is a core developer tool for Rust plugin authors who want real project structure and instant feedback on a live server. Folder plugins. One-second iteration. Real stack traces. Development the way it should have been.

This plugin demonstrates the integration with the AdvancedStatus plugin. It displays the amount of a specific item in the player's inventory in the status bar. In this case, it's Scrap, to track a different item, replace the itemID value on line 47 with the ID of the desired item. This plugin can be downloaded by plugin developers as a reference to understanding how to work with the AdvancedStatus and by server owners to easily display desired items in the status bar.