Need way to control what is allowed into any inventory

[NanoTree]

I'm currently looking for way to control what specific items can go into specific slots in an inventory. I need a way to do this for vanilla IInventory's, as well as, potentially, any other mods. More precisely, I'm looking to intercept, work around, or directly "hijack" the method at runtime: 

public boolean isItemValidForSlot(int slotNumber, ItemStack itemStack)

belonging to a TileEntity object implementing the IInventory interface.
 

To elaborate, I need any object that implements IInventory (Vanilla or modded) reject any type of item being placed in any slot of that inventory unless it is the specific item I want to allow. The problem I am running into is how do you make this happen with any existing Objects implementing IInventory. I have a pretty good idea of how I might be able to control what goes in inventory slots when the player is placing items using a GUIContainer. Doing so when automation occurs seems to be quite a bit more tricky.

My idea so far:

• Place ItemStack of item I want to allow in slot of size 1. Decrement 1 from ItemStack size just before or just after slot accepts more items of same type and before next update tick (unsure how to implement this). Some how insure there wasn't overflow.

The thing is, I'm not sure how to detect when an inventory slot has changed, other than mapping references to all IInventory TileEntities in the affected loaded chunks and exhaustively comparing their contents to a previous state. This seems excessive and too computationally expensive for something so simple and that could potentially happen frequently.

I've already devised a way to store information associated with TileEntities implementing IInventory in a chunk's NBT. I suppose all I need is a way to monitory which TileEntities are changing.
 

Has anyone done something like this before in another mod that I could use as an example? It has to be compatible with any TileEntity implementing IInventory.

Thanks!

Edited March 6, 2017 by NanoTree

[Draco18s]

Use capabilities.

[NanoTree]

Hmmm, alright. Looks like I have to do some more tinkering. This will work great for all the of the versions that are currently officially supported.

Sadly I was hoping for a solution that was a bit more backward compatible, as many of my favorite mods are still not with the current yet, and may never be.

Thanks though! For now I'll see about getting this working.

Edited March 6, 2017 by NanoTree

[Blackop778]

Tip to surviving on this forum: don't mention 1.7.10. They'll lock your thread. It's not fun.

Edited March 6, 2017 by Blackop778

[larsgerrits]

6 hours ago, Blackop778 said:

Tip to surviving on this forum: don't mention use 1.7.10. They'll lock your thread. It's not fun.

 

 

 

[NanoTree]

 

9 hours ago, larsgerrits said:

Tip to surviving on this forum: don't mention use 1.7.10. They'll lock your thread. It's not fun.

**spits out coffee**1.7.10?! Who said anything about that?!

Anyway, yeah, I noticed. I've been creeping on the forum for a little over a month in my limited free time. My original plan was to learn how to make a mod in... that version, so I might then port it and learn some of the sticky situations I'd run into porting someone else's mod in the future. This is why I managed to overlook Capabilities though.

And I totally get it. Supporting old versions forever is not realistic/sustainable, and is bad for modding in general anyway. I'll just have to get savvy enough to port/revive any old favorites.

Besides, it appears I'd have to dive into core modding in order to get my idea working for... that version. And though I'm confident I'd eventually make it work, this is much easier and I think I'll build a functioning mod for 1.10.2 first after all.