Raidable Bases 3.0.5

I think you might want to ask them if you have a channel to, directly about your plugin. essentially it emulates what could and would happen on vanilla servers, where a base is raided, and a player might find items that are skinned or dlc content. not sure how a player raiding a base, is the equivalent of something like skinbox or /s in server rewards or custom crafts, but seems like a gray area. your plugin is probably the most popular plugin of all rust

@PhatBlinkie

Heya, thanks for responding with valuable feedback.

I can understand that perspective, and it might hold more weight if raid bases were rare, risky or difficult to access. However, in practice—especially on PvE servers—players can freely and repeatedly access raid bases with minimal effort and walk away with a large amount of skinned or DLC items.

That kind of accessibility significantly undercuts the value of content and contributes to Facepunch's reduced sales.

From a developer’s standpoint, I have to consider both the player experience and the broader impact on Facepunch’s monetization model. Given how widely used this plugin is—and how easily it enables access to premium content—I think it’s reasonable to expect Facepunch would take issue with that.

Personally, I’ve never supported the idea of plugins handing out paid skins or DLC content freely. These features were implemented purely in response to community demand. At the end of the day, I build for you—the community—but I also have to respect the boundaries set by the game’s creators.

I had an essay written up, but its deleted due to being defeated. I disagree with how they are enforcing this, and doubt they financial troubles. This will cost them players and should have ben handled by them inside the game instead of threatening 50k modded servers with bans, just crappy

this is also a problem for many plugins, and I appreciate the devs like you and k1lly0u and others that tackle this themselves to comply and make it simpler to the rust admins. I spent a few hours cleaning up custom crafting, server rewards, and other plugins. It's a little hard to even figure out what is dlc vs not. for example, i find listings of gifts from fp, like the frog boots that were given for using the beta, and other things like the twitch sunglasses and trophies that were definitely free in the dlc listings. 

I like many others are very annoyed at the moment, that they didnt fix this problem themselves inside the game, and put it onto the plugin devs. Ill get over it. but sheesh, really annoying.

@PhatBlinkie

You're welcome, and I understand your frustration. Let's wait and see what their next response is. They're going to clear up some concerns that have been raised. In the mean time, you could try writing your concerns to them.

You can use this resource to search for any questionable skins or DLC content. It's still being actively updated to include any that might've been missed. I know it's difficult to use, but might prove helpful when using the search functionality on specific skins.

https://api.rusthelp.com/v1/facepunch/skins

Make sure you put a checkmark in the "Pretty-print" checkbox.

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

Thanks this list is 2-3 x longer than the list i had before. this is part of my concern, they should provide a list of all (official) skins by shortname or skinid or something that is actually official.

Ill wait and let this develop more but will sanitize what I can off your link nivex.
 

    {
      "name": "Tarp",
      "workshopId": 0,
      "itemDefinitionId": "124"
    }

They really need to provide an official listing, not sure why tarps are listed about 3 times, I never seen a paid for skin for a tarp.

This is a very useful tool for checking your configs & data files for now banned skins & items 

https://app.rustspain.com/facepunch/checkitems

Link courtesy of @ninco90 

kind of enforcing my point

this is pasting the file from nivex

aka, if the link was only paid items, the number of prohibited items would match the detected. maybe the format is wrong. I will not trust a tool like this unless fp weighs in when it comes to banning servers for this stuff

another admin sent me this too, which also doesnt match either other list
https://carbonmod.gg/references/items/?dlcsOnly=1

The tool i linked is using the api that nivex provided, it's just made it a more convenient way I guess. But I agree we need the full clarification from FP still

Hey @nivex
I have a question
Would setting up the SKINS section of the config perhaps stop approved skins from spawning on the bases?

 

"Preset Skins": [],
      "Ignore If Skinned Already": false,
      "Use Identical Skins": false,
      "Use Random Skin": true,
      "Use Workshop Skins": true,
      "Use Imported Workshop Skins File": true,
      "Use Approved Workshop Skins Only": false

I have about 200 raidable bases and I'm sure some of them use Approved Workshop Skins

I've also asked Misticos if we can get a config setting in Copy Paste to block approved skins

As for lootables, I'm going through each of them to make sure there's no DLC items for the raidable bases

But pretty worried about Approved Skins being used and not catching it in time

