Search the Community

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.