nivex
-
Posts
4,784 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
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.
-
@BadLandsits fixed in next update. couldve sworn I said that already @NoxiousPluKthose settings are in the config under Eject Mounts. its not new
-
Changed Status from Pending to Closed
-
lol well im glad you sorted it out because i had no idea. ill have to remember that =D
-
Changed Status from Pending to Closed
-
use ent who on the base after using the command. is this linux? tell your host to install libgdiplus if so. it is required to convert byte arrays into bitmap format for Rust. not having it installed will definitely cause this issue.
-
@GamingHQno, not necessarily. it could be many things. i've fixed 2 issues in next update so hopefully one of those fixes resolves your problem. libgdiplus is a required library on all linux machines as it converts byte arrays into bitmap format. not having this will definitely cause spawn and/or despawn issues. if missing this library then your host must install this critical library and in most cases requires the machine to be restarted.
-
@TwoShoesthat contains the uid of each entity spawned by CopyPaste for use with Raidable Bases so that it can delete them on a server restart if they were not despawned either during a server crash or during a normal restart.
-
hi, i am thanks. there's a simple way to delete them, /rbe kill_cleanup it should be fixed in next update, but there's no reason a restart shouldn't clear them out unless there's an error which i would need.
-
Changed Status from Pending to Closed
-
interesting. never seen it done this way. ill have to remember that lol
-
you have to press enter then click the buttons, otherwise set cursor enabled to true so you don't need to press enter first
-
yes, as GamingHQ said, this does not happen if they're teammates. profiles: "Eject Enemies From Locked PVE Raids": true, "Eject Enemies From Locked PVP Raids": false, config: "Bypass Lock Treasure To First Attacker For PVE Bases": false, "Bypass Lock Treasure To First Attacker For PVP Bases": false, "Lock Players To Raid Base After Entering Zone": false, "Lock Treasure To First Attacker": true,
-
its fixed in the next update @BadLands
-
the next update will be released when its ready. I don't like to say a specific period of time because there are often delays with a project this large, the fact that I have over 25 projects, and I like to release quality work. I am working on rewriting the handling of auto turrets in order to resolve an issue where turrets do not come online when the server hits the IO queue limit. this isn't a concern for most servers but those servers that are slower or are bogged down will notice this from time to time so hopefully I can finally put the final nail in the coffin