4 hours ago, PhatBlinkie said:

aka, if the link was only paid items, the number of prohibited items would match the detected. maybe the format is wrong. I will not trust a tool like this unless fp weighs in when it comes to banning servers for this stuff

Hi! What's not matching exactly? My tool uses the RustHelp API, where one of its developers currently works for Facepunch. This API collects both Steam store items and approved skins.

I believe the list also includes items that were never released or were deleted for some reason but exist hidden on Steam.

10 minutes ago, ninco90 said:

Hi! What's not matching exactly? My tool uses the RustHelp API, where one of its developers currently works for Facepunch. This API collects both Steam store items and approved skins.

I believe the list also includes items that were never released or were deleted for some reason but exist hidden on Steam.

It picks up timer numbers like 1100 and claims them to be skins so it's kind of a pain to sift through 100 extra false positives. 

1 hour ago, ninco90 said:

Hi! What's not matching exactly? My tool uses the RustHelp API, where one of its developers currently works for Facepunch. This API collects both Steam store items and approved skins.

I believe the list also includes items that were never released or were deleted for some reason but exist hidden on Steam.

this is from my raidable bases loot table being added to this tool you provided

more inconsistencies

Ahh, now I understand. What this does is search for any numerical matches to adapt to different use cases. That's why if another variable, like amount, has a numerical match, this appears.

I'll try to figure out how to filter better or even make it possible to select only the field to validate.

Thanks for the information!

2 hours ago, Dead Nasty said:

It picks up timer numbers like 1100 and claims them to be skins so it's kind of a pain to sift through 100 extra false positives. 

1 hour ago, tacman1981 said:

this is from my raidable bases loot table being added to this tool you provided

more inconsistencies

I made some improvements, now you can validate by fields.

Hi, I want to ask — I can’t find anywhere in the config a setting that if I attack a base, then there is some cooldown before I can attack another one. It lets me into the next raid, but it doesn’t add me as an owner and I can’t destroy anything. I would like a notification to show that I can’t raid because there is a cooldown and how much time is left, or ideally, to be prevented from entering the dome at all. Is this setting available anywhere?

@ChardaZAR

"Use Workshop Skins": true,

These should be set to false in your config, and it will prevent approved skins

I don't modify files. So for copypaste files you'll need an option in that plugin, or to remove the paid content manually

@Tay

Hi, it is intended that admins bypass entry to events with noclip, vanish and permissions like raidablebases.canbypass which are in the documentation

Options for cooldowns:

Public events: Player Lockouts, none of which are configured by default

Purchased events: Buyable Cooldowns, none of which apply a cooldown to admins or admins/staff/moderators that have raidablebases.allow by default

@nivex

So there’s no option to set it so that a player who has just completed a raid and tries to start another (for example, another Easy raid) — even though I have a 60-minute cooldown set — can still enter the dome, but can’t actually raid?

I need it so that the player can’t enter the dome at all, or at the very least receives a message saying they have to wait.

Just like when I have an active raid and try to enter another one — it doesn’t let me in and tells me I must finish the current raid.

@Tay

If you set 60 minutes with a Buyable Cooldown, then players will not be allowed to BUY the same difficulty again until that time elapses. This does not prevent them from entering any raid, public or purchased. There is no option to block their entry since they or a team mate are required to buy the event first.

If you set 60 minutes with a lockout from Player Lockouts, then players will not be allowed to ENTER or RAID the same difficulty again until that time expires. Player Lockouts will not block players from entering purchased events, applying only to Maintained or Scheduled Events.

If this is not working, then you've given permission that is bypassing it, or it is not configured.

@nivex

 

I don't use buyable events at all — I only have automatic (scheduled/maintained) events. I have a 60-minute cooldown set for all bases, and when a player finishes a raid, they can enter another base, but they can't start raiding it — so the system only works halfway. I don’t know where the issue might be.

Also, I’m having a problem with my custom bases. How are they supposed to be copied? When I use copy and then load them through the Raidable Bases plugin, the bases spawn under the ground.

@Tay

Timers start when the event despawns, not when it's completed. It's intended to work this way, and depending on the configuration, to block them from raiding other events when they still have an event spawned already.

Bases should be copied while standing and looking at the center foundation. Use /paste to verify the /copy worked properly.