flutes

Connect Vote System points to a Custom Rewards catalogue while preserving the familiar player vote-reward chat commands. At a glance Lightweight bridge between Vote System and Custom Rewards. Preserves /vote, /votes, and historical reward-command aliases. Verifies both dependency contracts and the exact shared reward type before opening the UI. Reads the player's vote points from Vote System. Delegates reward eligibility, persistence, delivery, and UI rendering to Custom Rewards. Stores no separate player balance and performs no reward delivery itself. How it helps Vote Reward keeps the player experience simple while each required product retains one clear responsibility. Vote System collects and attributes votes. Custom Rewards owns the catalogue, claim state, and delivery. Vote Reward checks that the two sides agree before exposing the combined flow. Key features Configurable player chat aliases. Configurable Custom Rewards type and CUI parent. Contract and capability checks on load and dependency reload. Exact reward-type agreement with Vote System. Safe handling of missing, malformed, thrown, or mismatched dependency results. Structured UI-open result with clear failure diagnostics. No duplicated player storage. How it works When a player runs a configured command, Vote Reward: verifies Vote System and Custom Rewards are loaded; confirms Vote System contract V1 and its vote-points capability; confirms Custom Rewards contract V2 and its owner-points and UI-open capabilities; confirms both products use the configured reward type; reads the player's points from Vote System; asks Custom Rewards to open the enabled catalogue for that player. { "CustomRewards reward type": "VoteSystem", "Commands for show UI": [ "vote", "votes", "vote_rewards" ], "UI parent": "Overlay" } Requirements and compatibility Included required components The download contains the complete matching stack: Custom Rewards 2.0.4 — the catalogue, UI, claim state, and delivery service. Vote System 2.1.3 — provider polling, identity attribution, and points. Vote Reward 2.1.4 — the player command bridge. A preconfigured enabled VoteSystem catalogue, English catalogue text, and matching plugin configurations. Custom Rewards and Vote System remain required at runtime, but the exact matching deployables are included in this Vote Reward bundle. Optional dependencies Vote Reward has no optional dependency. Economics is optional for Vote System, not for this bridge. Without either required dependency, with an unavailable capability, or with different reward-type names, Vote Reward fails closed and does not open a partial UI. Setup Back up existing configuration and data files. Copy the included oxide directory into the server root. Review oxide/data/CustomRewards_rewards/VoteSystem.json; it is enabled but contains only a safe example reward. Grant customrewards.votesystem.use to eligible players. Add provider tokens and required identity bindings in oxide/config/VoteSystem.json, then enable only the configured providers. If reloading manually, load Custom Rewards, Vote System, then Vote Reward. Test with a non-administrator account. Commands and permissions The shipped chat aliases are /vote, /votes, /vote_rewards, /vote_reward, /votes_reward, and /votes_rewards. They all open the same configured Custom Rewards type. Vote Reward declares no separate permission. Access is controlled by the Custom Rewards dynamic permission for the selected type. With the default configuration, grant: customrewards.votesystem.use The historical mixed-case permission remains accepted by Custom Rewards for existing installations. Configuration highlights CustomRewards reward type must exactly match Vote System and an enabled Custom Rewards type. Commands for show UI accepts one or more safe chat command names. UI parent defaults to Overlay and must be an accepted always-present Rust CUI parent. Changing the reward type on an existing installation is an administrator migration. Update all three products together and verify the new catalogue before granting access. Practical tutorials Integration example: first /vote flow Give a test account a small number of Vote System points. Grant customrewards.votesystem.use. Join with that account and run /vote. Confirm the VoteSystem catalogue opens and displays the expected points and claim states. Claim one low-value item. Reopen the UI and confirm the claimed state remains visible. Integration example: dependency reload Reload Custom Rewards, then Vote System, then Vote Reward. Wait for the compatibility success message before testing /vote. If a dependency is absent during reload, the bridge remains unavailable until both checks succeed again. Troubleshooting Vote System is not loaded: restore or reload the bundled Vote System before Vote Reward. Custom Rewards is not loaded: restore or reload the bundled Custom Rewards and verify the VoteSystem type. Reward type mismatch: use the exact same case-sensitive type in Vote System, Vote Reward, and the Custom Rewards filename. Reward type is disabled: review the catalogue, enable it, and reload Custom Rewards. The command opens nothing: grant customrewards.votesystem.use and check for duplicate chat command registration. Points are zero: diagnose provider attribution and bindings in Vote System; Vote Reward does not collect votes. FAQ Does Vote Reward replace Vote System? No. Vote System is required and remains responsible for provider polling, identity attribution, and points. Does Vote Reward deliver items? No. Custom Rewards performs validation, persistence, delivery, and UI rendering. Can I use a different reward-type name? Yes, but the name must match in all three configurations and the Custom Rewards type must be enabled. Support Veuillez utiliser la section d'assistance Codefling en précisant les trois versions du produit, le framework, le type de récompense configuré, la commande exécutée et le premier diagnostic de compatibilité. N'incluez pas les jetons du fournisseur ni les fichiers de données du joueur.

