-
Posts
121 -
Joined
-
Last visited
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by miniMe_rust
-
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
- 193 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.
- 193 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)
-
There is a teedy tiny problem. Too many players in PvE leave their bases unlocked (you don't need priv to open a door) and even don't lock their TCs. In my eyes this is where a) the loot protection breaks, and b) damage reflection about entities back to the attacker ultimately fails. So the real problem at hand is: players need to build sound and upgrade their twig asap players need to lock their TCs and not place them on a twig foundation In my eyes it is impossible to hold the players' hand at all times. I could imagine preventing TC auth if no authed person is connected AND in TC range. This would prevent the attack vector of intruders just authing on an unlocked TC and then just accessing any unlocked loot container in the base, or taking it over. Furthermore unlocked TCs and taking auth on it prevents any meaningful "reflect damage to an entity where the attacker has no building permission". Finally there are players who place their TCs on twig foundations. While a locked TC is pretty well protected an attacker can still break the twig foundation with the TC on it, and this way destroy the TC and build their own. SimplePVE fails to prevent destruction of twig foundations. While I like the idea of protecting a player's entities inside their base, I think fitting that into an existing plugin can be quite challenging, whereas preventing player damage is already there. It is not a big step from preventing damage to reflecting it. Hence I believe that is easier and more likely to be implemented soon, should @Iftebinjan decide to do that. Having damage reflection would be nice indeed. The problem with players bypassing loot protection through authing on the victim's TC could be solved by preventing a) OnCupboardAuthorize, b) OnCupboardClearList and c) OnCupboardDeauthorize while the TC is unlocked. This will force players to lock their TC, teach them better and this way solve the TC auth problem.
-
Hey there, just out of curiosity: what do you mean "add the reflect damage option"? If you talk about reflecting all damage inflicted to players and sleepers back to the attacker I'm all in for this suggestion. But reflection of damage inflicted to entities back to the attacker is a bad idea. Too easy to accidentally hit a player's entity while fighting a junkpile scientist... and dying from that? No thanks. That's a bad idea to begin with, was already bad in the vanilla server.pve mode. But yeah, an option to reflect damage would be nice, if you can also configure what kind of damage to reflect.
-
That would be lovely. Ideal would be a full cycle, a hook for every stage of an Abandoned base, Makes it easy to log it with owner, position, why it became raidable, who raided it or if it just disappeared because it was not eligible. Thanks again for looking into this
- 606 comments
-
- 1
-
-
- #rust
- #rust plugin
- (and 6 more)
-
Thank you, that is super helpful. Trying to get away from parsing logs with a bash script, and Abandoned Bases was the last puzzle piece missing. I think there should be 3 maybe 4 stages. When it comes to Abandoned Bases there is always a player involved who might return and ask what happened to their base (some players can't be bothered to check server rules with AB explanation). Base became abandoned but wasn't eligible to be converted into a raidable base Base was (manually?) converted / raid begins >> B OnAbandonedBaseStarted Raid was canceled (base owner came back while the raid was running, or someone ran /sar cancel) Raid was completed (all loot boxes emptied / broken) Raid ended >> D OnAbandonedBaseEnded I'm super happy you hinted me to B and D. Not sure what signatures I have seen in your source. Regarding the not-eligible bases which are directly destroyed I wrote in a support ticket, and I trust you will eventually add that when there is time. No rush. Also the conversion (manual / background scan, could be boolean) would be awesome to have, and maybe a hook for when the raid completed (by default a few minutes before the event ends). Having all this info when a player asks you "hey admin, where is my base?" is super useful. But I would understand if you don't want (multiple) more hooks in your plugin, which might cause follow-up questions and effort. However: This hook doesn't look right: OnAbandonedBaseEnded(Vector3 eventPos, float radius, bool allowPVP, List<BasePlayer> participants, List<ulong> participantIds, List<BaseEntity> entities) I'm missing the base owner, and you got 2x a list about participants (1x BasePlayer, 1x ulong userID) in a row, which doesn't seem to make a lot of sense. I assume one of them should have owner information (?) -- The other hook also doesn't appear to have owner info. Maybe it is just me, but I don't get how you can have a list of intruders already when the Raid begins. Sorry for me asking probably stupid questions. Thanks again!
-
Hey @nivex I wonder if you could share hook methods I could subscribe to with my plugin. I want to log some events to Discord, and in the .cs source I found some hook signatures, which seem to be more or less similar to what you have in Raidable Bases (those hooks I successfully subscribe to, that works like a charm). But Abandoned Bases does not seem to play nice. I'm looking for these signatures but on my Logger I get nothing at all. In your source I found this: a) Potential base found OnPotentialAbandonedBaseFound(Vector3 eventPos, ulong ownerId) b) Abandoned Base started OnAbandonedBaseStarted(Vector3 eventPos, ulong ownerId, bool allowPVP, List<BaseEntity> entities) c) Abandoned Base completed OnAbandonedBaseCompleted(Vector3 eventPos, ulong ownerId, bool allowPVP, Dictionary<ulong, BasePlayer> participants, int lootCount) d) Abandoned Base Event end OnAbandonedBaseEventEnd(Vector3 eventPos, ulong ownerId, bool allowPVP) Currently I'm testing by manually running /sar convert - could it be that manual events trigger other hooks? Or do I need to pick other hooks? It would be great if you could shed some light and hint to which hooks to use for a) b) c) and d) Thank you!
-
Hey there! Carbon user here. I'm observing sporadic crashes on my server with Wallpaper Planner, when players use it. The player gets disconnected when this happens.
-
Thank you @nivex for all your hard work, especially to address concerns about changed ToS. Personally I will do both, enable the new option to suppress paid and DLC items, and additionally use cleaned loot tables (your original from the Tier 3 bases pack, cleaned using a loot table editor) because APIs can fail and I don't want to blindly trust an option. Nonetheless I find your level of support and commitment outstanding and inspiring. Thank you so much. If you ever decide to sell support packages (= donation) to generate some extra income for your hard work, I'm pretty sure not only me will be happy to buy one once in a while. Such packages could be several sizes, depending on how much a user wants to support or can afford - not sure if codefling allows such "empty" packages. It has been about 2 years since I purchased your plugin and bases pack, and it feels a bit strange to have you working on and improving your fantastic plugin, and getting nothing in return. Keep up the great work!
-
Suggestion: Add hook for Abandoned Base too small, filtered, skipped
miniMe_rust posted A Support Request in Support
Hey there! I wonder if you think it is beneficial to add a hook (e.g. OnAbandonedBaseSkipped) for such Abandoned Bases which don't meet the criterions to become raidable, e.g. not enough foundations or all Twig. I'd like to use such an event from Abandoned Bases for logging purposes - currently I only see the converted and finished bases, but the filtered ones slip through. Sometimes players complain about bases being gone, and in such cases my log is empty. Thanks in advance for checking -
Raidable Bases (Tier 3 Package) - Plugin sold separately. Bundle available.
miniMe_rust commented on nivex's file in Bases
Hi @nivex any chance you update the included loot tables to address the changed Facepunch TOS? I followed your suggestion over on the Raidable Bases plugin page and got myself the loot table editor you suggested, also verified it's output with the online check tool for prohibited items (https://app.rustspain.com/facepunch/checkitems). The loot table editor did remove DLC items flawlessly and I got clean loot profiles. But there were warnings from the loot table editor after removing DLC items that bases likely won't have enough items to spawn. I think the problem is that with the removal of the DLC items in the "Difficulty_Loot" profiles the number of available items actually is reduced, and could lead to player complaints about bases having too little and "not good enough" loot. I never changed the original loot profiles you provided with this bases pack, because it was just right and worked great, and players loved the resulting raids. It would be awesome if you could find the time and update the profiles in a sensible way. That would also help customers who buy now and run into the TOS drama. Thanks again -
Hi @nivex, if I understand the rule changes clarifications about Facepunch's TOS and their FAQ right it is all about not being allowed to drop skinned items in a Raidable Base's loot which the participant in the raid does not own. At the same time Facepunch states they have no problem with NPCs using such skins, or decorative elements using such skins. While you're thinking about how to detect which skins a raid owner has in their library, I think the most important configuration change lies within `carbon/configs/RaidableBases.json` within this snippet: "Loot Items": { "Use Identical Skins For Stackable Items": true, "Use Identical Skins For Non-Stackable Items": false, "Use Random Skin": true, "Use Workshop Skins": true, "Use Imported Workshop Skins File": true, "Use Approved Workshop Skins Only": false }, In my eyes all of these lines (except the first line) must be changed from "true" to being "false" - and, if I'm not mistaken - skinned items in a raid's loot should be gone. What is your take on it? Are more configurations needed or suggested? I'm thinking of the option which removes locks from doors when the raid is done, that should be in the raid profiles. That would allow players to pick up skinned doors before the base despawns. That should probably not be possible