I thought i would share an idea for a new redstone component called an Evaluator.
Evaluator Block:
Crafting Recipe:
Standard Behavior:
So we have target chest (A (south side)) and comparison (sample) chests (B & C (east & west side)) (you don't have to use two) so it would function like below:
Does A contain any item/blocks types that match items/blocks that are placed in B & C? if yes output a full signal (15), if no output no signal. Signal is outputted on the north side of the block (indicated in the image).
The output can be inverted with a toggle resulting in the below behavior.
Does A contain any item/blocks types that match items/blocks that are placed in B & C? if yes output no signal, if no output a full signal (15). Signal is outputted on the north side of the block (indicated in the image).
Additional Behavior:
If a comparator is placed on the north side (where the signal is emitted) the comparator is able to emit a signal strength based on the number of items/blocks in the target chest (A). The checks will be as below:
Does A contain any item/blocks types that match items/blocks that are placed in B & C? If no, output no signal. If yes, how much space do these blocks take up in the inventory as a percentage? Convert percentage into signal strength with 15 being 100%.
As an example, if the target chest (A) was as below and B & C contained an iron pickaxe and cobblestone it would get calculated as so. (same as the comparator but only for the items/blocks that match B & C)
((stackSize / maxStackSize) + (stackSize / maxStackSize) + (stackSize / maxStackSize)) / inventorySize * (15)
((1 / 1) + (1 / 64) + (1 / 64)) / 9 * (15)
(1 + 0.015625 + 0.015625) / 9 * (15)
1.03125 / 9 * 15
0.1145833 * (15)
1.6666666666666666666666666666667
Results are then rounded up to the nearest integer. Note: 15 is the max signal strength
In summary this would result in a signal of strength of 2.
If the Evalutator is in inverted mode it would perform the same calculation as above and deduct it from 15. Using the same setup as above it would result in signal strength of 13.
Additional Notes:
When checking items/blocks it does so using there name ID.
NBT data isn't considered when doing checks. (Possible Addition: When using the Evaluator on its own it could output a full signal if it has not just a name ID match but a full match to NBT data as well, if not then a signal strength of 7?)
The quantity of items won't affect the signal strength except if used with a Comparator. In this case only the quantities in the target chest (A) are taken into account as indicated above.
An Evaluator can check for a target chest (A) up to 2 blocks away if a solid block is in between the target and the Evaluator.
Containers that can be checked are:
chests (including double)
trapped chest
shulker box
barrels
hoppers
droppers
dispensers
minecart with chest
minecart with hopper
So that's it, let me know what you think. Would you find this item useful? is there anything you would change?
The comparison / target terms need to be clarified: suggest that the Sample [the container to be checked] be tested against the Reference [the container against which this check is made].
At least initially, the simplfying restriction that the two containers must be of the same type seems wise. [Extending this to 'of the same size' should then be fairly straightforward, but comparing the contents of a hopper (5 slots) to a chest (54 slots) or similar checks introduces complexities.]
I see the evauator (as depicted) as having a toggle that inverts the output, a single port for a reference (opposite the toggle), and two sample ports.
What occurs if both sample ports are occupied? Suggest that this produce a #NULL or #ERR output.
From what point can a compartor be used to take an output? Any unoccupied seems reasonable, but ought be explicitly stated.
By what algorithm is the comparator out put calculated? Given that I am considering only same type containers at present, the ratio of the number of shared items to the maximum container capacity seems the most straightforward…
BUT, this leaves open the question of how to calculate the signal strength if less than full stacks were used in either (or both) sample and target.
[Taking hoppers as an example, and considering only the first slot being used in both the sample and target:
how would the output be calculated with 1 wheat in the sample and 64 in the reference?
........................................................with 64 wheat in the sample and 1 in the reference?
.........in the general case.................with n wheat in the sample and m in the reference?]
Considering use without a comparator:
from where would the signal be output? Suggest the toggle side
what would the signal strength be?
would this be a binary check (ie ON signal15 if any item in the sample matched any item in the reference, OFF signa0 otherwise)?
if not, how would signal strength be determined?
Is it intended to include comparison of NBT data in the evaluation? [This would be incredibly useful in sorting things like enchanted armor/weapons/ books, but (by the same token) could be seen as 'over-powered'. Including NBT data would also raise issues about data order eg. a computer will not consider Protection4/FeatherFall4 as identical to FeatherFall4/Protection4 without something more than a simple same_as test.]
§
An alternative that might be easier to implement would be to test only a single item in the sample container, outputting a high (15) signal if it matched any item in the reference container, a low (7) signal if it did not, and a null (0) signal when the sample container was empty or held >1 item.
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
These are some good questions so i'll try my best to answer them and hopefully clarify some of the functionality.
Standard Behavior:
So we have target chest (A (south side)) and comparison (sample) chests (B & C (east & west side)) (you don't have to use two) so it would function like below:
Does A contain any item/blocks types that match items/blocks that are placed in B & C? if yes output a full signal (15), if no output no signal. Signal is outputted on the north side of the block (indicated in the image).
The output can be inverted with a toggle resulting in the below behavior.
Does A contain any item/blocks types that match items/blocks that are placed in B & C? if yes output no signal, if no output a full signal (15). Signal is outputted on the north side of the block (indicated in the image).
Additional Behavior:
If a comparator is placed on the north side (where the signal is emitted) the comparator is able to emit a signal strength based on the number of items/blocks in the target chest (A). The checks will be as below:
Does A contain any item/blocks types that match items/blocks that are placed in B & C? If no, output no signal. If yes, how much space do these blocks take up in the inventory as a percentage? Convert percentage into signal strength with 15 being 100%.
As an example, if the target chest (A) was as below and B & C contained an iron pickaxe and cobblestone it would get calculated as so. (same as the comparator but only for the items/blocks that match B & C)
((stackSize / maxStackSize) + (stackSize / maxStackSize) + (stackSize / maxStackSize)) / inventorySize * (15)
((1 / 1) + (1 / 64) + (1 / 64)) / 9 * (15)
(1 + 0.015625 + 0.015625) / 9 * (15)
1.03125 / 9 * 15
0.1145833 * (15)
1.6666666666666666666666666666667
Results are then rounded up to the nearest integer. Note: 15 is the max signal strength
In summary this would result in a signal of strength of 2.
If the Evalutator is in inverted mode it would perform the same calculation as above and deduct it from 15. Using the same setup as above it would result in signal strength of 13.
Additional Notes:
When checking items/blocks it does so using there name ID.
NBT data isn't considered when doing checks. (Possible Addition: When using the Evaluator on its own it could output a full signal if it has not just a name ID match but a full match to NBT data as well, if not then a signal strength of 7?)
The quantity of items won't affect the signal strength except if used with a Comparator. In this case only the quantities in the target chest (A) are taken into account as indicated above.
An Evaluator can check for a target chest (A) up to 2 blocks away if a solid block is in between the target and the Evaluator.
Containers that can be checked are:
chests (including double)
trapped chest
shulker box
barrels
hoppers
droppers
dispensers
minecart with chest
minecart with hopper
Hopefully this clears things up and removes any confusion there may have been in regards to functionality. Let me know if this explains things better, if so ill update my original post. If you have any other questions or suggestions let me know.
I've updated the initial post to better explain the functionality. The initial concept won't compare the quantity of items, think of the comparison chests as black/white lists. Having multiple of the same item in them won't change the signal outputted. The good thing about them being inventory's, they could be changed without direct interaction from the player.
It would be nice to have a way of checking for exact amounts of items but i feel it would complicate the blocks function. If you have any suggestions how it could work I'd like to hear it.
Hi everyone,
I thought i would share an idea for a new redstone component called an Evaluator.
Evaluator Block:
Crafting Recipe:
Standard Behavior:
So we have target chest (A (south side)) and comparison (sample) chests (B & C (east & west side)) (you don't have to use two) so it would function like below:
The output can be inverted with a toggle resulting in the below behavior.
Additional Behavior:
If a comparator is placed on the north side (where the signal is emitted) the comparator is able to emit a signal strength based on the number of items/blocks in the target chest (A). The checks will be as below:
As an example, if the target chest (A) was as below and B & C contained an iron pickaxe and cobblestone it would get calculated as so. (same as the comparator but only for the items/blocks that match B & C)
If the Evalutator is in inverted mode it would perform the same calculation as above and deduct it from 15. Using the same setup as above it would result in signal strength of 13.
Additional Notes:
When checking items/blocks it does so using there name ID.
NBT data isn't considered when doing checks. (Possible Addition: When using the Evaluator on its own it could output a full signal if it has not just a name ID match but a full match to NBT data as well, if not then a signal strength of 7?)
The quantity of items won't affect the signal strength except if used with a Comparator. In this case only the quantities in the target chest (A) are taken into account as indicated above.
An Evaluator can check for a target chest (A) up to 2 blocks away if a solid block is in between the target and the Evaluator.
Containers that can be checked are:
So that's it, let me know what you think. Would you find this item useful? is there anything you would change?
This has potential but needs more detail:
The comparison / target terms need to be clarified: suggest that the Sample [the container to be checked] be tested against the Reference [the container against which this check is made].
At least initially, the simplfying restriction that the two containers must be of the same type seems wise. [Extending this to 'of the same size' should then be fairly straightforward, but comparing the contents of a hopper (5 slots) to a chest (54 slots) or similar checks introduces complexities.]
I see the evauator (as depicted) as having a toggle that inverts the output, a single port for a reference (opposite the toggle), and two sample ports.
What occurs if both sample ports are occupied? Suggest that this produce a #NULL or #ERR output.
From what point can a compartor be used to take an output? Any unoccupied seems reasonable, but ought be explicitly stated.
By what algorithm is the comparator out put calculated? Given that I am considering only same type containers at present, the ratio of the number of shared items to the maximum container capacity seems the most straightforward…
BUT, this leaves open the question of how to calculate the signal strength if less than full stacks were used in either (or both) sample and target.
[Taking hoppers as an example, and considering only the first slot being used in both the sample and target:
how would the output be calculated with 1 wheat in the sample and 64 in the reference?
........................................................with 64 wheat in the sample and 1 in the reference?
.........in the general case.................with n wheat in the sample and m in the reference?]
Considering use without a comparator:
from where would the signal be output? Suggest the toggle side
what would the signal strength be?
would this be a binary check (ie ON signal15 if any item in the sample matched any item in the reference, OFF signa0 otherwise)?
if not, how would signal strength be determined?
Is it intended to include comparison of NBT data in the evaluation? [This would be incredibly useful in sorting things like enchanted armor/weapons/ books, but (by the same token) could be seen as 'over-powered'. Including NBT data would also raise issues about data order eg. a computer will not consider Protection4/FeatherFall4 as identical to FeatherFall4/Protection4 without something more than a simple same_as test.]
§
An alternative that might be easier to implement would be to test only a single item in the sample container, outputting a high (15) signal if it matched any item in the reference container, a low (7) signal if it did not, and a null (0) signal when the sample container was empty or held >1 item.
Hi ScotsMiser,
These are some good questions so i'll try my best to answer them and hopefully clarify some of the functionality.
Standard Behavior:
So we have target chest (A (south side)) and comparison (sample) chests (B & C (east & west side)) (you don't have to use two) so it would function like below:
The output can be inverted with a toggle resulting in the below behavior.
Additional Behavior:
If a comparator is placed on the north side (where the signal is emitted) the comparator is able to emit a signal strength based on the number of items/blocks in the target chest (A). The checks will be as below:
As an example, if the target chest (A) was as below and B & C contained an iron pickaxe and cobblestone it would get calculated as so. (same as the comparator but only for the items/blocks that match B & C)
If the Evalutator is in inverted mode it would perform the same calculation as above and deduct it from 15. Using the same setup as above it would result in signal strength of 13.
Additional Notes:
When checking items/blocks it does so using there name ID.
NBT data isn't considered when doing checks. (Possible Addition: When using the Evaluator on its own it could output a full signal if it has not just a name ID match but a full match to NBT data as well, if not then a signal strength of 7?)
The quantity of items won't affect the signal strength except if used with a Comparator. In this case only the quantities in the target chest (A) are taken into account as indicated above.
An Evaluator can check for a target chest (A) up to 2 blocks away if a solid block is in between the target and the Evaluator.
Containers that can be checked are:
Hopefully this clears things up and removes any confusion there may have been in regards to functionality. Let me know if this explains things better, if so ill update my original post. If you have any other questions or suggestions let me know.
I like the idea.
Few random thoughts:
Please, support the sledgehammer tool!
I ♥ Linux. Thanks Mojang for providing a game that runs natively on that OS!
Hi s_leroux,
I've updated the initial post to better explain the functionality. The initial concept won't compare the quantity of items, think of the comparison chests as black/white lists. Having multiple of the same item in them won't change the signal outputted. The good thing about them being inventory's, they could be changed without direct interaction from the player.
It would be nice to have a way of checking for exact amounts of items but i feel it would complicate the blocks function. If you have any suggestions how it could work I'd like to hear it.