All Activity

Custom & animated item icons, rendered server-side Give any item on your server a custom or animated icon — rendered server-side, streamed to players, no client mods needed. DynamicItemIcon repaints the icons of any item — vanilla items pulled from the CDN, Workshop skins fetched straight from Steam, or your own PNG files — and animates them right on the server. Effects, presets, keyframe clips and per-frame rendering all run off-thread, so your TPS won't feel it. 22 effects 11 presets 30+ API methods 25 commands zero config Features Any icon, any source Vanilla items · Workshop skins by ID · your own PNG files Every icon streams to players as a server-side sprite — nothing to install on the client. Effect chain language Chain effects with commas, tune each with named args: fx=glitch:3,neon:0x00ffcc From invert to pixelsort — 22 built-in effects, stacks compose freely. 11 ready presets corrupted · cursed · retro · golden · frozen · cartoon · vhs · cyber · void · holo · inferno One name — a tuned stack of effects. Mix presets into chains as building blocks. Keyframe clips Author animations as keyframe timelines: Per-key effect clips · frame indices · 5 easing types · loop / once / ping-pong Persistent bindings A bound animation rests on its frame 0 — players see the animated icon immediately on relog, dedup per session. Warm cache Frame-0 icons regenerate instantly at wipe/recompile — no cold stutter. Cache invalidation tracks code edits via IL-signature + MVID. Compositing Stack layers from item, skin or crc sources. 5 blend modes — over · add · multiply · screen · subtract — plus per-layer fx and opacity. CustomItemDefinitions support Overrides sprites for custom items out of the box. Batch export di.batchfx <png> runs any PNG through all 22 effects and 11 presets in one shot. 34 PNG files written to disk — preview every look before you bind. Targeted export & hue recolors di.exportfx rifle.ak hueshift:60 hueshift:120 — each fx argument lands as its own PNG file. one command → many variants for icon packs and skin shops. Wipe-safe OnNewSave clears state, icons restore at next boot. Atomic writes · debounced saves · data files stay clean. Installation Drop DynamicItemIcon.cs into your plugins/ folder. Get a GSLT token (required for Workshop skin sources): log in at steamcommunity.com/dev/managegameservers, create a token for App ID 252490 (Rust). Add it to your launch script: +server.login_token <YOUR_TOKEN> Restart the server. The token is read once at Steam login — a hot reload will not pick up a newly added launch argument. Start adding icons: di.skin <workshopId> to preview a Workshop skin, di.fx rifle.ak invert to test an effect. Steam auth fallback: token missing or invalid → the plugin still boots with a warning, server stays on anonymous login; Workshop fetching degrades gracefully to the vanilla icon. Vanilla icons and your own PNGs work without any token. For developers 30+ API methods, all callable from other plugins: Fetch & process: API_GetSkinIcon, API_GetItemIcon, API_ProcessSkinIcon, API_ProcessItemIcon, API_ProcessItem Composite: API_CompositeIcon, API_CompositeItem Animate: API_AnimateItem, API_PlayClip, API_BindClip, API_BindAnimation, API_UnbindAnimation, API_StopAnimation, API_StopAllAnimations Author clips: API_RecordClip (×2 variants), API_DeleteClip Register effects/presets: API_RegisterEffect (×2, owned), API_RegisterPreset (×2) Query: API_GetCRC, API_GetStoredIcons, API_ListEffects, API_ListPresets, API_ListClips, API_ListAnimations Admin commands 25 console commands under di.*: Items & skins: di.item, di.skin, di.fx, di.skinfx, di.processitem, di.compose Registry: di.effects, di.icons Animations: di.animate, di.animbind*, di.animstop, di.animlist, di.warmbind Clips: di.cliprecord, di.cliprecordkeys, di.clipplay, di.clipbind, di.cliplist, di.clipshow, di.clipdelete Exports: di.batchfx <png> — every effect, di.exportfx <png> <fx...> — targeted variants Permissions dynamicitemicon.admin — grants the full di.* command set. Configuration Deliberately minimal: one config option. Zero-config by design — everything interesting is done over the API and commands. Data lives under data/DynamicItemIcon/: processed/, vanilla/, skinned/, batch/ and export/. Compatibility & limits Source fetches time out and fall back to the vanilla icon — a failed download never bricks your items. Effect owners pause/resume cleanly: owner plugin unloads → its bound animations keep playing from cache. Max 1024 animation frames per clip; client preload throttled (≈40 PNG/s) so relogs don't spike players. FAQ Do players need to install anything? No — icons are server-rendered PNGs streamed through Rust's native icon pipeline. Will it break my server without the Steam token? No — falls back to anonymous login with a warning; only Workshop fetching degrades. What happens after a wipe? Bindings clear on the new save, cached icons restore automatically at boot. Does it lag the server? Frame generation and PNG encoding run on the thread pool; the main thread only decodes the source once. Can other plugins add effects? Yes — API_RegisterEffect accepts their own delegates; ownership tracking handles their reloads. Support & credits Written by 0xF. Join https://discord.gg/8nztXhvgDe for support and updates.