Give players a predictable weekly raid schedule with configurable post-wipe protection, practical exclusions, and a public next-transition command. At a glance Define one raid-allowed window for every day of the week. Support windows that cross midnight. Evaluate the schedule with a fixed UTC offset. Keep protection active for a configurable period after a wipe. Allow TC-authorized players to damage their own protected building. Exclude reviewed prefabs or optional Zone Manager zones. Show localized state-change alerts and /raid_date status. Preserve safety when configuration or an optional integration is invalid. How it helps Raid Time Protection turns an informal raid-hours rule into a consistent server policy. Players can see whether protection is active and when the next change occurs, while administrators retain explicit scheduling and exclusion controls. Key features Seven-day schedule with hour, minute, and duration. Half-open windows: the start is included and the end is excluded. Fixed offset in minutes for servers that do not operate on UTC. Fractional post-wipe duration in hours. Built-in localized chat alerts without a required notification plugin. Cached prefab and Zone Manager exclusions. Recoverable migration of readable legacy configuration. Fail-closed behavior for eligible protected hits when policy evaluation is unhealthy. How it works When global protection is enabled, post-wipe protection takes priority. After that period, raiding is allowed inside the current weekly window and protected outside it. A window can continue into the next day. /raid_date The public read-only command reports the current protection state and the next scheduled transition in UTC. It does not change server state and requires no permission. Requirements and compatibility Rust server using Oxide or Carbon. Framework-provided JSON support. Zone Manager is optional. If it is absent, fails, or returns an unsupported result, no zone exclusion is applied. The current policy covers the documented owned-building path where the target is an owned DecayEntity with building privilege and the hit is attributed to a player. Do not interpret it as blanket coverage for every current Rust damage or entity path. Setup Back up the existing RaidTimeProtection.json. Install RaidTimeProtection.cs in the framework plugin directory. Reload the plugin and review the generated configuration. Set the fixed UTC Offset Minutes for your chosen schedule. Configure each daily start time and duration. Review wipe duration, prefab exclusions, and optional Zone Manager zone IDs. Test protected and allowed states with /raid_date. Keep the .v1.bak file if a legacy configuration is migrated. Commands and permissions Command | Purpose | Authorization /raid_date | Show whether protection is active and the next transition | Public, read-only Version 2.0.0 has no permission and no state-changing command. Configuration highlights This example uses UTC+2, keeps 48 hours of post-wipe protection, and allows Friday raiding from 22:00 until Saturday 04:00: { "Schema Version": 2, "UTC Offset Minutes": 120, "Wipe Protection Time (in hours)": 48.0, "Global Protection": { "Enabled": true, "Show Alert (recquires Notify plugin)": true, "(ZoneManager) Disabled protection zones": [], "Disable protection prefabs (optional)": [], "Friday": { "Stop Protection Hours": 22, "Stop Protection Minutes": 0, "Stop Protection Duration (in minutes)": 360 } } } The UTC offset is fixed and does not adjust automatically for daylight saving time. Update it manually when your local policy changes. Practical tutorials Tutorial: create an evening raid schedule Choose the schedule's fixed offset. For every day, set the local raid start hour and minute. Set the allowed duration in minutes. Use a duration that crosses midnight when needed; for example, 22:00 plus 360 minutes ends at 04:00 the next day. Reload and use /raid_date before, during, and after the window. Repeat the check after the next daylight-saving change if you use a non-zero offset. Tutorial: add a Zone Manager exclusion Install and verify Zone Manager separately. Add the exact zone ID to (ZoneManager) Disabled protection zones. Reload Raid Time Protection. Test an eligible owned-building hit inside and outside the zone. Remove the dependency and confirm the same target remains protected outside a healthy exclusion result. Authorization and exclusions For the documented eligible path: TC-authorized players may damage the target. Configured prefabs may bypass protection. A matching optional Zone Manager zone may bypass protection. Decay, electric, NPC player, Bradley APC, and CH47 damage are excluded from this policy. An otherwise eligible player-attributed hit is reduced to zero while protection is active. Indirect damage without an attributable player is not claimed as protected. Troubleshooting The schedule is shifted: verify UTC Offset Minutes; it is not a timezone name and does not follow daylight saving automatically. A cross-midnight window ends early: set one start plus the complete duration on the starting day. Protection remains active after wipe: verify the configured wipe duration and wipe timestamp. A Zone Manager exclusion is ignored: verify the exact zone ID and the integration response; failure preserves protection. A legacy configuration will not load: restore the backup, correct unreadable values, and keep the .v1.bak produced by a successful migration. FAQ What happens when global protection is disabled? A healthy configuration allows damage regardless of the weekly and post-wipe schedule. Invalid or unreadable configuration cannot disable protection. Is /raid_date restricted? No. The command is intentionally public so the raid schedule can be communicated to players. Does the plugin require Notify? No. State-change alerts use built-in server chat. The historical configuration label is retained for compatibility. Support Use the Codefling support section with the plugin version, framework, fixed offset, relevant daily window, protection state, target type, and a redacted configuration excerpt.

