Hey,

Do you have any intentions to add the ammo options any time soon? It's the last thing to replace the AntiItems plugin, which this plugin does most of now.

I would like to. It's just a bit trickier to implement since Rust handles it differently.

For most item consumption operations, Rust will first call a function to see if you have enough. Then it calls a function to either delete or move that many of the item. Item Retriever works by hooking both functions.

With ammo, Rust asks for a list of all items that match the ammo type, then Rust may or may not do something with those items. For the Backpacks use case, where the items actually exist in your Backpack, that works fine, but for Virtual Items, the ammo items don't actually exist, so the plugin would need to create the items. The problem is, if the thing that asked for the ammo doesn't use it, the item gets basically leaked into oblivion. Virtual Items will need a good way to handle that leaking, I just haven't decided how I want to solve it since there are multiple possible solutions.

Makes sense, thanks for the explanation!

I just pushed v0.5.0 with support for reloading.

Whilst it works, the ammo from the reload is placed in the inventory if your mag isn't empty. I'm not quite sure how AntiItems does it, but it's rare that it gives the player the items (rare cases with bolts and M249s).

I can test later but it seems that I couldn't have 2 permission groups either. When I created and assigned ammo, my custom permission group with materials didn't work. Fixed by putting them all in 1 config.

Merged post

I'm leaving it enabled on my server for a while, see if there's any feedback. It's rare that people will change ammo types too often but I guess it could be open to abuse getting ammo, topping up turrets or recycling. Not too much of an issue for my server though. 1 less plugin!

That's expected. Switching ammo or explicitly unloading the weapon will add its current ammo to your inventory. The ability to extract items created by this plugin is certainly a risk to server economy, but I estimate it would be a perilous journey to try to block all such abuse cases, so I've opted to just not try to solve that problem. Instead, I have simply called out that risk in the plugin documentation.

As far as multiple rulesets go, you can only have one assigned. This is explained in the documentation, and this is the pattern I typically follow with permission-based rulesets/profiles.

As for Anti Items, it works by placing large item stacks in invisible slots in the player inventory (after slot 24). If you have ammo in those slots, reloading will take items from those slots. If you unload the weapon, the ammo may go into the same slots, or may go to new slots, depending on how full the invisible item stacks are.

For comparison, the way Item Retriever + Virtual Items works is that instead of placing actual items in those invisible slots, your client only receives network snapshots from the server declaring that the items are there, but the items are actually not. That solves some problems that Anti Items has such as having to replenish the items, and plugins such as Kits finding those items by mistake. However, not having the actual items there means Item Retriever + Virtual Items have to be deliberate about hooking and modifying the game code to allow server side validation to pass and to allow the items to be accessed/created when needed. Utilizing these hooks comes with a greater performance cost than imposed by Anti Items, and while there are more performance improvements I can make if necessary, the simplicity of Anti Items means it will always be more performant. Ultimately I went with the design I did because it allows solving more use cases than just Virtual Items, since Item Retriever can be used to access items from theoretically anywhere.