-
Posts
5,658 -
Joined
-
Last visited
-
Days Won
194
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by nivex
-
NPC's Have Vanished And Turrets Are Missing Weapons Since Update
nivex replied to MatthiasBM's Support Request in Support
@MatthiasBM Your exact issue was fixed by removing Turbo Weapons and restarting the server. If that doesn't work, then you'll have to find the plugin causing your issue -
NPC's Have Vanished And Turrets Are Missing Weapons Since Update
nivex replied to MatthiasBM's Support Request in Support
I can't say without the error. This shouldn't be caused by RB. Update Kits by Mevent Unload TurboWeapons. Make sure LootEnhancer is configured. Loot not dropping from boxes is not caused by RB -
Buyable raids not spawning using Spawns Database
nivex replied to MNfreakTim's Support Request in Support
I'm really not sure about rustedit. best to ask a map dev -
hi, this would be caused by another plugin. we are trying rcon narrow it down. but its inconsistent
-
NPC's Have Vanished And Turrets Are Missing Weapons Since Update
nivex replied to MatthiasBM's Support Request in Support
hi, this shouldn't be related to rb TurboWeapons caused this for other people as did misconfigured LootEnhancer -
Buyable raids not spawning using Spawns Database
nivex replied to MNfreakTim's Support Request in Support
Hi, it means the spawn points are not available This is likely due to metal detector sources blocking the spawn point, implemented in this game update. See my fix, here: https://codefling.com/plugins/raidable-bases?page=157&tab=comments#findComment-70932 -
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.
-
Changed Status from Pending to Closed
-
No problem Enjoy
-
Hi, it requires the Rust update See the update notes
-
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.
-
Hi, I've added the despawnDateTime back to the hook. As for GetAllEvents, this will not work, and the code you're referencing needs to be updated in RealPve. public enum RaidableMode { Disabled = -1, Easy = 0, Medium = 1, Hard = 2, Expert = 3, Nightmare = 4, Points = 8888, Random = 9999 } This enum is no longer used, everything is dynamic now, and pulled from the profiles. As of version 3.0.0 (released February 6, 2025), dynamic difficulties were introduced with the rb.difficulty command. This allows users to: Rename any difficulty Remove any difficulty Add unlimited additional difficulties Here are some examples of what this means: Users may change the name Easy to Beginner Users may change Easy level from 0 to 10 Users may add a new difficulty, using any name, and any level. There is no limit. They can create as many new difficulties as they like. I've seen upwards of 20, and as few as 2. [HookMethod("GetAllEvents")] public List<(Vector3 pos, string mode, int level, bool allowPVP, string a, float b, float c, float loadTime, ulong ownerId, BasePlayer owner, List<BasePlayer> raiders, List<BasePlayer> intruders, HashSet<BaseEntity> entities, string baseName, DateTime spawnDateTime, DateTime despawnDateTime, float radius, int lootRemaining)> GetAllEvents(Vector3 position, float x = 0f) { return new(Raids.Select(raid => (raid.Location, raid.Options.Mode, raid.Options.Level, raid.AllowPVP, raid.ID, 0f, 0f, raid.loadTime, raid.ownerId, raid.GetOwner(), raid.GetRaiders(), raid.GetIntruders(), raid.Entities, raid.BaseName, raid.spawnDateTime, raid.despawnDateTime, raid.ProtectionRadius, raid.GetLootAmountRemaining()))); } [HookMethod("GetAllDifficulties")] public List<(string mode, int level)> GetAllDifficulties() { return new(Buildings.Profiles.Select(x => (x.Value.Options.Mode, x.Value.Options.Level))); } I've made the above change to GetAllEvents, to include the mode and the level, and added a new method. The solution is simple. Allow the user to map the difficulty mode to a level in your configuration file, and use the GetAllEvents API to match with that configuration. I've included an additional GetAllDifficulties API for you for ease of use, allowing you to easily create a default mapping in your configuration. But, it is still required that the user map them in your configuration file whenever they make changes in the future.
-
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.
