nivex
-
Posts
5,154 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
this would need to be added. i will consider it in a future update -
"Skip Treasure Loot And Use Loot In Base Only": true, hi! you need to disable this
-
Changed Status from Pending to Closed
-
nice, good luck
-
Height Adjustment Applied To This Paste - spawn X height off of the ground Force All Bases To Spawn At Height Level (0 = Water) - spawn X height regardless of where the ground is hi, you must use one of these settings for that
-
as mentioned before, it should be in the profile. i wouldn't put it in the config. profiles are more advanced whereas the config is a general use
-
all good ideas. ill keep them in mind. the last idea is the easiest
-
Changed Status from Pending to Closed
-
no problem good luck
-
yup it removes the need to put zone manager zones with no build in raid bases custom spawn points. so that allows people to delete zonemanager if thats all they were using it for. its built in now to raid bases with that option.
-
@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?
-
ah, ok. well if you updated the server during that restart then it was likely the bug introduced by the Rust update a few days ago that should be fixed now. np
-
i guess the first question would be how many potential points are there on your grid when it loads currently? having Player Cupboard Detection Radius set too low will cause bases to spawn/overlap into player bases. it is 125 by default. increase it if need be Ignore Safe Checks and Ignore Safe Checks In X Radius Only will bypass this check and can definitely allow it to happen Ignore Player Entities At Custom Spawn Locations can also pose problems if not used ideally Prevent Building Until Base Spawns is your best option to prevent players from building in custom spawn points all other settings should be set in the profiles instead of the config if using Prevent Building Until Base Spawns what you're requesting is a command that would be better suited its own plugin given how complex it would need to be in order to prevent all of the potential issues with it. it is possible, and I do have plans to make extensions for the plugin, but I don't know when that'll happen
-
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.
- 583 comments
-
- 1
-
-
- #rust
- #rust plugin
- (and 6 more)
-
maybe in the future
-
well car.key may cause this since it was removed from the game. remove that from all of the files in oxide/data/RaidableBases/Difficulty_Loot/ and then see if it still happens
-
hi, I don't quite understand what the problem is. can you clarify? you see them in the game console when pressing F1? or it shows up as red text that is printed on your screen instead of the console? I assume you mean the former. I mean I guess its possible that the loot tables contain an item that was renamed by Facepunch. I remember chocholate was renamed to chocolate, but that is fixed. it would have to be something else. do you know of any other items that were renamed? glad you enjoy my work! thanks!
-
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 -
Changed Status from Pending to Closed
-
hi, type: rb.populate all it goes to oxide/data/RaidableBases/Editable_Lists/ this is explained in the documentation
-
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.
-
who requested the above feature? can you explain. seems my notes were not good enough lol I haven't forgotten this. Ill see about getting it in the next update 2.0.3 released
-
Changed Status from Pending to Closed
-
Allow Teleport false will block this, but only if they teleport above a foundation. otherwise Map Note Teleport would need to use the EventTerritory(Vector3) API. likely campers yes, but there are many reasons players can be ejected and it does not matter if they're mounted or not. such as having a lockout, hogging raids, entering a base owned by another player, etc etc lol no problem. I don't know who it was that asked anyway. this value should be no less than double of your Protection Radius setting or this can happen. I recommend setting it between 100-150 if Protection Radius is 50.
