-
Posts
5,234 -
Joined
-
Last visited
-
Days Won
180
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
Message: OnLockedToRaid Option: Lock Players To Raid Base After Entering Zone Applies To: Buyable / Manual / Maintained / Scheduled Events Shown when a player enters an event. This option locks the player to the raid, NOT the raid to the player. Locking the raid to the player uses separate options. Message: BuyCooldown Option: Buyable Cooldowns Applies To: Buyable Events Displayed when a player attempts to use the /buyraid command while still on cooldown. This message does not prevent entering a raid, nor does it show the cooldown when entering a raid — it only blocks purchasing them, and is only shown when being blocked from that purchase. Message: LockedOut Option: Player Lockouts Applies To: Maintained / Scheduled Events Shown when trying to enter a public event while on a lockout. Not related to Buyable Cooldowns, and not related to Buyable Events.
-
@Tay Hi, I think the confusion is coming from the translation. First, it said "cooldown," now it says "locked," which changes the meaning. This option doesn’t lock the raid to the player — it locks the player to the raid. That means they should finish that raid before they can start another one. Set to true in the config: This message is shown, OnLockedToRaid: If instead you want the raid to lock to the player, that happens when the player deals damage, not when they enter. That behavior is enabled by default, and there’s no message shown when it happens. It is displayed in an update to the Status UI, visible only when the player is inside of an event. I hope this clears things up. I understand translating is difficult when it's not accurate.
-
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!- 1 reply
-
- 1
-
-
@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.
-
@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
-
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
-
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.
-
@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.
-
@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
- 592 comments
-
- #rust
- #rust plugin
- (and 6 more)