Dialogs is an innovative plugin designed to introduce dynamic interactions within Rust. These interactions, in the form of dialogues, can guide players, provide information, trigger specific events, or even interact with other plugins. One of Dialogs' standout features is its ability to respond based on players' previous actions or choices, offering a rich and tailored user experience. While integrating with NPCs is an appealing feature, Dialogs can operate independently, providing server administrators with significant flexibility. Key Features: Dynamic Interactions: Craft step-by-step dialogues, with questions and answers that can guide players or initiate specific interactions. Responsiveness to Player Actions: Dialogs can tailor interactions based on players' previous actions or choices, making each dialogue unique and dynamic. NPC Independence: While integration with NPCs is possible, Dialogs can function without them, offering versatility in how interactions are presented to players. Powerful API: Dialogs' API allows developers to initiate dialogues programmatically, offering deeper integration with other plugins or custom gameplay scenarios. Advanced UI Customization: Dialogs provides comprehensive user interface customization, allowing users to create the exact appearance they desire. However, this customization, while powerful, may require careful attention to detail. Configuration & Customization: Dialogue Files: Dialogues are stored in individual files within the oxide/plugins/data/Dialogs directory. Each file represents a distinct dialogue. API for Developers: Utilize the provided API to programmatically trigger dialogues, offering flexibility in how dialogues are employed. UI Configuration: With the capability to customize every aspect of the user interface, users can craft dialogues that perfectly match their server's aesthetic. However, this customization can be intricate and requires some familiarity with UI configuration. Dialogs is an essential tool for enriching the gaming experience by introducing dynamic and responsive interactions. Its adaptability to player actions and advanced UI customization make it an ideal choice for server administrators looking to add an extra dimension to their gaming world. Example Configuration Examples are available on this page (in the attached files) or in the downloaded archive. Commands /dialog_show <dialog_id> : (For admin), show dialog with specified id Documentation Creating Dialogues : Defining Dialogues: - Dialogues are defined in individual files located in the oxide/plugins/data/Dialogs folder. - Each file represents a distinct dialogue and is named following the format DialogData_DialogueName.json. Dialogue Structure: - A dialogue consists of questions and answers. - Each dialogue starts with one or more initial questions/answers ("Start Question/Answers"). - It can then have a set of questions/answers ("All Question/Answers") that can be triggered based on the answers chosen by the player. Understanding the Fields : "Start Question/Answers" & "All Question/Answers": - These fields contain a list of questions and answers. - Each question has content ("Question content"), required event states ("Recquired Event States"), and possible answers ("Responses"). Answers ("Responses"): Each answer has content ("Response Content"). It can trigger another question/answer ("Trigger Question/Answer Id"). It can also end the dialogue ("Trigger Exit Dialog"). Event states might be required to display this answer ("Recquired Event States"). Event states can be updated when this answer is chosen ("Event States Updated"). Hooks from other plugins can be called ("Plugins Hooks"). Console commands can be executed ("Console Commands"). FAQ How do I create an NPC and link it to a dialogue using Human NPC? To create an NPC, use the command npc_add in the console. Once the NPC is spawned, it will have a unique ID displayed (if not, check the human npc json file). To link this NPC to a dialogue: - Note down the NPC's unique ID. - Navigate to the oxide/plugins/data/Dialogs directory. - Open the DialogsNpcsData.json file and add a new entry with the NPC's unique id as the key and the dialogue ID as the value. - Save the file and reload the plugin. - Now, when players interact with this NPC, the linked dialogue will be triggered. - For more advanced settings like changing the NPC's appearance, name, etc., refer to the Human NPC plugin's documentation on the mod page. Tutorial: Creating Interactive Dialogues with Two NPCs using the Dialogs Plugin Introduction: This tutorial will guide you through creating interconnected dialogues for two NPCs in Rust using the Dialogs plugin. By the end, the dialogue of one NPC will influence the dialogue of the other. Step 1: Preparation Ensure the Dialogs plugin is installed on your server. Navigate to the plugin's data directory, typically located at oxide/plugins/data/Dialogs. Step 2: Setting up Bob's Dialogue In the oxide/plugins/data/Dialogs directory, create a new file named DialogData_Bob.json. Open this file with a text or JSON editor. Define the root of the dialogue: { "Dialog": { "Start Question/Answers": { "Intro": { "Question content": "Have you seen Alice?", "Responses": { "1": { "Response Content": "yes I saw it !", "Trigger Question/Answer Id": "AliceLocation" }, "2": { "Response Content": "No, never seen!", "Trigger Exit Dialog": true } } } }, "All Question/Answers": { "AliceLocation": { "Question content": "Was she near the river or the mountain?", "Responses": { "1": { "Response Content": "I saw him by the river", "Event States Updated": { "AliceRiver": true } }, "2": { "Response Content": "I saw him at the bottom of the mountain", "Event States Updated": { "AliceMountain": true } } } } } } } Step 3: Setting up Alice's Dialogue Create a new file named DialogData_Alice.json. Open this file and set up Alice's dialogue: { "Dialog": { "Start Question/Answers": { "Intro": { "Question content": "Hello! How can I assist you today?", "Responses": { "1": { "Response Content": "I saw Bob and I told him you were at the river", "Recquired Event States": { "AliceRiver": true } }, "2": { "Response Content": "I saw Bob and I told him you were near the mountain.", "Recquired Event States": { "AliceMountain": true } }, "3": { "Response Content": "Just enjoying the view. Take care!", "Trigger Exit Dialog": true } } } } } } Step 4: Associating the Dialogue with the NPCs Open the file oxide/plugins/data/Dialogs/DialogsNpcsData.json. Add a new entry for each NPC: { "id_of_bob": { "Dialog Id": "Bob" }, "id_of_alice": { "Dialog Id": "Alice" } } Step 5: Testing Your Dialogues Launch your Rust server. or realod Dialogs plugin Approach Bob and initiate a conversation (or use /dialog_show <dialog_id>) Depending on your responses to Bob, approach Alice and see how her dialogue changes based on the event states set during your conversation with Bob. You've successfully set up interconnected dialogues for two NPCs in Rust! This dynamic interaction showcases the power of the Dialogs plugin. You can expand upon this foundation to create even more intricate and engaging dialogues for your players. Support : You can also contact me via discord : https://discord.gg/JJnxFgP27G DialogData_Alice.json DialogData_Bob.json

