-
Posts
131 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by miniMe_rust
-
Yes, you can set the rules to disable traps (incl. Turrets) and/or prevent damage to a player from traps. -
Thanks nivex, I will check my config and make sure the owner is not removed ("Remove Ownership From Bases" and "Remove Ownership From Containers" are both true by default). If I understand you right, I could get the ownerId for instance by checking the first element in privs (will likely contain only 1 in most cases) and reading the ownerId from there. I'm asking because in line 846 there is a call to "TrySetOwner" if the boolean "anon" is false. This seems to depend on "saranon" and might be another pitfall to reliably get the ownerId. Thanks again for your swift reply. I know how to go from here. OnAbandonedBaseStarted(Vector3 center, float radius, bool AllowPVP, List<BasePlayer> intruders, List<ulong> intruderIds, List<BaseEntity> entities, List<BuildingPrivlidge> privs, bool canDropBackpack, bool automatedEvent, bool attackEvent) -
Hi @nivex thanks for adding the hooks. I'm currently looking into including those into my logging and got a quick question. "OnBaseSkipped" <- does this one only fire when a base is skipped and just despawned without conversion, or does it also fire when you manually run `/sab` (or when the periodic background scan runs) when the base is not yet eligible to become abandoned? If that hook would fire for "not yet eligible" bases, according to your description only the "OnAbandonedBaseDespawn(List<BaseEntity> entities)" would be usable to signal such a base being removed. But it wouldn't provide the base owner or location. Maybe I'm overthinking this EDIT: It seems only for skipped Bases / Tugboats / Shelters the owner is passed in the signature. As I understand in that stage where e.g. OnAbandonedBaseStarted (or a subsequent hook) fires the ownerId would already have been removed from the entities so that the available info would be "a base became abandoned" but the original owner would be lost. Do I oversee something? Thanks again for your great work!
-
Check the Monuments folder and find all the JSONs in there, one per monument. Open the JSONs and edit them - you need to enable each of the monuments you want Monument Owner to handle. -
It usually does exactly that: The little overlay turns red and reads PVP when you're inside a PVP zone.
-
You need to install SimpleStatus alongside SimplePVE to get that status display.
-
Loot Protection not working for player-called airdrops
miniMe_rust replied to miniMe_rust's Support Request in Support
Hey there! I see that in v1.2.11 you addressed looting of player-called Supply Drops. However, what I can see in code is that you're not handling Excavator-called supply drops. Which is fine, but probably deserves a hint either in the plugin's page here on Codefling, or in the /sprules. Otherwise you likely disappoint players who think all player-called drops are protected, but in fact are not if called from Excavator. Thanks for the update, I will definitely check it out - but probably need to stick to my other plugin to also protect Excavator drops. Truly happy to see you teach SimplePVE new tricks. -
Your rules look fine. You prevent player to player damage, but NPCs should give damage. Please check the output of server.pve in F1 console (should say false) as well as o.plugins (If you're on Oxide, or c.plugins if you're on Carbon) to list all the plugins you have installed. Chances are you either set server.pve to true, or another plugin is preventing NPC to player damage.
-
You posted your main config, but I don't see your [oxide/data/SimplePVE/RulesData.json] file which holds your configured rules. You will very likely find your answer there.
-
I don't see a question but a statement. What is the question? SimplePVE shouldn't interfere with being able to loot anything you don't own or is outside your TC range. But you probably have another plugin that interferes.
-
Hey there, no fix, no answer, only a workaround to silence false accusations and restore peace of mind. -
Raidable Bases Mega Pack (Easy to Nightmare 210 Bases)
miniMe_rust commented on fullwiped's file in Bases
Hey there, here is a quick feedback regarding your suggested configuration to get rid of autoturrets (especially for easy bases). The configuration snippet you provide for Raidable Bases does not work. I have asked in the Raidable Bases support area, and nivex pointed me to this corrected configuration snippet. I have tested it, and when configured like so the autoturrets are removed from my (easy) bases as intended: "Kill These Prefabs After Paste": [ "autoturret_deployed" ], The important part is, that you can only put the prefab shortname, but neither the entire path nor the prefab shortname with .prefab extension. I hope this helps to improve your config example, and ultimately other buyers of your bases pack. Thanks again for putting up this nice collection of bases! There are some really nice bases in there, players love them!- 6 comments
-
- 1
-
-
- #raid bases
- #base
- (and 33 more)
-
Thank you! I get why you say CopyPaste should implement replacement of items, and I agree that such functionality should be placed there. However, I have some doubts that such replacement will ever be implemented, because there is no reason to limit what CopyPaste can do - just because one plugin (Raidable Bases) with their use case depends on it. Nonetheless it doesn't hurt to ask. Killing the autoturrets worked when I removed the first line with the full prefab path and only left the short prefab name as you suggested. I will send a notice to the creator and hint him to the correct configuration.
-
One more question: I've purchased a bunch of bases which came with autoturrets deployed - not good for easy difficulty. The creator pointed to the Raidable Bases config: "carbon/data/RaidableBases/Profiles/Easy Bases.json" and said in order not to have autoturrets you can set the option "Kill These Prefabs After Paste" like so: "Kill These Prefabs After Paste": [ "assets/prefabs/npc/autoturret/autoturret_deployed.prefab", "autoturret_deployed" ], However, after reloading or even server restart I still have autoturrets in my easy bases. Am I doing something wrong, or is the option misunderstood?
-
Not sure if this has already been asked - is it possible to dynamically replace now-blocked DLC items like for instance the "storage_barrel_c" (Frontier horizontal storage barrel) with the standard large storage box? I have a number of bases where now-blocked DLC storages have been used, and now raids don't have enough storage to spawn the typical amount of loot for the difficulty. It would be a great help if you could make an option to replace such storages with a standard similar storage. If that is feasible at all - otherwise server owners need to either violate ToS and spawn blocked items, or manually update their bases' json files and replace the blocked item with a vanilla item. Thanks in advance for looking.
-
Version number "1.7.4b5" causes Carbon to throw
miniMe_rust replied to miniMe_rust's Support Request in Support
Yes, it was as simple as removing the b5 from the version number in the plugin head. Once removed the plugin compiled fine and works (in Carbon) as far as I can tell. -
Failed to compile 'MonumentOwner': (Input string was not in a correct format.) at void Number.ThrowOverflowOrFormatException(bool overflow, string overflowResourceKey) at int Number.ParseInt32(ReadOnlySpan<char> value, NumberStyles styles, NumberFormatInfo info) at int int.Parse(string s) at new Oxide.Core.VersionNumber(string version) in /__w/Carbon/Carbon/Carbon.Core/Carbon.Components/Carbon.SDK/src/Oxide/Version.cs:line 33 at new InfoAttribute(string Title, string Author, string Version) in /__w/Carbon/Carbon/Carbon.Core/Carbon.Components/Carbon.SDK/src/Plugins/Attribute.cs:line 19 at object[] MonoCustomAttrs.GetCustomAttributesBase(ICustomAttributeProvider obj, Type attributeType, bool inheritedOnly) at object[] MonoCustomAttrs.GetCustomAttributes(ICustomAttributeProvider obj, Type attributeType, bool inherit) at object[] RuntimeType.GetCustomAttributes(Type attributeType, bool inherit) at Attribute[] Attribute.GetCustomAttributes(MemberInfo element, Type type, bool inherit) at Attribute Attribute.GetCustomAttribute(MemberInfo element, Type attributeType, bool inherit) at Attribute System.Reflection.CustomAttributeExtensions.GetCustomAttribute(MemberInfo element, Type attributeType, bool inherit) at IEnumerator Carbon.Managers.ScriptLoader.Compile()+MoveNext() in /__w/Carbon/Carbon/Carbon.Core/Carbon/src/Loaders/ScriptLoader.cs:line 478 Invalid plugin format in 'MonumentOwner.cs'. Namespace must be Carbon|Oxide.Plugins and inherited class must be Carbon|Rust|CovalencePlugin. Remedy: Edit the source .cs file and change "1.7.4b5" >> "1.7.4"
-
Not exactly sure what you're referring to "Team Ownership". a) Every team member can do everything within the owned monument. b) Team cool downs are something the author promised to look into at some point, he called it "the next global version". This plugin has a lot of configuration switches which can lead to strange behavior, for example flipping ownership back and forth if one team member is in monument A and the other in monument B. All explained and handled nicely by the author in the discussion and support sections. It boils down to "settings do what they say / don't change too much at a time / think". To sum it up, the plugin is very usable overall, and my personal experience with the author is that he is very active - as testified in my review. For me personally Monument Owner is a perfect fit for my servers. But every server is different. If your use case is different it may or may not suit your needs.
-
Yes it does
- 201 comments
-
- 1
-
-
- #jtedal
- #mad mappers
- (and 7 more)
-
nvm
-
No need to tamper the .cs source - Monument Owner can be enabled and disabled individually per monument through configuration. This is more sustainable across plugin updates.
-
Careful with this option. It literally does what it says. Either turn on spheres around monuments or imagine an invisible border between inside and outside the monument zone. If you don't allow damage from outside the zone you might find yourself in situations where a junkpile scientist is just inside the zone and you're outside. He can damage you, but you can't kill him - unless you change position and also enter the zone. This option is not about ownership.
- 201 comments
-
- 1
-
-
- #jtedal
- #mad mappers
- (and 7 more)
-
Hey there! You should set server.pve to "false" or remove the line completely from your startup / server config. While SimplePVE may work to some degree, you otherwise should expect for example players getting damage reflected when they try to break their own bases (e.g. remove twig in order to build differently, and die from it). In addition immersion will be tampered with, because you could literally run a monument like Oil Rig with a water pistol, because NPCs don't cause real damage. If you set server.pve as intended (= false) and leave damage handling to SimplePVE it will work just fine. Add "pve" to your server.tags to make your server show as PVE in the server list, if that is what you want.
-
Loot Protection not working for player-called airdrops
miniMe_rust replied to miniMe_rust's Support Request in Support
I think the problem lies within how you treat Supply Drops. SimplePVE seems to assume that a Supply Drop entity holds the OwnerID of the rightful owner, which is not the case in reality. The check in SimplePVE line 2392 does not work, and for that reason loot protection fails. Instead of checking for OwnerID you should check who threw the Supply Signal (or requested the drop from Excavator) and follow how those are linked => Cargo Plane => Supply Drop. If you chain it correctly, it will tell through the link chain which Supply Drop (NetId) belongs to which player, and you can decide whether or not it can be looted according to rules by a player or team mate. Thanks in advance for looking into it. If there is interest, I can share a proof-of-concept plugin which uses signal-chains as described to reliably tell which drop belongs to which player. That PoC is based on SupplyLock (free plugin here on codefling) which is using a queue approach (unreliable), and prompted me to dig deeper and investigate. I'm happy to share the (working) source if it helps and you want to use it. See also https://umod.org/documentation/games/rust#onexplosivethrown https://umod.org/documentation/games/rust#onexcavatorsuppliesrequest https://umod.org/documentation/games/rust#oncargoplanesignaled https://umod.org/documentation/games/rust#onsupplydropdropped -
Your settings look fine. But notice you've got loot protection disabled, hence unlocked boxes can be accessed by anyone. That is to be expected. As per "everyone can raid everyone", this is true if attackers manage to auth on the victim's TC. If the TC is indeed locked and players can still raid there must be another plugin interfering. Please post the output of o.plugins (if you are on Oxide) or c.plugins (if you are on Carbon)