BlackLightning

Changed Status from Pending to No Response

When dynamic is disabled, whether the decorative inner tube is displayed is determined by the Enabled property. Have you see that to false as well?

Changed Status from Pending to Closed

I'll go ahead and close this out since it seems like there isn't anything for Bag of Holding to do differently.

If you get any pushback from the developer, simply emphasize that the user experience is wrong. Moving an item with right-click or hover-loot should not empty its contents. Items should also not be emptied when added to a container by a plugin (i.e., when the virtual backpack is initialized). This is not a plugin compatibility issue, it is a stacking plugin issue, which happens to present a worse experience for plugins that allow players to store large quantities of items inside other items. The developer may "blame" this issue on there not being a proper hook for their use case, but that should cause them to not try to implement that feature in the first place, rather than degrade user experience by implementing it the wrong way. The developer has previously insisted that other plugins, such as Bag of Holding, should not use the CanStackItem hook while Stack Modifier is loaded, as SM should handle it correctly. If the developer wants to make that claim, they need to also implement it correctly. If they want to back down from that claim, they can expose a way for other plugins to dictate the behavior of that hook instead, since if BoH tries to use that hook now it will result in a non-deterministic conflict.

I parsed through both descriptions, and something occurs to me, especially regarding the second case where trying to take the bag spilled out the contents. Are you using Stack Modifier? Around the time that Bag of Holding was in beta, an issue was discovered with Stack Modifier where it could empty the contents of any item, including these bags, in order to allow the item to be stacked with another. The way we solved it was by updating Stack Modifier to only apply that behavior to items that appear to have a container in vanilla. However, the Facepunch Backpacks update required some changes to be made in Bag of Holding, which unfortunately have resulted in that logic in Stack Modifier no longer working, so it looks like that issue should have returned. To reproduce the issue, you can probably do something like the above screenshot. Basically, make two bags with the same skin/capacity, place items into one and place that one in another container, then right-click or hover-loot that bag into your inventory. I'm guessing this will cause it to spill out and possibly stack with the other bag in your inventory. To mitigate this issue, you should be able to disable stacking of large halloween loot bags, as that will prevent Stack Modifier from trying to stack them. Note that even if you are not using Stack Modifier, this issue could exist with other stacking plugins. The proper solution should be for the Stack Modifier maintainer to simply remove this "auto-unpack" logic from the plugin. This is suggested because the developer implemented that logic under the incorrect assumption that any time the CanStackItem hook is called, that the player must be intentionally moving one item onto another, which is not true because the game will automatically test various similar-looking items for stack eligibility when right-clicking/hover-looting, which is inadvertently causing this issue. I suspect this is the same root cause as the issue happening in the Virtual Backpack. In a previous discussion with the Stack Modifier developer, he was hesitant to remove this logic because he believed "people expected it", and "it wasn't causing issues since it hadn't been reported" even though it was made clear to him at the time that the logic was wrong.

Can you paste the exact wording used by the all reports of this issue? Sometimes the player's description of the issue includes nuances that can help with the investigation. When you say custom bags, do you mean bag profiles that you defined in the config, in addition to the ones provided by default? Note that there is no functional difference between custom bags and the ones provided by default, they all simply operate according to how they are configured, so any correlation here is probably coincidence. As for items spewing on the ground, that sounds like a capability of the Backpacks plugin, where opening the backpack can spew overflowing items if the backpack capacity has reduced since it was filled. Bag of Holding doesn't do anything like this, so that sounds like something is happening on the Backpacks side. Did players see the contents of the bag spewed out or was the bag itself simply spewed out of the backpack with other items from the backpack? If items spewed out of the bag itself, I don't know what would cause that. Items being unusable is a known phenomenon in the Rust modding world which happens when the HeldEntity of an item was killed. This doesn't happen in vanilla Rust, but can happen in some modding situations which should be avoidable/fixable. Servers using item cleaner plugins such as Broken Items Cleaner will probably see this often because that plugin aggressively kills HeldEntity instances if it isn't aware of the item that created the HeldEntity,. That plugin isn't coded to find items inside of other items recursively, so it may break items inside of bags. There was a brief issues after a Rust update quite a few months ago where placing a bag on the ground and picking it up would kill any HeldEntity instances associated with items inside the bag. This happened because Rust by default tries to parent the HeldEntity instances to the bag world model entity, so when the world model entity is killed, Rust automatically kills the child entities. This was resolved in a previous update by preventing the HeldEntity instances from being parented to the dropped bag.

Changed Status from Pending to Closed Changed Fixed In to 1.9.3

Thanks for reporting this issue! I appreciate the screenshots which made the issue very clear. It has been fixed in v1.9.3.

Changed Status from Pending to Closed Changed Fixed In to Next Version