All Activity

Hi, the custom build spot in W24 is not accessible; the entrance is visible but it looks as though it is slightly below ground level, which is preventing entry, so could this please be checked and adjusted so it can be accessed properly?

The tiers just represent the upper and lower values that the item can spawn with. For example: C tier: 10-20% B tier: 21-25% A tier: 26-30% S tier: 31-35% The numbers next to the letter is the actual buff value. For example if it says 0.5, it means 50%.

Some reason this has started spamming my console. Any idea? Thanks Failed to call internal hook 'OnEntityTakeDamage' on plugin 'MonumentEvents v1.1.7' [952055589] (Object reference not set to an instance of an object.) at bool Oxide.Plugins.MonumentEvents+MonumentEvent.IsEventNpc(ScientistNPC npc) in /home/container/carbon/plugins/MonumentEvents.cs:line 4181 at void Oxide.Plugins.MonumentEvents.OnEntityTakeDamage(ScientistNPC npc, HitInfo hitInfo) in /home/container/carbon/plugins/MonumentEvents.cs:line 4849 at object Oxide.Plugins.MonumentEvents.InternalCallHook(uint hook, object[] args) in MonumentEvents.cs/Internal:line 350

I don't know if it was instantly after the restart. But sounds like he noticed after an hour I'll ask him to test again

Changed Status from Pending to Closed

ah, no worries. have fun

Apologies for the late response. I attempted to debug the issue, but wasn't able to finish before I was relocated out of country. I couldn't remote into my machine due to the lack of Google services. I have informed WhiteThunder (the developer of ItemRetriever) of the issue and linked your fix so he has an easy time looking into the issue. You can see my post here to WhiteThunder: https://umod.org/community/item-retriever/57739-player-disconnect?page=1#post-2 Since this fix is contained within ItemRetriever, we should wait for him to update it or respond. Thank you.

its good information for sure, can you confirm if this happends after a server restart? you mention "being there an hour after reset but then gone" To me it sounds like After a server restart then the rug will disappear?

Yes thank you in will adjust that appreciate the feedback back sir

Almost a month has passed, but not all the deep sea content has been added to the plugin. I haven't seen a single bot in this configurator yet!

The player tested again and reported this. I know it prob doesn't help much. But the issue seems to only happen when the rug is placed hanging off of a triangle floor "oh yeah its only on a the triangle floor, that this is happening on, the foundation ones ive placed are still there. where as the ones on the raised floors disappear. i though ahead about this and placed a few others in different spots and square floors and foundations had no issues, and triangle foundations where also ok, just the hanging triangle floor rug sees to be the issue with removing. It seems to be a 48 hours from when i placed it. being there an hour after reset but then gone."

Changed Status from Pending to No Response

Changed Status from Pending to No Response

Changed Status from Pending to No Response

Changed Status from Pending to No Response

Changed Status from Pending to Not a Bug Changed Fixed In to 6.0.0

This may be more of an issue with customitemdefinitions, but I am surfacing it here first since it affects items created via this plugin. While testing custom wearable items created via CustomItemManager + CustomItemDefinitions, I found a consistent behavior difference based on the custom definition’s Repairable flag: If a custom wearable is defined with Repairable=true, when condition reaches 0 it behaves like normal Rust clothing: it remains equipped and shows as broken (red exclamation), rather than disappearing. If the same item is defined with Repairable=false, once condition reaches 0 it is removed from the wear container (appears to “poof” rather than remain broken). In our case, this removal could also coincide with other worn items being displaced/disappearing when stacking/combination plugins were present (likely due to wear/equip refresh events firing at the same moment). For reference, this was occurring when I also had custom clothing combinations loaded - though the issue only surfaces when toggling the repairable flag in CIM. In CustomItemDefinitions, definition.repairable is applied directly to the underlying ItemDefinition.condition.repairable, so this is not just “can’t repair at a bench” — it seems to change runtime condition behavior. Workaround: For any custom item intended to be worn and allowed to reach 0 condition without vanishing, Repairable=true must be set (even if actual repair is undesired). I didn't really want these items repairable, but unless I have them set to true they end up vanishing (and taking other worn items with them) when reaching 0 durability.