nivex
-
Posts
5,168 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
@Dr.D.Bugthe raidablebases.allow permission and admin cooldowns are set to 0 so the cooldowns won't apply to you since they are 0. even more importantly, they will not apply if you are in noclip @aimacakif you set Always Maintain Max Events to false then it's not going to spawn them Time To Wait Between Spawns is how long it waits before it consecutively spawns another base it sounds like you should be using Scheduled Events if you want to space them out more, and configure Max To Spawn At Once to 1 and the Min and Max times to the amount of time you want them spread out to. I could add your request but I think Scheduled Events is better suited for what you're describing -
as I said, this exists already. if you want a specific base to use a specific loot file then put that base in its own profile and put the loot you want to spawn in its own Base Loot table example: if the base is oxide/data/copypaste/aimacakhard111.json then you create a profile: rb.config add hard111 aimacakhard111 2 this will create the file oxide/data/RaidableBases/Profiles/hard111.json with the base aimacakhard111 and set the difficulty to 2 (hard) then you create oxide/data/RaidableBases/Base_Loot/hard111.json and put your loot table in this file. if you want the base loot to always spawn then enable Always Spawn Base Loot Table in the oxide/data/RaidableBases/Profiles/hard111.json profile. bonjour. this is not in the Raidable Bases plugin. it is an exclusive plugin that I've written for the Zombie Land server that interacts with the Raidable Bases plugin.
-
few things that could do this: 1. those specific bases were not copied properly. those would need recopied with half of the foundation (1.5 meters) visible above ground while the remaining half is underground. this is key. 2. if not all, but only if a small portion of the base tends to spawn slightly underground then this is unavoidable. 3. the profile heights were modified. there are multiple settings for this: 4. autoheight was enabled in the profiles. it is false by default and should generally not be enabled. most commonly the reason is #1, but #2 could apply here since you did not clarify how much of the base is underground. here are the settings for #3 and #4 "Height Adjustment Applied To This Paste": 0.0, "Force All Bases To Spawn At Height Level (0 = Water)": -1.0, { "Option": "height", "Value": "1.0" } { "Option": "autoheight", "Value": "false" }, you are either missing libgdiplus if using a linux machine, or another plugin is preventing the kill from happening
-
@MNfreakTim @HowlingWolfI removed that option in 2.6.7 btw, you just need to change stability in the profiles for each of the bases as originally intended now
-
ya, oxide/data/RaidableBases/Profiles/ "Arena Walls": { "Enabled": true, "Stacks": 1, "Ignore Stack Limit When Clipping Terrain": true, "Use Stone Walls": true, "Use Iced Walls": false, "Use Least Amount Of Walls": true, "Use UFO Walls": false, "Radius": 25.0 },
-
this cooldown applies to the player who bought the event. there will be an option to apply it to all ally in the next update. if ownership changes then the new owner will not receive this specific cooldown when the event ends. the short answer is that the cooldown starts when the event ends. the long answer is that in order for this to happen the cooldown must be set when the event starts and reset back to the full cooldown when the event ends. this prevents any exploitation of the cooldown.
-
which cooldown @Dr.D.Bug
-
@Dr.D.Bugsure, added in next update @TwoShoesnp @Shneidhello. are you using 2.6.7? ill check it out. edit: the turret will not fill or refill ammo if one of the following conditions is triggered: 1. if anyone tries to loot it at ANY point when Allow Players To Loot Traps is enabled, or 2. if you become authorized on the turret or TC by any means, including by another plugin such as DynamicCupShare or other Auto Auth plugins. either condition will completely prevent the fill/refill method from being used. this is intentional to stop any infinite ammo exploits. admins and users with the raidablebases.canbypass permission are excluded in the next update. if this isn't the case then I can look into it further just keep in mind that #1 will stop the turret from refilling if you try to loot the turret at any point, as will authing.
-
nah i removed that sometime ago. i will reimplement it in the future though
-
lol ive seen my fair share of nightmare configs. i don't recommend it but if it works for you then thats what matters.
-
Changed Status from Pending to Closed
-
nice! no problem
-
yes, that would be the free version. make sure Rust Server Manager, some host web panel uMod updater, or whatever updater you have is not overwriting the paid version =\ unfortunately, that wiped out your premium settings. the free version does not have those settings so they would not exist anymore. you can simply reinstall your tier package to fix that. only the oxide/config/RaidableBases.json and oxide/data/RaidableBases/Profiles would need reinstalled. @MrChubbyFingerz thanks @GamingHQ
-
I found an elegant solution for flamethrowers. all fireballs spawned by flamethrowers have the flamethrower_fireball prefab name. so i just kill anything that doesn't have that name. problem solved. ez pz
-
agreed
-
Changed Status from Pending to Closed
-
i couldn't tell you. must be another plugin interfering as there's nothing wrong with that profile or the plugin equipping weapons.
-
yes, that is intended, you can prevent it by enabling Despawn Dropped Loot Bags From Raid Boxes When Base Despawns @MrChubbyFingerz
-
show me a profile with the issue
-
you can edit the OnPlayerEntered messages in the language file "<color=#FF0000>You have entered a raidable PVP base!</color>\nRead the server rules: /rules" just put the \n so it's on a new line, and then add your message to that.
-
noted, thanks. message is easy enough. would just add another the problem i'm having is the games limitations with fire. death notes plugin handles it quite well but I don't want to go to that extreme to do so. i will just block fire damage if i can't determine the source in an elegant way. this would require players to keep the flamethrower in their hands in order for it to do damage. a bit annoying, but simpler is better.
-
what all is an eco tool? to me that is melee weapons only / no explosives what about flamethrowers, should that be allowed? I will have to make that an option because I know some would want it to work too
-
I suggest using Entity Owner plugin on the TC when this happens. other plugins can auth you automatically, which would cause this issue.
