All Activity

Yes, but it will be later, because I have another map loaded right now.

Could you provide a screenshot of the issue?

Neither in RustEdit nor on the test server where I’m testing this—while loot in other locations works fine—does the motel provide anything other than a single fragment in one cupboard.

Changed Status from Pending to Fixed

Changed Status from Pending to Fixed

Changed Status from Pending to Can't Reproduce

Hey! First of all, I'm sorry for the late response. I missed your ticket while I was busy working on other things. Thanks for providing your config. I have a few questions to help me understand exactly what happened and hopefully reproduce the issue. Just to clarify, are you sure the event hadn't reached its lifetime limit and ended automatically? The locked crates are supposed to be destroyed when the event ends due to its lifetime expiring, provided they haven't been looted. According to your config, the event lifetime is set to 1800 seconds (30 minutes). Since nobody else has reported this issue so far, I'd like to understand the exact circumstances in which it occurred. Did all three crates disappear simultaneously while the event was still active, with the event marker still visible on the map? Or did the event end or its marker disappear around the same time? Any additional details would be helpful in tracking down the cause. I'll also use your config to try to reproduce the issue on my end. Thanks for reporting this!

Is the map not showing up in RustEdit?

Changed Status from Pending to Not a Bug

Changed Status from Pending to Feature Request Changed Fixed In from Not set to Next Version

Hey! First of all, sorry for taking so long to get back to you, and thank you for your patience and for the additional suggestions. Regarding viewing container history while in Vanish, especially when a box is protected by a Code Lock, I've started looking into how this could be implemented properly. Unfortunately, it's a bit more complicated than I initially expected, as the current plugin relies on Rust's standard container looting mechanics. Allowing admins to access the history without authorizing on the lock may require changes to how the plugin handles container interactions. I may be able to find a solution, but I don't want to rush an implementation that could break existing functionality or negatively affect the experience of people who are already using the plugin. I'd rather take the time to investigate the underlying logic and make sure any changes are reliable before introducing them. Regarding your other suggestions, I agree that having a more comprehensive history of who deposits and withdraws items would be useful. Adding support for quarries and pump jacks is also something worth exploring, although these features may require additional work to handle their mechanics correctly. I'll keep all of these suggestions in mind and look into what's feasible for future updates. I can't promise a specific release date yet, but I'd prefer to implement these features properly rather than rush them and risk introducing new issues. Thanks again for your feedback and for using the plugin!

yes the items spawn but without the metal insert slots only default always as for example the kilt i got from heli signals came with the 3 slots i hat set in config the facemask i got in nightmare dungeon should spawn with 1 slot but has zero slots for the inserts bnut otherwise is all working

Changed Status from Pending to No Response

Changed Status from Pending to Not a Bug

The smoke is currently an integral part of the event mechanics, so adding an option to disable it isn't as straightforward as it might seem. Certain suicide bots spawn behind the smoke, which serves as both visual cover and an important part of the event's pacing. It helps create the intended surprise when the bots emerge, rather than having them appear out of nowhere or run directly at players without any visual context. Simply removing the smoke could break this part of the encounter and negatively affect the overall gameplay experience. To implement this properly, I would need to rethink some of the underlying logic and refactor parts of the event system to ensure everything continues to work as intended without the smoke. I'm not ruling out this feature, and I'll consider it for a future update. However, I'd prefer to take the time to design and implement it properly rather than rush out a configuration option that could compromise the event mechanics. Thanks for the suggestion!

Changed Status from Pending to Fixed Changed Fixed In from Not set to Next Version

I placed the files as you described; the rest of the map is fine, but at the motel, only one map fragment appears. Sorry to bother you—I’m new to this and a bit lost. Thanks again!

Changed Status from No Response to Closed

Changed Status from Work in Progress to No Response

Changed Status from Pending to Not a Bug

Yeah, it has been in description since underwater labs update. Not much I can do to change it.

Sorry mate I mass closed them - there was 790 notifications in my list from tickets dating back to 2024 that were done, but weren't closed. Bound to have a few fall through the cracks. __ Found it. CIV only accepts a payment item whose name matches the currency name exactly, capitals included. STIP builds item names from the profile name plus the effect details, and buff names include the duration, e.g. midnight protocol [+100-150% - All[900s] - Time: 18:00 to 06:00]. When you shortened the buff durations, every newly created buff got a new name (e.g. [600s]), so it no longer matches the [900s] entries in your CIV config. The XP shards have the same problem for a different reason: STIP names them in lowercase, common quantum shard [XP: 7000], while your config has Common Quantum Shard [XP: 7000]. Changing the config afterwards won’t fix listings you already have, because each listing saves its own copy of the currency name when it’s created. To fix it: Spawn each item with stip.give and copy its exact name, or update the displayName values in the CIV config to match the format above with your current durations, all lowercase. Reload CustomItemVending. Delete the affected listings and create them again. Bear in mind that if you change buff durations again later, the names will change too, so you’ll need to repeat these steps. For the third listing, what exactly happens? Does it show 0 stock, or does the item not appear in the list at all? A screenshot would help. common quantum shard [XP: 7000] // Are not the same Common Quantum Shard [XP: 7000]