.gif.6f3a363dfec70196781e00367ec6f978.gif)
flutes
-
Posts
143 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Reels
Everything posted by flutes
-
Hi, sorry for the late reply. VoteSystem itself doesn't register a player reward-claim chat command. It checks the voting sites and passes points to the enabled reward integration. If you're using the Vote Reward bundle, its separate VoteReward plugin provides /vote (plus the aliases configured in VoteReward.json), which opens the reward interface. If you installed VoteSystem and CustomRewards separately, use the show command configured for your CustomRewards reward catalogue instead; VoteSystem doesn't create that command for you. Please tell me which setup you're using if you're unsure, and I'll help you find the right command. -
Hi, no worries at all, and sorry for the very late reply! Please start with the current Vote Commands 0.2.0 download. Back up any existing files before updating. When oxide/config/VoteCommands/ is empty, the plugin creates a safe Example.json vote; each vote has its own JSON file in that folder. On Carbon, use the corresponding configured directory. Join as a server administrator, enter /vote_start to start the example, then /vote to open it. For ordinary players to vote in that example, grant VoteCommands.Example.Vote. The safe example has its winner actions disabled, so you can test the interface before adding commands. If that doesn't work, please open a support request with your plugin version, whether you're using Oxide or Carbon, the first console error when it loads, and what happens when you enter the commands. I'll be happy to help you through the setup. -
Hi, sorry for the late reply. In the current Codefling 2.0.4 configuration, the direct item reward supports the item's shortname and quantity, but there isn't a skin-ID field exposed for that item action. Its built-in item mapping uses the default skin. The available alternative is a Server command (optional) reward that calls a plugin/command capable of giving the skinned item. %steamid% can be used for the recipient's Steam ID. The exact command depends on the item-giving plugin you're using, so I don't want to give you an unverified command. Please tell me which plugin provides the skinned item and its documented give command, and I can help you configure the reward. A direct skin-ID setting would be an additional feature. -
Hi, thanks for your interest, and sorry for the very late reply. Player Event States is a state-storage/API plugin, rather than a complete quest system. It stores named true/false states for individual players and for the server, which another plugin can read and update. It doesn't automatically create quests, detect objectives, display a quest journal or deliver quest rewards on its own. Dialogs is one existing integration: it can check the required player states to choose dialogue paths and update states from dialogue responses. That can form part of an NPC tutorial or server guide, but a complete quest flow still needs the relevant logic/integration. If you describe the guide or objectives you want, I can help identify which parts these plugins cover. I can't confirm compatibility with a particular third-party quest system without checking its API. -
Hi, sorry for the late reply. To protect eligible buildings every day from 01:00 to 09:00, configure the allowed raid window to start at 09:00 and last 960 minutes (16 hours). That window ends at 01:00 the following morning, leaving protection active from 01:00 to 09:00. Apply these values to all seven days: Stop Protection Hours: 9 Stop Protection Minutes: 0 Stop Protection Duration (in minutes): 960 Keep Global Protection enabled, set UTC Offset Minutes to your intended timezone, then reload and check /raid_date. The offset is fixed, so adjust it yourself when needed for daylight saving. Post-wipe protection can also keep protection active outside this schedule. One important limit: this is protection for eligible owned buildings with a TC, not blanket protection against every source of damage. TC-authorized players remain exempt, and decay/electricity and the excluded NPC damage sources are not blocked. Please test the schedule on a private server before applying it live. -
Hi, sorry for the late reply. The protection exemption is based on authorization at the building's tool cupboard. A player authorized on that TC can damage the protected building while protection is active. Being in the same Rust team or clan does not, by itself, grant that exemption: the current plugin doesn't look up clan or team membership. Make sure the teammates are authorized on the relevant TC. Building placement still follows the normal Rust building/TC rules; this plugin handles damage protection rather than granting building privileges.
-
Hi, sorry for the very late reply. For raids only on Friday, Saturday and Sunday from 19:00 until midnight, configure each of those days with: Stop Protection Hours: 19 Stop Protection Minutes: 0 Stop Protection Duration (in minutes): 300 For Monday through Thursday, set the duration to 0. A duration of 1, as in your Thursday example, opens a one-minute raid window; 0 means no allowed raid window that day. Keep Global Protection enabled and check UTC Offset Minutes against the timezone you want. Please back up your old configuration before updating to 2.0.0, reload it and check /raid_date. Post-wipe protection takes priority while it is active. I can't determine the cause of the old negative countdown from this snippet alone, so if it still happens on the current version, please open a support request with the full configuration and current console output, with private information removed.
-
Changed Status from Pending to Closed
-
Changed Status from Pending to Closed
-
Hi, Thanks for the follow-up, and sorry for leaving this request open for so long. As you mentioned in your last reply, this was an unusual case and you were going to report back if it happened again. Since there have been no further reports here, I'll close the request for now. If it happens again on the latest versions, please reopen it or create a new request with your VoteSystem, CustomRewards and SkillTree versions, whether you're using Oxide or Carbon, the full relevant error with sensitive information removed, and the steps that trigger it. That will help establish whether there's an interaction between the plugins or another cause. Thank you for your feedback!
-
Hi, First of all, I'm sorry for the extremely late response. I understand that you wanted players to receive RP every time they vote, rather than having to create a separate catalogue reward for every possible vote. Custom Rewards uses a progression-based catalogue: 1 point unlocks the first reward, 2 points the second, and so on. Claiming a reward doesn't spend those points, and an already-claimed catalogue reward isn't automatically reset by the next vote. That distinction explains why the setup you described didn't behave as expected. The plugins have received updates since this report. If you still want help setting up a reward for every vote, please send your current VoteSystem and CustomRewards versions, the plugin you use for RP, and the relevant reward configuration with private information removed. Please also confirm whether you want RP awarded automatically or claimed through a command/UI, so I can advise on the appropriate setup. Since this request is quite old and refers to the previous versions, I'll close it for now. If you still need assistance, please reply/reopen it or create a new support request. Again, sorry for the lack of support at the time.
-
Changed Status from Pending to Closed
-
Hi, I'm sorry for the extremely late response and for leaving you without the setup information you needed. In the current Custom Rewards 2.0.4, reward catalogues are stored in oxide/data/CustomRewards_rewards/, not in oxide/config/. Loading the plugin creates an example.json catalogue when no catalogue exists. Each reward type has its own JSON file. You can use the Custom Rewards configurator linked on the product page to create or edit a catalogue, then export it to oxide/data/CustomRewards_rewards/<Name>.json. Review the reward actions, configure a unique chat command, enable the catalogue and reload the plugin. Players need the matching customrewards.<name>.use permission. Please back up your existing CustomRewards data before updating. If the latest version still doesn't create the example in an empty catalogue folder, send me your plugin version, whether you're using Oxide or Carbon, and the console output when it loads. I'll close this request for the old version now, but feel free to reply/reopen it or create a new request if you still need help. Again, sorry for the delayed support.
-
Changed Status from Pending to Closed
-
Hi, First of all, I'm sorry for the extremely late response, and thank you for including the error log. The exception was raised inside VoteSystem's Top-Serveurs check callback. The log alone doesn't tell me whether the original cause was the API response, the configuration or the plugin's handling of that response. VoteSystem and the vote-site integrations have changed since this report, so I can't reliably diagnose the original issue or confirm whether it still occurs in the current version. If you're still experiencing this after updating, please send your current VoteSystem version, whether you're using Oxide or Carbon, the relevant Top-Serveurs configuration with the API key/token removed, and the current console error. If available, include the provider's response with sensitive information removed as well. Since this report concerns an old version, I'm going to close it for now. If the issue persists, please reply/reopen the request or create a new one with those details and I'll investigate. Again, sorry for the lack of support at the time.
-
Changed Status from Pending to Closed
-
Hi, Sorry for the very late reply. Your question refers to the old 1.0.4 configuration. In the current Raid Time Protection 2.0.0, you configure the time when raids are allowed; protection applies outside that window while Global Protection is enabled. For protection OFF at 12:00 and back ON at 00:00, set an allowed raid window starting at 12:00 with a duration of 720 minutes (12 hours) for each day you want this schedule to apply. This allows raids from noon until midnight and protects eligible targets from midnight until noon. Check that the configured UTC offset matches the timezone you want to use. It is a fixed offset and does not adjust automatically for daylight saving. You can check the current rule with /raid_date. The product page also links to the configurator and schedule guide. Back up your existing configuration before updating and verify the schedule on a private server first. I'll close this request for the old version now. If you still need help with the current configuration, feel free to reopen it and send your schedule settings and intended timezone. Again, sorry for the delay.
-
Changed Status from Pending to Closed
-
Changed Status from Pending to Closed
-
Hi! The plugin was recently updated and tested, and I'm fully available to provide support, so to answer your question: yes -
Changed Status from Pending to Fixed Changed Fixed In to 2.1.4
-
Changed Status from Pending to Fixed Changed Fixed In to 2.1.4
-
Hi, First of all, I'm sorry for the extremely late response, and thank you for the detailed report. From what you described, the Rust-Servers API itself was responding, but Vote Reward apparently wasn't reaching the point where the vote was considered valid and the points were awarded. The fact that you didn't get the Added XX Points to player XX log would be consistent with that. The plugin and the vote-site integrations have changed since this report, so I can't reliably diagnose the original issue from the information available now. If you're still using Vote Reward and Rust-Servers is still not awarding points on the latest version, please send me: Your current Vote Reward version Whether you're using Oxide or Carbon Your Rust-Servers configuration, with the API key/token removed The API response you receive from Rust-Servers, with any sensitive information removed Any relevant console logs when the vote check runs With that, I can compare the response with what the plugin expects and determine whether the issue is in the provider response, the parsing, or the reward handling. Since this report is quite old and I can't confirm that the original issue still exists in the current version, I'm going to close it for now. If you're still experiencing it, please reply/reopen the request or create a new one and I'll investigate it properly. Again, sorry for the lack of support at the time.
-
Changed Status from Pending to Closed
-
Hi, First of all, I'm sorry for the extremely late response, and thank you for the detailed report. From what you described, the Rust-Servers API itself was responding, but Vote Reward apparently wasn't reaching the point where the vote was considered valid and the points were awarded. The fact that you didn't get the Added XX Points to player XX log would be consistent with that. The plugin and the vote-site integrations have changed since this report, so I can't reliably diagnose the original issue from the information available now. If you're still using Vote Reward and Rust-Servers is still not awarding points on the latest version, please send me: Your current Vote Reward version Whether you're using Oxide or Carbon Your Rust-Servers configuration, with the API key/token removed The API response you receive from Rust-Servers, with any sensitive information removed Any relevant console logs when the vote check runs With that, I can compare the response with what the plugin expects and determine whether the issue is in the provider response, the parsing, or the reward handling. Since this report is quite old and I can't confirm that the original issue still exists in the current version, I'm going to close it for now. If you're still experiencing it, please reply/reopen the request or create a new one and I'll investigate it properly. Again, sorry for the lack of support at the time.
