-
Posts
5,937 -
Joined
-
Last visited
-
Days Won
200
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by nivex
-
@Grumpy Old Man PlayerDLCAPI is not used by RaidableBases. It is used by other plugins though. So if you have any plugins using it, then it should not be removed. Such as Kits. RaidableBases has no dependency for any plugin other than CopyPaste, and an optional dependency for Spawns Database. It checks all DLC internally.
-
- 634 comments
-
- #rust
- #rust plugin
- (and 6 more)
-
Known bug: metal detector sources and other such entities with enableSaving set to false will block custom spawn points. I will fix this, but I'm going to wait a bit and see if any other issues pop up first. Here's a fix for anyone that needs it now. On line 12615 change : if (e is BuildingBlock || e.ShortPrefabName.Contains("wall.external.high") || !e.enableSaving || e.HasFlag(BaseEntity.Flags.Locked)) to: if (e is BuildingBlock || e.ShortPrefabName.Contains("wall.external.high") || !e.enableSaving && e.HasFlag(BaseEntity.Flags.Busy) && e.HasFlag(BaseEntity.Flags.Locked)) I wish more developers would use dedicated or dummy skins instead, it would be easier to detect your events since I won't use any API for that as it would be too expensive in this method.
-
TOS Compliance Overview: Deployables will spawn as usual. No players will be able to pick up DLC deployables. All players can pick up skinned deployables, but the skin will be removed upon pickup to ensure compliance. Players that own the content are no exception, yet. I tried but failed, so it will have to wait for another update. Restricted items, including skinned turret weapons, will not spawn in containers. If any exist in copypaste files, they’ll be removed from the event (but not the original file) Skins will be reset before being spawned into the game. No skins are allowed unless... If you want skins, you must use the ImportedWorkshopSkins or SkinsPlugin files found in the RaidableBases data folder. This will remain the solution indefinitely. The old method of flooding skins into every corner of the game diluted their value and killed the excitement of collecting them. This (forced) change will bring that thrill back and restore meaning. In short, everything will function as decor, ensuring compliance with the TOS. I don't have time for any questions right now. Save them until tomorrow after the game update. What do you need to do? Just download the update when it’s ready and install it alongside the game update — the usual. Easy. I can only hope my solution eliminates the need for manual edits, but if there’s one thing I’ve learned in programming, it’s this: anything that can go wrong, will go wrong. It’s only a matter of time — Murphy’s Law always finds a way. I will release the plugin update when it's ready, it requires the game update so don't wait around for it. It'll be a few hours yet.
-
@EllieCat @miniMe_rust and others I haven’t had the chance to work on the tier packages yet — all my time has gone into making sure the RB plugin is fully compliant, which takes top priority right now. I’m sure you understand how important that is. The good news is: the plugin update will enforce compliance by default. No one will need to modify the tier package files. Once a tier package update is released, you can go ahead and update it, but keep in mind that doing so means starting from scratch. Tier updates are mainly useful for people who haven’t made edits, recently purchased, or want a fresh start. But there’s no actual need to update unless you want to. RB Plugin Update: There are commands to either remove all restricted content, or replace it with its non-restricted counterpart where applicable. This will save a lot of time editing files manually. TOS Compliance Overview: Deployables will spawn as usual. No players will be able to pick up DLC deployables. All players can pick up skinned deployables, but the skin will be removed upon pickup to ensure compliance. Players that own the content are no exception, yet. I tried but failed, so it will have to wait for another update. Restricted items, including skinned turret weapons, will not spawn in containers. If any exist in copypaste files, they’ll be removed from the event (but not the original file) Skins will be reset. If you want skins, you must use the ImportedWorkshopSkins or SkinsPlugin files found in the RaidableBases data folder moving forward. In short, everything will function as decor, ensuring compliance with the TOS.
-
@DrayTemplar Hi there, thank you for the support! 1. Carbon would need to implement such support as its their platform and interface. I don't recommend that they do this though. This is not your standard plugin, and should be updated manually. Reloading the plugin despawns all events, and players will have to start all over again if you accidentally try to update. It's a nightmare waiting to happen, and I've seen it happen multiples with other plugins already. But it's ultimately up to Carbon if they decide they want to implement support for that! 2. You don't need to worry about any tier packages of mine violating the TOS. The next plugin update will handle everything automatically, ensuring compliance with the TOS by default. This means you don't need to edit anything. You only need to update the plugin with the game update. Or it will not compile.
-
Message: OnLockedToRaid Option: Lock Players To Raid Base After Entering Zone Applies To: Buyable / Manual / Maintained / Scheduled Events Shown when a player enters an event. This option locks the player to the raid, NOT the raid to the player. Locking the raid to the player uses separate options. Message: BuyCooldown Option: Buyable Cooldowns Applies To: Buyable Events Displayed when a player attempts to use the /buyraid command while still on cooldown. This message does not prevent entering a raid, nor does it show the cooldown when entering a raid — it only blocks purchasing them, and is only shown when being blocked from that purchase. Message: LockedOut Option: Player Lockouts Applies To: Maintained / Scheduled Events Shown when trying to enter a public event while on a lockout. Not related to Buyable Cooldowns, and not related to Buyable Events.
-
@Tay Hi, I think the confusion is coming from the translation. First, it said "cooldown," now it says "locked," which changes the meaning. This option doesn’t lock the raid to the player — it locks the player to the raid. That means they should finish that raid before they can start another one. Set to true in the config: This message is shown, OnLockedToRaid: If instead you want the raid to lock to the player, that happens when the player deals damage, not when they enter. That behavior is enabled by default, and there’s no message shown when it happens. It is displayed in an update to the Status UI, visible only when the player is inside of an event. I hope this clears things up. I understand translating is difficult when it's not accurate.
-
@Tay Heya, relevant messages are shown already. Buyable Cooldowns Buyable Cooldowns do not restrict event entry. They are used to limit how frequently players can purchase events. When a purchase is blocked due to a cooldown, a message is always displayed explaining the reason. This is not used with public events. Player Lockouts Player Lockouts prevent players from entering public events. When a lockout is triggered, a message is displayed and any active lockouts are listed in the Lockout UI. If no message appears, the lockout is either not configured or you do not have a lockout for that difficulty. This is not used with purchased events. Bypassing Lockouts Vanish, noclip, and the permissions raidablebases.lockoutbypass or raidablebases.canbypass will allow you to enter. This is intended so you can easily assist players without interfering with game play. Cooldowns and lockouts are not interchangeable. They serve different purposes and are named differently for that reason.
-
@Tay I've responded in DM. I've tested Easy, Medium, and Hard from Maintained Events using your files and each event locks to the player (on damage, never on entry) as expected. I changed Difficulty Level for each back to its respective value (0=easy, 1=medium, 2=hard, etc). This must be from some error, or an issue with RealPve, as no such issue exists in RB. Several people use both RealPve and RB so I am sure you can sort it out if you ask that developer. He has his own RB implementation, which deviates from mine, so he will be the only one that knows what the issue is since it's not my code.