This suggestion is primarily concerned with Map Making - especially with custom item crafting
Background:
Did you ever wanted to have custom recipes? Well I do. Custom Crafting can be used to create extended gameplay mechanics. In order to give the player more than just one custom crafted item at a time it is essential to know how many items the player put in a specific inventory slot.
Currently there is only one option to do so that I know of. But that requires the map maker to individually test every possible amount of items for every item slot. At a 3x3 grid this would require 1152 Command Blocks. [9 slots * 64 items * 2 Command Blocks (one CB. to test for the amount and another to set a score)]
This is how a custom crafting system would look like (pre 1.8.6 - today with chain command blocks this could be build more compact but still be as exhausting like before)
The Command-Block-Arrays in the bottom part serve the sole purpose of testing the amount of items in a specific slot of the dropper and then setting the appropriate score.
Other simpler methods would require the player to put exactly the amount of items in the slots, as there are in the sample container that is used to identify the recipe (using /testforblocks) or completely ignore the amount of items. (using /testforblock with NBT-tags)
In my case for example I wanted to make a new SkyBlock survival map where you can craft every item/block you couldn't otherwise get so you can get more creative with building things.
OK, but what is Custom Crafting and how does it work?
In short 'Custom Crafting' is when you add your own custom recipes for crafting to the game.
But since you don't actually put your items on the crafting table when you craft stuff we cant use a crafting table for that.
(Technically all crafting you do happens on your character. The GUI that pops up when you right click a crafting table is basically just an extended inventory screen. -> 2 or more players can use the same crafting table without seeing the items of the other player(s) but when you look in a container (e.g. a chest) the items are actually stored inside it and other players can see them.)
So instead of a crafting table we can use a dropper as it also has a 3x3 grid to lay items out in. When the items are in the dropper we need to check what recipe it is. As I mentioned earlier there are 2 options for that.
'/testforblock' and '/testforblocks'
The former looks for a single block and if it matches the given criteria. The latter compares blocks.
/testforblocks
Here we set up a sample dropper with the correct recipe inside and test if the players dropper and the sample are identical.
This might be particularly easy to set up but there is a big downside. The data tags of the two droppers need to match exactly. That means as a player you need to put exactly the amount of items in the right spots like there are in the sample.
If you just want to craft a single special item this is not much of a problem though if you want to craft for example a block of dirt (i.e. multiple blocks of dirt) you need to repeat the crafting process for every single block over and over again.
/testforblock
This method is more complicated as we need to write the NBT-tags ourselves. But it allows for much more flexible implementations. By not specifying an inventory slot or the count number we can make shapeless recipes with any amount of items on the grid.
The downside here is that this method ignores how big a stack of items is and if there are items in slots not specified by the NBT-tag to be empty.
When the command succeeds the player gets the result of the recipe.
By counting how many items there are in the slots of the dropper we can give the player the result of the recipe as often as the number of the smallest stack was. (but only by using '/testforblock')
Therefor we use math operations on the scoreboard.
The Idea:
Command Stats are used to store the outcome of specific commands to a player in a scoreboard objective. With a small addition to how this is currently working the counting of items in specific inventory/container slots could be achieved quite easily. (in comparison to what was done in the picture above)
That means if you execute a command that deletes the Items in a specific inventory slot the command stats store the amount of items that have been deleted.
wouldn't store the number passed by '[amount]' (like now) but the amount of items that have been deleted by this command.
Alternatively "the command /clear could be extended to work like /replaceitem with all entities and blocks too. Accordingly the new syntax would look like this:
The old arguments would behave as usual and in Block mode , and specify the coordinates of the block. The [slot] argument could be ignored by adding a new slot constant e.g. "slot.all" which means all slots would be addressed in the command execution.
(If possible I think it would be better if the arguments "entity" and "block" would not be needed to defer the operation modes)
I personally prefer the second option. It might add a little redundancy to the commands but it is more clear to see what they do. This way "/clear" would always return the amount of deleted items and "/replaceitems" can still return the amount of given items. (for whatever reason that might be good for )
Example:
We want to count the items in a Dropper which conveniently mimics a 3x3 crafting grid.
At first we have to set up the Scoreboard. Therefor we need an Objective and Players to assign the score to.
Lets name the Objective "ItemCount" and the Players according to the slot they represent.
/scoreboard objectives add ItemCount dummy
/scoreboard players set slot_0 ItemCount 0
/scoreboard players set slot_1 ItemCount 0
...
/scoreboard players set slot_8 ItemCount 0
Now we need a command block for each slot to clear individually. Enter the following command to each of the 9 command blocks where , and are the coordinates of the Dropper, and adjust the slot number.
/clear block slot.container.slot_number
When that is done we can set up the Command Stats.
Jump on top of each command block and type the following command (in chat) and again adjust the slot number i.e. player name.
/stats block ~ ~-1 ~ set AffectedItems slot_0 ItemCount
Now every time the command blocks clear the slots in the Dropper the scoreboard will store the amount of items there was in each slot.
(of curse I'm passionate about this - For an eternity I was thinking to myself: "Dang, There just got to be an easy way to do this!" But guess what, there isn't .. bummer) ... so .. sorry for bumping I guess
If this Idea isn't very good, please tell me.
anything wrong with the presentation? (new here so I guess its a valid question...)
The concept is solid but the implementation of it is my main issue. A much easier method would be an admin only command for adding custom recipes. Something like /addrecipe <shapeless boolean> <item 1>; <item 2>; <item 3>; <item 4>; <item 5>; <item 6>; <item 7>; <item 8>; <item 9>; <output item>; [custom ID]
This would add the recipe to a recipe folder within the save and would automatically give an error if the recipe exists and let you craft it if you follow the recipe. You could then have a command for listing all recipes (all would get an ID on creation) and a command for removing a recipe.
This way might use a little more hard drive space to store recipes, but would require 0 command blocks to modify, but could be used by command blocks to say, temporarily allow someone to make something by adding a recipe with a custom ID and then removing it later.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
The concept is solid but the implementation of it is my main issue. A much
easier method would be an admin only command for adding custom recipes.
Something like /addrecipe <shapeless boolean> <item 1>;
<item 2>; <item 3>; <item 4>; <item 5>; <item
6>; <item 7>; <item 8>; <item 9>; <output
item>; [custom ID]
This would add the recipe to a recipe
folder within the save and would automatically give an error if the
recipe exists and let you craft it if you follow the recipe. You could
then have a command for listing all recipes (all would get an ID on
creation) and a command for removing a recipe.
[...]
Yes, this would indeed be a lot easier to use than my attempt. Too easy for my taste.
Working with command blocks like I described is much more rewarding than just typing a simple command.
All this redstone stuff (including command blocks) is about tinkering to achieve cool stuff.
This is stuff people can figure out for themselves and share with the community and others can improve the implementation, which in my experience makes up a big part of Minecraft.
And whats probably a lot more crucial than that is that this command would probably take several months to get implemented. The whole crafting system would need to be redone in order to allow for on-the-fly recipe addition. Hence a lot of testing would need to be done and it has to work with servers as well.
On the other side my attempt I think would take about an hour to be implemented.
The command /clear just needs a new signature or overload method with code mostly taken from /replaceitem and then it's only a matter of refactoring.
(how I can tell? ... well I'm studying informatics and program java myself - yes, I'm aware that this
doesn't mean I can't be wrong. But it definitely helps guessing correctly how things work )
This suggestion is primarily concerned with Map Making - especially with custom item crafting
Background:
Did you ever wanted to have custom recipes? Well I do.
Custom Crafting can be used to create extended gameplay mechanics.
In order to give the player more than just one custom crafted item at a time it is essential to know how many items the player put in a specific inventory slot.
Currently there is only one option to do so that I know of. But that requires the map maker to individually test every possible amount of items for every item slot. At a 3x3 grid this would require 1152 Command Blocks. [9 slots * 64 items * 2 Command Blocks (one CB. to test for the amount and another to set a score)]
This is how a custom crafting system would look like (pre 1.8.6 - today with chain command blocks this could be build more compact but still be as exhausting like before)
The Command-Block-Arrays in the bottom part serve the sole purpose of testing the amount of items in a specific slot of the dropper and then setting the appropriate score.
Other simpler methods would require the player to put exactly the amount of items in the slots, as there are in the sample container that is used to identify the recipe (using /testforblocks) or completely ignore the amount of items. (using /testforblock with NBT-tags)
In my case for example I wanted to make a new SkyBlock survival map where you can craft every item/block you couldn't otherwise get so you can get more creative with building things.
OK, but what is Custom Crafting and how does it work?
In short 'Custom Crafting' is when you add your own custom recipes for crafting to the game.
But since you don't actually put your items on the crafting table when you craft stuff we cant use a crafting table for that.
(Technically all crafting you do happens on your character. The GUI that pops up when you right click a crafting table is basically just an extended inventory screen. -> 2 or more players can use the same crafting table without seeing the items of the other player(s) but when you look in a container (e.g. a chest) the items are actually stored inside it and other players can see them.)
So instead of a crafting table we can use a dropper as it also has a 3x3 grid to lay items out in. When the items are in the dropper we need to check what recipe it is. As I mentioned earlier there are 2 options for that.
'/testforblock' and '/testforblocks'
The former looks for a single block and if it matches the given criteria. The latter compares blocks.
/testforblocks
Here we set up a sample dropper with the correct recipe inside and test if the players dropper and the sample are identical.
This might be particularly easy to set up but there is a big downside. The data tags of the two droppers need to match exactly. That means as a player you need to put exactly the amount of items in the right spots like there are in the sample.
If you just want to craft a single special item this is not much of a problem though if you want to craft for example a block of dirt (i.e. multiple blocks of dirt) you need to repeat the crafting process for every single block over and over again.
/testforblock
This method is more complicated as we need to write the NBT-tags ourselves. But it allows for much more flexible implementations. By not specifying an inventory slot or the count number we can make shapeless recipes with any amount of items on the grid.
The downside here is that this method ignores how big a stack of items is and if there are items in slots not specified by the NBT-tag to be empty.
When the command succeeds the player gets the result of the recipe.
By counting how many items there are in the slots of the dropper we can give the player the result of the recipe as often as the number of the smallest stack was. (but only by using '/testforblock')
Therefor we use math operations on the scoreboard.
The Idea:
Command Stats are used to store the outcome of specific commands to a player in a scoreboard objective. With a small addition to how this is currently working the counting of items in specific inventory/container slots could be achieved quite easily. (in comparison to what was done in the picture above)
That means if you execute a command that deletes the Items in a specific inventory slot the command stats store the amount of items that have been deleted.
Technically speaking:
The use of
wouldn't store the number passed by '[amount]' (like now) but the amount of items that have been deleted by this command.
Alternatively "the command /clear could be extended to work like /replaceitem with all entities and blocks too. Accordingly the new syntax would look like this:
The old arguments would behave as usual and in Block mode , and specify the coordinates of the block. The [slot] argument could be ignored by adding a new slot constant e.g. "slot.all" which means all slots would be addressed in the command execution.
(If possible I think it would be better if the arguments "entity" and "block" would not be needed to defer the operation modes)
I personally prefer the second option. It might add a little redundancy to the commands but it is more clear to see what they do. This way "/clear" would always return the amount of deleted items and "/replaceitems" can still return the amount of given items. (for whatever reason that might be good for )
Example:
We want to count the items in a Dropper which conveniently mimics a 3x3 crafting grid.
At first we have to set up the Scoreboard. Therefor we need an Objective and Players to assign the score to.
Lets name the Objective "ItemCount" and the Players according to the slot they represent.
Now we need a command block for each slot to clear individually. Enter the following command to each of the 9 command blocks where , and are the coordinates of the Dropper, and adjust the slot number.
When that is done we can set up the Command Stats.
Jump on top of each command block and type the following command (in chat) and again adjust the slot number i.e. player name.
Now every time the command blocks clear the slots in the Dropper the scoreboard will store the amount of items there was in each slot.
To make the scoreboard visible simply type
What else do you think could be done knowing how many items a player put in a container/inventory slot?
* added picture
... no replies in 4 days?
(of curse I'm passionate about this - For an eternity I was thinking to myself: "Dang, There just got to be an easy way to do this!" But guess what, there isn't .. bummer) ... so .. sorry for bumping I guess
If this Idea isn't very good, please tell me.
anything wrong with the presentation? (new here so I guess its a valid question...)
(edited to comply with forum rules)
The lack of replies is surely not because it's bad, in fact it looks very polished, it's just most of us don't get half of what's going up there :/
no sig yay
The concept is solid but the implementation of it is my main issue. A much easier method would be an admin only command for adding custom recipes. Something like /addrecipe <shapeless boolean> <item 1>; <item 2>; <item 3>; <item 4>; <item 5>; <item 6>; <item 7>; <item 8>; <item 9>; <output item>; [custom ID]
This would add the recipe to a recipe folder within the save and would automatically give an error if the recipe exists and let you craft it if you follow the recipe. You could then have a command for listing all recipes (all would get an ID on creation) and a command for removing a recipe.
This way might use a little more hard drive space to store recipes, but would require 0 command blocks to modify, but could be used by command blocks to say, temporarily allow someone to make something by adding a recipe with a custom ID and then removing it later.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
OK, thx! This is something I can work with
-Added further explanation to OP
Yes, this would indeed be a lot easier to use than my attempt. Too easy for my taste.
Working with command blocks like I described is much more rewarding than just typing a simple command.
All this redstone stuff (including command blocks) is about tinkering to achieve cool stuff.
This is stuff people can figure out for themselves and share with the community and others can improve the implementation, which in my experience makes up a big part of Minecraft.
And whats probably a lot more crucial than that is that this command would probably take several months to get implemented. The whole crafting system would need to be redone in order to allow for on-the-fly recipe addition. Hence a lot of testing would need to be done and it has to work with servers as well.
On the other side my attempt I think would take about an hour to be implemented.
The command /clear just needs a new signature or overload method with code mostly taken from /replaceitem and then it's only a matter of refactoring.
(how I can tell? ... well I'm studying informatics and program java myself - yes, I'm aware that this
doesn't mean I can't be wrong. But it definitely helps guessing correctly how things work )