Never lose a loadout for good. InventoryBackup automatically saves a player's full inventory the moment they die — no matter the cause — and lets you restore it with a single chat command. Perfect for servers that want a safety net against unfair deaths, bugs, exploits, or grief scenarios, without disabling normal looting. Key Features - Backs up on every death — PvP, PvE, NPCs, animals, suicide, fall damage, radiation, drowning, starvation, dehydration, bleeding, poison, explosions, electric shock, Patrol Helicopter, Bradley APC. If a real player dies, it's recorded. - Corpses stay fully lootable — the plugin doesn't touch loot on death. Your server's normal looting/raiding experience is untouched; the backup is purely a safety net. - Zero-duplication restore — /restore moves the items that are still physically in the corpse (and in the separately-dropped equipped backpack) directly into the player's inventory. Already looted something yourself or lost it to another player? Restore accounts for that automatically instead of handing out a duplicate copy. Only if the corpse no longer exists at all (destroyed, despawned, server restarted) does it fall back to recreating the items from the saved backup data. - Handles equipped backpacks correctly — Rust drops an equipped Large/Small Backpack as its own separate object next to the corpse; InventoryBackup finds and restores it too, not just the main corpse. - Full item fidelity — condition/durability, skins, and nested contents (attachments, magazines, ammo) are preserved and recreated exactly. - Two independent Discord webhooks: - Loss webhook — posts an embed for every death: victim, killer (with SteamIDs), death cause, coordinates, timestamp, item count, and the exact /restore <id> command to use. - Command log webhook — separately logs every time /restore is actually used: who ran it, for which player, how many items, how many had to be dropped (full inventory). - Built-in localization — English, German, and Russian chat messages out of the box, automatically served based on each player's client language via Oxide's lang system. - Performance-conscious — O(1) backup lookups, O(1) corpse lookups via a cached reference (with automatic fallbacks), and batched/delayed data saving so busy servers don't take a disk-write hit on every single death. - Configurable backup retention per player, so data files don't grow indefinitely. ------------------------------------------------------------------------------------------------ Chat Commands CommandDescriptionPermission /restore <id>Restores backup <id> to its owner (must be online). Admins can restore any backup; players can only restore their own.inventorybackup.admin (any backup) or inventorybackup.use (own backups only, if enabled in config) /restorelist <player name or SteamID>Lists all backup IDs for a player, with timestamp, item count, and status (open/restored).inventorybackup.admin /backupinfo <id>Shows the full item list of a specific backup.inventorybackup.admin or inventorybackup.use (own backups only) Permissions inventorybackup.admin -> Full access: restore, list, and inspect any player's backups. inventorybackup.use -> Players can restore and inspect only their own backups via /restore and /backupinfo (requires Allow Players To Restore Their Own Backups enabled in the config). ------------------------------------------------------------------------------------------------- Setting up a Discord Webhook 1. In Discord, go to your channel's Edit Channel → Integrations → Webhooks → New Webhook. 2. Copy the webhook URL. 3. Paste it into Discord Webhook URL (and/or Discord Log Webhook URL) in the config. 4. Set the matching Enable... option to true and reload the plugin. Notes - Restoring only works while the target player is online. - A backup can only be restored once — trying again returns "already restored." - If the original corpse (and any separately dropped backpack) is gone by the time /restore runs, the plugin falls back to recreating the items from the saved data, so nothing is ever permanently lost due to a despawned corpse.

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.

