nivex
-
Posts
5,658 -
Joined
-
Last visited
-
Days Won
194
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
@EllieCat Hi, before the game update. -
Hi, here is the advice in more detail. First, they need to reduce paste batch size in the CopyPaste config file from 15 to 1. There is no reason that 15 should be the default. oxide/config/CopyPaste.json: "Amount of entities to paste per batch. Use to tweak performance impact of pasting": 1, Reduce the batches in your profiles, oxide/data/RaidableBases/Profiles/ "Amount Of Entities To Spawn Per Batch": 1, "Amount Of Entities To Despawn Per Batch": 1, limit the number of plugins: too many will push the server past its limit, and every server has a limit! limit the number of bases; auto spawn 1 easy, 1 medium and 1 hard. let players buy the rest. increase the default inactive despawn time of 45 minutes to something more fitting for your servers specific needs. limit the sizes of the bases; delete any copypaste files over 3mb. most files should be under 1mb — a few up to 2mb is fine, but keep it minimal. do not use copypaste which have too many io entities! anyone who does otherwise does so at their own risk. know your limits. reduce entity count on the server; the higher the entity count, the more load on the server, and the quicker it will hit its limit. plugins such as LimitEntities or AutoPurge can help with this upgrade to better hardware; increase your RAM (at bare minimum 16GB), or pick a better machine. restart daily to avoid server degradation issues - DO NOT RELY ON MEMORY OR CPU USAGE TO DETERMINE SERVER DEGRADATION! Use fewer NPCs. No more than 2-3 per base. Increase health, damage, accuracy and use better kits. A few good NPCs will prove challenging enough. Some hardware should not be used for a Rust server, and loading plugins like this one will push it over the edge; if it's under 16GB RAM then it's a crap shoot. Some hosts have way too many servers on shared machines; ensure your host does not exceed a reasonable limit lastly, it could be failing hardware in which case you need to check with your host and ensure they follow up accordingly; I've seen this quite often as of recent months Rarely is the issue with the plugin itself, where I am quickly notified by high pop servers about any noticeable change in performance from wipe to wipe. I watch this closely, and take it very seriously, to ensure a high quality plugin that your players can enjoy.
-
@Tay Heya, relevant messages are shown already. Buyable Cooldowns Buyable Cooldowns do not restrict event entry. They are used to limit how frequently players can purchase events. When a purchase is blocked due to a cooldown, a message is always displayed explaining the reason. This is not used with public events. Player Lockouts Player Lockouts prevent players from entering public events. When a lockout is triggered, a message is displayed and any active lockouts are listed in the Lockout UI. If no message appears, the lockout is either not configured or you do not have a lockout for that difficulty. This is not used with purchased events. Bypassing Lockouts Vanish, noclip, and the permissions raidablebases.lockoutbypass or raidablebases.canbypass will allow you to enter. This is intended so you can easily assist players without interfering with game play. Cooldowns and lockouts are not interchangeable. They serve different purposes and are named differently for that reason. -
Changed Status from Pending to Closed
-
Again, so it's not missed: A couple more points You should use fewer NPCs as well. No more than 2-3 per base. Increase their health and damage, give them good kits, give them crazy accuracy. A few good NPCs will make a very challenging base. Some hardware should not be used for a Rust server, and loading plugins like this one will push it over the edge. It's time to upgrade when it's clearly a crap shoot. Some hosts have way too many servers on a single machine too. I could elaborate further, but there’s little value in continuing the discussion at this point. By now, this often devolves into debate, and I won’t engage in that. I’ve provided thorough, detailed responses, and it’s now your responsibility to review and act on them as needed. I've done my part. I take server performance very seriously and work closely with server owners to continually improve my plugins. Thanks to their contributions and feedback, any significant issues are identified and resolved in a timely manner. If there's an issue then you best believe we'll sort it out. Thank you for your understanding. This thread is now closed.
-
Heya, First, they need to reduce paste batch size in the CopyPaste file from 15 to 1. There is no reason that 15 should be the default. If the server lags when the bases spawn or despawn then, limit the number of plugins they're using, limit the number of bases they're spawning, limit the sizes of the bases they're trying to spawn, reduce the entities on their server (300k+ is too much for modded), upgrade to better hardware restart daily to avoid server degradation issues - DO NOT RELY ON MEMORY OR CPU USAGE TO DETERMINE SEVER DEGRADATION! lastly, it could be failing hardware in which case you need to check with your host and ensure they follow up accordingly. Everything runs at the bare minimum for despawning already. It is clear that AI was used to analyze the code, and it has done a very poor job with the remarks in the provided message file. Many of the comments misunderstand the plugin’s low-level functionality. Implementing such changes would severely impact that, breaking critical method logic and cross-method integrations. So I have to correct each point—something that’s both frustrating and time-consuming. I will not respond further to this afterwards. **1. MASSIVE GRID GENERATION This is called one-time when the server starts, or when the plugin reloads. Neither of which are an issue. Yield times are sufficient, spreading the load out across several minutes, reducing the impact it has on performance. Increasing them would serve no purpose other than to delay how long it takes anyone to reload the plugin. Changing CELL_SIZE would break the cluster logic of potential spawn points. This shows a gross misunderstanding of how CELL_SIZE relates to the code as a whole. Such changes will break the plugin on maps which are starved of good terrain to begin with. I am not going to impose any limits. Use Spawns Database! **2. FREQUENT COROUTINE EXECUTION Nonsense. This is fine, and is a requirement. Without this, the plugin cannot function, it must use these to find positions for bases to spawn at. 0.1 is sufficient enough yield time already, increasing it would provide no benefit. **3. ELEVATOR UI SPAM This runs once per second, and will not be increased to 5 seconds. That is way too long, and serves no benefit to be increased. Checks are done within a 3 meter radius which is highly efficient. Using a cached dictionary of players to boot. **4. BROADCAST MESSAGES TO ALL PLAYERS No, there is no issue with the plugin messaging all players on the server. This is OPTIONAL already. **5. CONTINUOUS AUTOMATED SPAWNING Say it ain't so. Better throw in the towel and paste them in manually then. **6. PHYSICS RAYCASTS IN ELEVATORS This is not used frequently enough to be expensive, and no one uses "many" elevators in their bases, let alone across multiple bases simultaneously. RECOMMENDED OPTIMIZATIONS: All suggested optimizations are either already implemented, unnecessary, or based on incorrect assumptions. Memory management issues: Allocations are minimal as nearly everything is pooled. Oxide’s memory reporting is notoriously inaccurate; if precise metrics are critical, use Carbon, which provides more reliable memory data. This is no fault of Oxide, or the Oxide team. Bugs exist, and some times they're ridiculously difficult to track down and we do not always have the time to waste on such meaningless tasks. High hook times (my response): I don’t dispute the hook times. This plugin is intentionally large and delivers extensive functionality, which inherently requires many hooks and significant processing. That overhead is a direct result of its scope and cannot be reduced without stripping core features. Immediate action items: These are the only points that I agree with.
-
Suggestion: Add hook for Abandoned Base too small, filtered, skipped
nivex replied to miniMe_rust's Support Request in Support
Hi, I can add this! -
@Tay I've responded in DM. I've tested Easy, Medium, and Hard from Maintained Events using your files and each event locks to the player (on damage, never on entry) as expected. I changed Difficulty Level for each back to its respective value (0=easy, 1=medium, 2=hard, etc). This must be from some error, or an issue with RealPve, as no such issue exists in RB. Several people use both RealPve and RB so I am sure you can sort it out if you ask that developer. He has his own RB implementation, which deviates from mine, so he will be the only one that knows what the issue is since it's not my code.
-
You should not configure it this way. Every difficulty requires its own level, not to be shared with another difficulty send me the files in DM
-
@Tay Hi, as explained earlier, bases do not lock on entry. It locks on explosive/melee damage, killing an npc, or destroying part of the base. If it locks on one difficulty then it will lock on every difficulty, unless you have the others spawning as PVP when they should be PVE. You can send me the profiles and config in DM though. @Andariel Hi, the error says 2.0 is not a valid integer, so it needs to be written as 2 instead, under Notify Plugin - Type
-
@PhatBlinkie Hi, it's an issue with a language file, likely the French language file (unless you changed something else) Here's the fixed French file RaidableBases.json
-
@Andariel Hi, what message are you not seeing? "Notification Interval": 1.0, You can try adjusting this to 2.0
-
@Trick Hi, the only way to see this message is if you've been granted the raidablebases.banned permission. People do this often enough that I've created a command to revoke it, useful for those who don't remember what group they granted it to. /rb unban
-
heya, these are in the profiles, not the config 1. Look for the block damage outside options, and prevent npcs from leaving the dome. set true, Block Damage Outside Of The Dome To Npcs Inside set true, Block Damage Outside To Npcs When Not Allowed To Leave Dome set false, Allow Npcs To Leave Dome When Attacking set false, Allow Npcs To Shoot Players Outside Of The Dome 2. Yes, but adjust this with caution. Setting it too high will cause turrets to shoot very far away, 45 meters is more than sufficient leave at default 30, or increase to 45, Sight Range if you set this to true, then it can double (eg: from 30 to 60) when attacked by players, Double Sight Range When Shot these are all in the profiles, oxide/data/RaidableBases/Profiles/ I'm glad you enjoy the plugin
-
Hi, I can't really tell from the photo, but it appears to be a vanilla feature
-
@KingSizeKevin hi, I'll have it fixed next update thanks
-
There are multiple tools available (RB loot table editor, and various websites) to help you with removing paid content. In the next update, I will have two additional ways to handle this for Raidable Bases: An option, which is enabled by default, and will remove paid content without modifying any files. A command, generated at random, that will permanently remove all paid content from your copypaste and loot table files. The command name is randomly generated and stored in the configuration file. Only those with access to your configuration files will be able to see the command name. This can be used as a server command, or by those with auth level 2. It will never be permission based. Example output with tier 1, tier 2 and tier 3 packags installed.
-
@SunShine ツ heya, yes. there will be a new option in RB, and several developers have website tools. see the above responses where it's discussed at length already
-
@Dead Nasty Hi, sorry but no, there's simply too much bloat with cooldowns as is and you'll need to cap it with the cooldowns and lockouts instead. If you set it to every 24 hours then that's once per day. Set it to every 12 hours and that's twice per day. You'll have to make do with this. If I can reduce the bloat of the code, then I'll reconsider it, but not right now.
-
@Amadeus.pve Hi, do not worry, turrets will be addressed in the next plugin update. All paid content will be blocked from spawning by the new option until Facepunch is able to clearly outline specific exceptions. I've asked them to comment further on this, but haven't gotten a response other than to wait for the dev blog.
-
@Amadeus.pve Hi, no, you cannot keep paid content. Free content is still allowed. Use Random Skins spawns free content. Use Workshop Skins spawns paid content, and will be disabled in the next plugin update.
-
@Dead Nasty To clarify, this tugboat was the event? It could be the float to shore code implemented by Facepunch Test by setting the do_shore_drift convar to false, then you can enable it again afterwards If so, it is an easy fix but don't want to go down a rabbit hole trying to figure out what it is if you can confirm with the convar first -
A new option will be added in the next plugin update, to be released before the game update—enabled by default—will block paid content: Paid items from copypaste files (these will be automatically despawned) Paid items in loot tables (they will be skipped in favor of non-paid content) Paid skins from copypaste files (these skins will be removed) Paid skins from any file within the RaidableBases data folder Moving forward, only non-paid skins should be added to either ImportedWorkshopSkins or SkinsPlugin files in the RaidableBases data folder. Paid skins are not allowed when this option is enabled. Note: Third-party plugins may bypass these restrictions. This option will attempt to block pickup and looting in such cases. Be sure to only use plugins that comply with Facepunch’s Terms of Service. It remains unclear what exceptions are permitted, so these restrictions will remain until Facepunch can respond with an official statement clarifying what is allowed.
-
@Grumpy Old Man Hi, this is discussed at length above, and is in the top of the plugin's documentation. Yes, there will be a new option (DIsable Paid Content in the config) but it is still your responsibility to remove any paid content from the files on your server. You can already disable "Use Workshop Skins" setting (boxes, npcs, loot items, and deployables) to prevent workshop skins being applied. This will not remove any skins already in your copypaste files. It prevents new skins from being applied only. My tier packages will be updated when I have time. Stay tuned.
-
@miniMe_rust Hi, I will provide an update to include new items which are missing from the loot tables, and to provide additional loot tables that do not include any paid content in them. Though anyone not wanting to update to the new package will not have to do so. Removing the paid content without updating to the new pack will not result in less loot spawning in bases if "Allow Duplicate Items" is still enabled, it will still ensure the correct amount of loot is generated. It will be possible for the Raidable Bases plugin to filter out any paid content using a new option that will be added in the next plugin update. The plugin update will be released before the game update. My warning in the documentation, in short, explains that this might require more than one plugin update to fix any issues with this option or otherwise.
