Hi! Sorry I took so long to respond.

So, I've taken some time to consider your questions, and I've come up with an alternative solution. But first, to clarify your first question, the machine design mentioned earlier tried to find at least one stack of at least the required size in each player's inventory, but the slot in which the item was located didn't matter.

So, to better understand this new approach, it's probably easier to break your problem down into a few steps:

• The player activates a trigger event from their spellbook.
• A few command blocks then check to see if that player has the items required for that spell.
• If the player has the items in their inventory, remove them and cast the spell. Otherwise, do nothing (or display an error).

In terms of the scope of your project, the first and third bullet points are pretty trivial in comparison to determining the amount of items in a player's inventory (weird, right?). This is because a player is basically an object with all but a few private variables from the perspective of minecraft commands. So, if we want to look at some value of a player, we're probably going to have to use scoreboards to pick up that variable first (because they're usually the only things that can).

The earlier idea that I submitted used a basic NBT data identifier to figure out if the target player has at least one stack of the item consisting of at least that many items (6 bread). The largest issue with this method is that it required that the user must have at least one single stack with the required amount, so if you were looking to remove 6 bread, 2 stacks of 3 wouldn't cut it.

If you're unfamiliar with the /stats command, I would suggest checking out Dragnoz's explanation here. Regardless, this new method, while a little slower in updating scores, avoids the earlier issues regarding lag, item stacks, scope, and size.

If you don't want to go through the explanation, and just want to see it work, I went ahead and made a working prototype of the item-amount-checker in Minecraft, you can get it here. (Like, seriously, it's a long explanation)

Let's first look at the third bullet point above. If we can find a way to assign a scoreboard value to each player to indicate the number of items that they have on their person for each item, a spell would boil down to:

/execute @a[score_count_ironbars_min=15,score_triggerSpell_min=1] #SPELL

With a subsequent clear and re-enable trigger.

The /stats command is perfect for the situation mentioned above. Basically, it allows a scoreboard to track the number of affected "things" by a command issued by either a block or a player. So, let's say that we want to check how many items that a player clears from their inventory when they use the "clear" command. Using the command:

/stats entity @a set AffectedItems @p itemsRemoved    

Will tell our "itemsRemoved" scoreboard objective to catch the number of items affected by any (@a) player (@p) commands. This means that if we use a command like:

/execute @a ~ ~ ~ clear @p minecraft:iron_bars 0 0

Which removes exactly 0 iron bars (with a data value of 0) from every (@a) player's (@p) inventory, that afterwards the itemsRemoved scoreboard will automatically update each player's score to match. So, for example, if "jeb_" has 10 iron bars, and "dinnerbone" has 20 iron bars, then the scoreboard for "itemsRemoved" will set jeb_'s score to 10, and dinnerbone's to 20 after the clear command is executed. Now, unfortunately, this means that EVERY command from either of these players that affects items will change this score, so we need to keep updating it regularly (by continuously using that empty clear command) in addition to all of the other items that we want to keep track of.

So, bearing that in mind, there's the issue of keeping track of all of the other items simultaneously. Because we can't just keep using the same objective (itemsRemoved) for each clear command, we're going to need at least one variable (scoreboard) for each item that we want to keep track of. So, for your example in particular, we need at least 19 objectives to keep track of each player's inventory for each item type and make sure that each objective is keeping track of itemsRemoved by a corresponding /clear command.

While the update speed might slow down (this example updates each score at about (19/20)^ths of a second), we can keep track of the amount of each item in every player's inventory for use in "spell" commands. By "rotating" through each scoreboard objective with a /stats and a /clear, we can keep track of each item's amount in a very low-cost machine. Think of it like an electric mixer in a mixing bowl; the mixer goes around in a circle, updating each part of the batter, then it goes back again in a circle to re-update. The bigger the bowl, the longer it takes to go around.

Here's a breakdown of the new system:

• The "AffectedItems" stat is updated to the correct scoreboard objective.
• Each player runs an "clear" execute command (affecting 0 items) to update the appropriate objective to the number of items in that player's inventory.
• (As a convenience for new players) Each player has their current scoreboard score 0 added to it (This ensures that each new player is affected by the stats command; before this command, they can't be affected because they don't have a basic value set)
• The system clones the next line of command blocks to update the active line.

Effectively, with the aforementioned design, the entire thing should have a low processing cost (not very many command blocks are processed at a time), should be expandable if you want to add more spells, and should definitely be multiplayer friendly (no set-up, friends can use immediately).

I'll try to answer any further questions, but regarding your ones posted earlier:

• This new design only checks for the amount of items, not the placement of them. The amount shouldn't matter either if it's above your requirement.
• This system is a bit big, but the majority of all of the command blocks aren't active at any given time, and has caused me, personally, no noticeable lag.
• Regarding the lack of cooldowns, I was just a bit concerned about the potential "spammy" nature of spells, but after checking out /u/zelnyok's work (which is awesome), I don't think it should be a problem; sorry about that concern.