nivex
-
Posts
5,151 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
it's supported, but it's not recommended that you increase the protection radius unless your map can support it. it will make it more difficult for the plugin to find a suitable spawn location for such a large radius -
i can't stomach creating anymore UI right now but may consider it later. @KingSizeKevinif someone wants to contribute it then ill definitely add it
-
there is nothing to block players from buying their own raids except the cooldown and this is not applied to the whole clan all other raids are blocked by default (raidablebases.blockbypass permission bypasses these settings): config: "Block Clans From Owning More Than One Raid": true, "Block Friends From Owning More Than One Raid": true, "Block Teams From Owning More Than One Raid": true none of this will work if the below option is false "Prevent Players From Hogging Raids": true, this will prevent them from doing damage when they're blocked this can by bypassed using: Bypass Lock Treasure To First Attacker For PVE Bases Bypass Lock Treasure To First Attacker For PVP Bases and by default players can enter ally raids when they have a lockout: Allow Ally With Lockouts To Enter there are no global cooldown applied to the clan, but there are individual cooldowns for buyable events: Cooldowns (0 = No Cooldown) and the other is for lockouts by difficulty or global lockouts if enabled. a lockout does not prevent someone from owning (buying) a raid: "Player Lockouts (0 = ignore)": { "Apply All Lockouts Everytime": false, "Time Between Raids In Minutes (Easy)": 0.0, "Time Between Raids In Minutes (Medium)": 0.0, "Time Between Raids In Minutes (Hard)": 0.0, "Time Between Raids In Minutes (Expert)": 0.0, "Time Between Raids In Minutes (Nightmare)": 0.0, "Block Clans From Owning More Than One Raid": true, "Block Friends From Owning More Than One Raid": true, "Block Teams From Owning More Than One Raid": true },
-
heh yea It's fixed in the next update thanks bro
-
thanks for the translation I will look into this @Deadpool @LizardMods
-
@Deadpoolplease say again in your native language. the translation is a bit confusing @DeanoI am trying to fix the issue sorry for the trouble
-
yea I keep looking and I just don't see anything wrong. I will probably just rewrite the whole damn thing =\
-
case RaidableMode.Easy: return Easy <= 0 || Easy - Epoch.Current <= 0; case RaidableMode.Medium: return Medium <= 0 || Medium - Epoch.Current <= 0; case RaidableMode.Hard: return Hard <= 0 || Hard - Epoch.Current <= 0; case RaidableMode.Expert: return Expert <= 0 || Expert - Epoch.Current <= 0; case RaidableMode.Nightmare: return Nightmare <= 0 || Nightmare - Epoch.Current <= 0; I have no idea. this code states the lockout MUST be 0 or MUST be expired in order to be reset. i see no possible way this could fail
-
no problem good luck!
-
heya, the issue is that most maps do not contain enough flat land, and when it does it is quickly taken up by players or bases. the reason the shore is preferred is because it contains the greatest portion of land, even though it's mostly submerged to try and counter this you have a few options 1. use Spawns Database File (Optional) via the Spawns Database plugin (available in the config if you opt to use the same spawn file for all profiles, or you can configure it individually in each profile instead) 2. create flat areas (or Islands) on each map before you use the next map. you can do this in RustEdit and save it as a prefab to paste into new maps 3. edit the below settings to reduce this possibility. "Water Settings": { "Allow Bases To Float Above Water": false, "Chance For Underwater Bases To Spawn (0-100) (BETA - WORK IN PROGRESS)": 0.0, "Prevent Bases From Floating Above Water By Also Checking Surrounding Area": true, "Maximum Water Depth Level Used For Float Above Water Option": 0.01 }, however maps with bad terrain will cease to work properly if there aren't enough spawn locations to choose from. this option will decrease server performance on lower end machines. a lower end machine is any machine with fewer than 12gb of memory, or a base clock speed under 3.7ghz on each core, or any machine that does not come with at least 2 cores available to the Rust server. lower end machines are still capable but issues will quickly present themselves when the machine is under any demanding load. most low end machines can host up to 20 players and 10 raid bases without issue this is mentioned so that you keep each option's performance in mind before deciding to use it. some main performance killers are too many bases, or too many npcs. i suggest no more than 10 bases on any low end server, and never more than 10 npcs per base on any machine low or high end. there are many options however that do not pose any performance issues so with any experience it should be self explanatory which ones do or do not
-
heya TwoShoes, I think a better solution would be to use the hook provided by Removal Tool and block each remove if the command is blacklisted. then there's no possible way to continue exploiting this. I've added the following code to achieve this in the next update: in Subscribe() method: if (config.Settings.BlacklistedCommands.Exists(x => x.Equals("remove", StringComparison.OrdinalIgnoreCase))) { Subscribe(nameof(canRemove)); } and above the canTeleport method: private object canRemove(BasePlayer player) { return !player.IsFlying && EventTerritory(player.transform.position) ? m("CannotRemove", player.UserIDString) : null; }
-
that's a good idea i'll keep it in mind
-
@Fast_CDthanks fixed in next update. you don't need to rollback, and it isn't going to help either. the issue is its trying to update the time for someone that's offline so it's going to happen in any version just revoke raidablebases.time permission from everyone until next update
-
it is a Unity bug that causes this to happen when it crashes, and it happens on Vanilla servers as well. all it takes is for one server on the machine to crash and every other one CAN crash as well. This can be caused by FindObjectsOfType being used in the code (which Raidable Bases does not use) and the corresponding error code is unity segment fault 0x01. This is often triggered when ANY server on the box restarts or a plugin unloads/reloads so it can be from any of the servers on the machine. Most often from a dev server, or a server that repeatedly reloads plugins for whatever reason. many plugins use this above code so without all of them being fixed it can be a huge problem for shared hosts glad you are hopeful. I hate these issues as much as anyone...
-
@Swedish Chefyes the spawning on the train tracks is fixed in the next update. your second issue is also caused by this issue I am still trying to fix the performance issue, but it's being difficult. would be nice if I had access to a machine with the issue
-
Server performance is my number one priority and I will continue to fix any performance issues. It is difficult when I can't reproduce them, and when so few people have the issue. Issues like this are much easier to fix when I have access to a machine in order to reproduce the issue. It is very difficult to fix something when you don't know the cause. It is intended and by design that npcs act erratically as it makes them difficult to kill. Collider issues can be fixed by updating CopyPaste and the tier packages. Otherwise it is caused by another plugin. I did ask the author of CopyPaste to remove unity scripts from being pasted in, and provided the fix, but have thus far been ignored. A plugin is not going to cause a server-node to crash. I don't know who told you this but they're wrong and if it was your host then find a different one that doesn't feed you nonsense. I apologize for the issues you're experiencing and you can rest assured that they will be fixed when I find a fix for them
-
I am trying to get it fixed asap sorry for the wait
-
@TwoShoesi am unable to reproduce issue with mini spamming players in 2.4.4. can anyone else confirm this is still happening? also I will not be replying to the closed thread regarding this simply because i'm asking others for more information here instead. also need step by step instructions to reproduce this. getting on a mini and flying in - nadda, getting on mini while already in - nadda
-
@chuck norrisyour issue is fixed in the next update !
-
@BatenkaIll have to remember this the next time someone mentions it isn't working. Oh fun oh fun =D Thanks guys for answering him
-
Changed Status from Pending to Closed Changed Fixed In to Next Version
-
heya this is fixed in the next update. thanks
-
heya. I am aware and working on a fix thanks
-
@DiDreamerif you are still having this issue then it is because of your Kits plugin. it is bugged and needs to be fixed. [HookMethod("isKit")] public bool isKit(string kitName) { return kitsList.Exists(p => p.Name == kitName); } this is the fix for the Russian version Kits plugin -
@chuck norrisI also need error messages from you, the one above is from Oxide and doesn't tell me enough