The NpcOverlay plugin provides functionality to display overlays (text) above NPCs in the Rust game. This can be particularly useful for developers or server administrators who wish to provide additional context or information about an NPC, such as their name, role, or any other relevant details. Features Dynamic Overlays: Allows server administrators to set custom text overlays for NPCs. Event-Driven: The plugin responds to events when a player enters or exits the proximity of an NPC. Customizable Text: The text displayed can be customized for each NPC. Data Persistence: The plugin ensures that overlay settings for each NPC are saved and can be loaded across server restarts. Adding Overlays to NPCs 1. Installation Ensure the NpcOverlay plugin is installed on your server. 2. Setting Up Overlays: Navigate to the data file associated with the plugin, located in oxide/data/NpcOverlay.json. The structure of the JSON file is as follows: { "Overlays": { "MyNpcId": { "LangKey": "MyLangKey", "Color" : { "r":202, "g":49, "b":0, "a":1 }, "LocalOffset" : { "x":0, "y":1, "z":0 } } } } Replace MyNpcId with the NPC's ID and MyLangKey with the key you will use in the language file to represent the text you want to display. 3. Configuring Overlay Text Navigate to the language file, oxide/data/lang/yourlang/NpcOverlay.json. If it doesn't exist, create it. Add a new key-value pair where the key is the MyLangKey you used in the NpcOverlay.json file and the value is the text you want to display. Example: { "MyLangKey": "Hello, I'm Bob the Builder!" } 4. Spawning NPCs Use the appropriate command or method to spawn an NPC in your Rust server. Note down the NPC's ID. 5. Linking NPC to Overlay Add the NPC's ID and desired overlay text key to the NpcOverlay.json file. Save the file. 6. Testing Approach the NPC in-game. As you get close, you should see the overlay text appear above the NPC.Move away from the NPC, and the overlay should disappear. Usage Examples Quest Givers: Use overlays to identify NPCs that give out quests. E.g., "Quest Giver: Find the lost treasure!" Shopkeepers: Identify NPCs that sell items. E.g., "Shopkeeper: Buy rare items here!" Lore: Provide background information or lore about specific NPCs to enrich the game's story. Conclusion The NpcOverlay plugin is a simple yet powerful tool for server administrators and developers looking to enhance the player's experience in Rust.By providing contextual overlays above NPCs, players can have a clearer understanding of the role and significance of each NPC they encounter.Whether you're looking to guide players on their journey, provide lore, or simply add a touch of personality to your NPCs, NpcOverlay is a valuable addition to your server. Support : You can also contact me via discord : https://discord.gg/JJnxFgP27G

