nivex

No problem Enjoy

Hi, it requires the Rust update See the update notes

Hi, I've added the despawnDateTime back to the hook. As for GetAllEvents, this will not work, and the code you're referencing needs to be updated in RealPve. public enum RaidableMode { Disabled = -1, Easy = 0, Medium = 1, Hard = 2, Expert = 3, Nightmare = 4, Points = 8888, Random = 9999 } This enum is no longer used, everything is dynamic now, and pulled from the profiles. As of version 3.0.0 (released February 6, 2025), dynamic difficulties were introduced with the rb.difficulty command. This allows users to: Rename any difficulty Remove any difficulty Add unlimited additional difficulties Here are some examples of what this means: Users may change the name Easy to Beginner Users may change Easy level from 0 to 10 Users may add a new difficulty, using any name, and any level. There is no limit. They can create as many new difficulties as they like. I've seen upwards of 20, and as few as 2. [HookMethod("GetAllEvents")] public List<(Vector3 pos, string mode, int level, bool allowPVP, string a, float b, float c, float loadTime, ulong ownerId, BasePlayer owner, List<BasePlayer> raiders, List<BasePlayer> intruders, HashSet<BaseEntity> entities, string baseName, DateTime spawnDateTime, DateTime despawnDateTime, float radius, int lootRemaining)> GetAllEvents(Vector3 position, float x = 0f) { return new(Raids.Select(raid => (raid.Location, raid.Options.Mode, raid.Options.Level, raid.AllowPVP, raid.ID, 0f, 0f, raid.loadTime, raid.ownerId, raid.GetOwner(), raid.GetRaiders(), raid.GetIntruders(), raid.Entities, raid.BaseName, raid.spawnDateTime, raid.despawnDateTime, raid.ProtectionRadius, raid.GetLootAmountRemaining()))); } [HookMethod("GetAllDifficulties")] public List<(string mode, int level)> GetAllDifficulties() { return new(Buildings.Profiles.Select(x => (x.Value.Options.Mode, x.Value.Options.Level))); } I've made the above change to GetAllEvents, to include the mode and the level, and added a new method. The solution is simple. Allow the user to map the difficulty mode to a level in your configuration file, and use the GetAllEvents API to match with that configuration. I've included an additional GetAllDifficulties API for you for ease of use, allowing you to easily create a default mapping in your configuration. But, it is still required that the user map them in your configuration file whenever they make changes in the future.

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.

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.

Hi, I can add this!