nivex
-
Posts
5,932 -
Joined
-
Last visited
-
Days Won
200
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
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
-
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
-
yes, that is intended, you can prevent it by enabling Despawn Dropped Loot Bags From Raid Boxes When Base Despawns @MrChubbyFingerz
-
I suggest using Entity Owner plugin on the TC when this happens. other plugins can auth you automatically, which would cause this issue.
-
tested this twice and no issues until I auth on TC or destroy TC.
-
thank you. the issue is that ladders built by the plugin are not taking damage. the plugin ignores it, thinking it's not part of the event, and lets TruePVE handle it instead. it doesn't affect normal ladders. it's entirely possible that the damage is allowed by another plugin (such as TruePVE rulesets or flags) so you may or may not have this issue. this bug is fixed in the next update, and I posted the fix a few posts back if you'd like to see it.
-
semi rifle reloads fine. authorizing on the turret or TC, or killing the TC will prevent the weapons from reloading but that is intended
-
if you want to allow ladder damage on the entire server then you may add BaseLadder to the dispensers entity group in the TruePVE config, or any other entity group that is allowed to take damage
-
@Vasilyi Yrupinthanks, fixed in next update raid.MyInstance.RaidEntities[e] = raid; add this to line 2361
-
this would need to be added. i will consider it in a future update -
all good ideas. ill keep them in mind. the last idea is the easiest
-
@GamingHQinteresting idea. i wouldnt be able to use holograms, I dont think thats a thing. i could draw boxes on their screen to indicate where the damage is. but that would be difficult to see when its visible through walls. i suppose i could do a range check to help mitigate that. you would have to explain the restrictions of the repair command more. for example.. when would it be useable? and for how long?
-
if they have abandonedbases.convert and abandonedbases.convert.cancel then they can type /sar cancel if Require Event Be Finished Before It Can Be Canceled then it won't be canceled if its not finished if Seconds Until Event Can Be Canceled has not elapsed then it won't be canceled ultimately, that's on the player. I would tell them that they should've spent a few minutes to log in instead of abandoning their base. the plugin exists so that player buildings can be raided or destroyed when they're no longer used by the owners. it provides another incentive to the server while simultaneously helping it perform better by keeping the entity count in check.
- 634 comments
-
- 1
-
-
- #rust
- #rust plugin
- (and 6 more)
-
maybe in the future
-
hi and thanks, you're welcome! times cannot expire early, nor can they expire before the configured amount of time unless you manually force a conversion of the base using the /sar command, or by granting the wrong permission from the config to the player. if a player has 2 permissions and 1 is inherited from a group with a lesser amount of time then that time will be used instead. the plugin begins saving the players last online time the moment it is installed. if the plugin is running for 3 days (and that player was online the first day) before you give players a permission and that permissions lasts for 5 days then they will have 2 days before it expires and converts their base if automation is enabled. all times are calculated using the epoch time, which uses the time on your server. so if your time zone differs from the server's then that does not mean it expired early. ah that makes more sense. I'll note it down but I don't have an eta for you atm
-
Added in next update change: if (!attacker.IsReallyValid()) { return null; } to: if (!attacker.IsReallyValid()) { return hitInfo.Initiator.IsNull() || RaidableBase.Has(hitInfo.Initiator) ? true : (object)null; } this is the result of other bugs which were fixed. this happens now because the current unchanged code still returns null which tells TruePVE to handle it. the damage is blocked by TruePVE because there are no flags or rules allowing it (and there shouldn't be, but TwigDamage would allow it if not paired with TwigDamageRequiresOwnership). the fixed code tries to handle the damage itself by checking for no initiator or if the initiator belongs to the base and failing that it will let TruePVE handle it. I could very likely just return true and be fine but I'd rather cover any potential overlooked edge cases. took me several hours to figure all these details out for something so simple in the end. that's generally how it goes lol. anyway, I figured an explanation would help server owners like you to learn a bit about code so they can dabble in it themselves. it's quite fun =p
-
post your config from pastebin.com so i can have a better understanding of how you're using the plugin. by default all entities get destroyed.