The PlayerEventStates plugin provides a system to manage and track event states for individual players and globally across the server. This system can be particularly useful for developers who wish to create conditional gameplay mechanics based on specific events or states. Features Player-Specific Event States: Allows tracking of individual player event states. Global Event States: Provides a mechanism to track global events that apply server-wide. API Access: Exposes several API methods for developers to interact with the system, making it versatile for integration with other plugins or custom scripts. Data Persistence: Ensures that both player-specific and global event states are saved and can be loaded across server restarts. API Methods (For Developers) GetEventStatePlayer_API(ulong playerId, string eventName); // Fetches the event state for a specific player. GetEventStateGlobal_API(string eventName); // Retrieves the global event state. SetEventStatePlayer_API(ulong playerId, string eventName, bool value); // Sets the event state for a specific player. SetEventStateGlobal_API(string eventName, bool value); // Modifies the global event state. PlayerHasRecquiredStates_API(ulong playerId, Dictionary<string,bool> states); //Checks if a player meets specific event state conditions. Usage Examples Quest Systems: If you're developing a quest system, you can use event states to track a player's progress. For instance, if a player completes a task, you can set an event state to true. This can then influence future interactions or dialogues with NPCs. Dynamic World Events: Global event states can be used to track server-wide events. For example, if a server-wide event like a festival is active, you can set a global event state. This could change interactions or available quests for all players. Conditional Dialogues: As mentioned, integration with the Dialogs plugin can lead to dynamic dialogues. An NPC might have different dialogues for players who have or haven't completed specific tasks. Setup & Configuration Ensure the PlayerEventStates plugin is installed on your server. The plugin will automatically create necessary data files in the oxide/data/PlayerEventStates directory. Developers can directly interact with the plugin using the provided API methods. Note for Developers: When developing with this plugin, pay special attention to the variables ending with _API. These are the methods you'll primarily interact with to get or set event states. Conclusion The PlayerEventStates plugin is a powerful tool for developers looking to add depth and dynamism to their Rust servers. By tracking both player-specific and global event states, it opens up a plethora of gameplay possibilities, especially when combined with plugins like Dialogs. Whether you're crafting a complex quest system or just want NPCs to recognize player achievements, PlayerEventStates is a valuable addition to your plugin arsenal. Support : You can also contact me via discord : https://discord.gg/JJnxFgP27G