What is Owned Livestock Tracker? Made with the help of AI Owned Livestock Tracker is the ultimate administrative and performance-control utility for Rust server owners who want to manage player-owned livestock, ranching loops, and animal farms. Large-scale animal farms are notorious for causing server-side entity lag and frame drops; this plugin acts as an automated custodian to protect your server's performance while keeping players fully informed. Key Capabilities Automated Population Control: It continuously tracks animal densities around Tool Cupboard (TC) zones. If a player’s farm exceeds your configured threshold, the plugin automatically culls the excess down to a stable line, intelligently targeting the oldest entities first. Performance Protection: Instead of constantly draining server resources by scanning the map, it uses an optimized, event-driven framework that only triggers when animals are spawned or killed. Admin Dashboard HUD: Admins gain access to a sleek, fully interactive, native in-game UI menu. From this menu, you can see a paginated list of every farm on the server, who owns it, what grid it is in, and exactly how many animals are there. Targeted Moderation: Within the UI, admins can "inspect" any specific TC zone, view a list of every animal inside it, instantly kill individual animals by network ID, or wipe an entire problematic lag-source using a "Purge All" button. Discreet Admin Slaughter Logs: To prevent offline griefing or unmonitored animal slaughter, the plugin broadcasts a real-time message to active administrators and authorized moderators when an animal is killed, logging who did it and the exact map grid where it happened—completely hidden from regular players. Player-Friendly Notifications: When the automated system culls an overcrowded farm, it displays a professional, immersive full-screen warning UI to the base owner when they are online, explaining the server limit so they understand exactly why it happened without needing to open an admin support ticket. Command Directory Chat Commands /ol Permission: ownedlivestocktracker.admin / Server Admin Description: Launches the main overview administration matrix dashboard. This maps out active zones, showing coordinates, current ownership links, and aggregated livestock entities grouped under Tool Cupboards. Console Commands ownedtracker.ui.testwarning Permission: Admin Only Description: Instantly fires a sandbox version of the LivestockWarningUI modal onto your screen, simulating a population threshold violation in Grid A1 so you can inspect the design layout. ownedtracker.ui.close Description: Safely terminates the root dashboard UI and flushes active navigation state references from server memory. ownedtracker.ui.closewarning Description: Destroys the automated population overflow warning notification wrapper on the target player's screen. ownedtracker.ui.page <1 / -1> Description: Handles grid pagination navigation by shifting your dashboard list view index offset forward or backward. ownedtracker.ui.inspect <tcId> Description: Swaps view perspectives from global server zones into a localized inspection window targeting a specific Tool Cupboard's network asset ID. ownedtracker.ui.delete <netId> Description: Issues a direct server invocation to instantly cull and kill a specific tracked livestock entity by its Network ID. ownedtracker.ui.purgeuser <tcId> Description: Runs an iterative filter scan on active server entities to slaughter every matching livestock animal currently bound to that specific Tool Cupboard radius zone. Configuration & Customization Guide Upon your first launch, a configuration file will automatically be generated in your server files under oxide/config/OwnedLivestockTracker.json. Open this file to easily scale limits, adjust colors, or fine-tune entity definitions to match your server's needs: { "MaxPopulationCap": 50, "TargetCullCount": 35, "WarningPanelColor": "0.15 0.05 0.05 0.98", "MainPanelColor": "0.08 0.08 0.1 0.98", "TrackedPrefabs": [ "cow", "bull", "calf", "sheep", "lamb", "chicken", "horse", "scarecrowrowsheep", "chicken.population.item" ] } Use code with caution. Property Explanations: MaxPopulationCap (int) — The maximum number of allowed tracked animals inside a single Tool Cupboard radius zone before an automated server cleanup triggers. TargetCullCount (int) — The safe baseline target the system drops the animal population down to during an intervention. WarningPanelColor (string) — The RGBA background color format used to render the full-screen limit warning popup for players. MainPanelColor (string) — The RGBA background color layout configuration used to render the administrative overview dashboard grid. TrackedPrefabs (List) — A customized collection of lowercase prefab string targets monitored by the tracking engine. You can seamlessly add or remove custom animal mod prefabs here. OwnedLivestockTracker.cs