I'd like to share this design with the hope that some of you might find it useful for map making. It's not overly complex and is actually fairly straightforward. The main focus here is probably the compact scalable nature of the design, rather than it's fairly simple function.
Simply put, this is an item shop where players can press the button to purchase an item that will go directly into their inventory. It can be modified to use droppers/dispensers instead. It does not need to be based off of exp (although it can be), thanks to the new scoreboard system.
Example shop using "Credits" (read below for details):
Vanilla redstone view (per module/item):
This is a command-block based item shop which utilizes the scoreboard feature from the latest snapshots. It acts on a "virtual" currency which you can define with the scoreboard using the "dummy" type. In this case I used something I called "Credits", which would be purchased with kills. Also, I wouldn't share such a trivial design if there wasn't something more unique about it: notice that it is fully 1-wide scalable, and is not very large overall (1x4x5). This design can easily be tiled as long as you'd like, where each module can be placed immediately beside another without interference. It can even be crammed into a 3-wide wall for a flush look.
There are two things to note. First: the use of additional search parameters in the cmd block is recommended if you're dealing with multiple players. The only reason I excluded these in the example text was to preserve readability. Second: the 4-tick delay on the upper repeater is to ensure that the comparator receives the result of the cmd block before the piston retracts. This is important because if the piston were to retract ahead of time, it might pass an erroneous signal from the comparator, because the comparator updated slower than the piston retracted.
If you're wondering, the example text in the image illustrates a simple shop that might be used in a PvP map: the player can use 20 of their kills to purchase a Pumpkin Pie. This is worth it because Pumpkin Pie is amazing. =]
Nice work. I like the idea of virtual currency, and using command blocks makes it very easy to have a shop with a lot of options. I just wish command blocks could give items with enchantments, as well as different colored armor. Maybe in the future, more options will be available for making custom shops for even more specific items. Thanks for your post.
Nice work. I like the idea of virtual currency, and using command blocks makes it very easy to have a shop with a lot of options. I just wish command blocks could give items with enchantments, as well as different colored armor. Maybe in the future, more options will be available for making custom shops for even more specific items. Thanks for your post.
Thanks for your reply. =]
It is possible to replace the leftmost cmd block with a dropper, and then fill the dropper with any item(s) you'd like. Rather than a cmd being run, an item would be dropped. These items could be enchanted weapons, armor, or even custom potions. You might even use a tool like MCEdit to set all the stack sizes to -1 for maximum usage. I think this would cause the stack quantity to wrap around from -128 to +127 and down to 1, for total of 255 states (items). But, if you're thinking what I'm thinking, it's that the droppers would eventually run out regardless... I think what map makers really need is a way to generate custom items on the spot.
Hmm, this has me thinking. There might actually be some trickery possible involving entity spawners, where the generated items fall into a hopper that feeds into a dropper, which effectively becomes bottomless. I'm not entirely sure as to the limitations of custom data within spawners, however...
Edit: As expected, it is possible to use spawners in combination with droppers to create "bottomless" droppers. Using MCEdit with a couple of filters (thank you SethBling), I was actually able to create a few for a double enchanted renamed sword, a custom potion, and even a written and signed book. Although the modules might be quite large, this does at least mean everlasting shops with custom items are possible... =]
Ya, I used the item spawner for my Infinity Cannon. The only drawback is the difficulty to get the item to spawn where you want it. I used a water line to control where the items go, but like you said, it can be quite large. I would say it's worth it though if you want to use a scoreboard point system for transfering items.
Well since the comparator takes only 1/2 ticks to update this shouldnt be a problem, so you could remove the repeater, and the block and make your circuit 1 lower by putting the torch over the comparator
Funny you mention that... I tried this originally, but it proved to be very unstable. There was about a 50/50 chance that the signal would go through after the last time the player purchased something (when they were out of points), and they'd end up with either a free item or losing points for nothing. I think this was due to the instability of comparators, which has apparently been fixed in a recent snapshot since I made this design. At some point I'll have to head back and see how this design works now that I'm in 13w06a. Thanks for the input. =)
How do you add currency onto your server, ive got a command block and types command in (might not be right ones) but dont know what to do after that, do you have to power them?
For your server, Scoreboard isn't needed. You can use Essentials and create sign shops. Read the Essentials wiki for more. http://ess.khhq.net/wiki/Sign_Tutorial
Perhaps I dont understand this, but wouldnt this be easier?
its also 1 wide and fully tileable. Size 1x2x5
Example gives 1 Firecharge for 1 "Credit" :
give @p[score_credits_min=1] 385 1
scoreboard players remove @p[score_credits_min=1] credits 1
(Command blocks have to be triggered in this order, first give, than remove credit)
I think it was a stability issue with rapidly pressing the button. The design I posted re-activates each time you press the button (hence the AND gate). Honestly I'm not 100% sure anymore the motive behind it, because it's been a while since I've used this. I recall it being a result of me trying to derive solid numbers from combinations of cmd blocks and the scoreboard.
Edit: Ah, wait, I see what you're doing... separating the cmd blocks completely by not using comparators. This removes the need to deal with the constant output the cmd blocks might give. Interesting.
Can I ask why the cmds need to be triggered in that order?(Oh, because both of them need to check the minimum amount.) I think it would be best to swap them and take points first. Although highly unlikely, a player could disconnect at the perfect time and receive the item for free (without knowing). Very negligible, but if you could possibly swap them I'd probably recommend it just in case.
For your server, Scoreboard isn't needed. You can use Essentials and create sign shops. Read the Essentials wiki for more. http://ess.khhq.net/wiki/Sign_Tutorial
Not sure where you got the idea he was using Bukkit, or anything aside vanilla... Anyways, I sent him a PM a while ago and answered his question.
Also I'm wondering why this thread is months old and has been randomly resurrected twice now... o_o
Thanks so much dude. +1
I tried to make this loooong ago, but I had 2 problems:
1. Couldn't find out how to "restart" it.
2. Wasn't so compact.
LOVE THIS! I even canceled a map project because of this.
Now I can start it again
I'll give you credit in my map.
<--- for you
Gold Miner at home already did this. He actually added a good way to allow you to turn diamonds into currency...
I have this built on my friends vanilla server, in place of an economy plugin. For people who want to know how it works, as the video gives no explanation, if I am correct, there is an item sorter, which funnels into a dropper. This dropper has a comparator coming out from it, which outputs to a repeater, and the current then travels into the repeater, making a fast clock that ticks only while the dropper has items in it. This signal also activates a command block, which gives the nearest player to the chest either 1 currency, on a 1:1 scale, or one dummy objective, called whatever you are selling, like diamonds, or gold, or whatever. (Name doesn't matter) for ratios that I do not want to be 1:1, I then have another part which is a hopper clock hooked up to some command blocks, one that gives all players who have enough of this dummy objective a value of currency. A repeater coming off from that removes the objective. I have these lined up next to each other to be more compact on this admin shop.
So, say that the buy ratio is 2 diamonds for 50$. You put 2 diamonds in the input chest, they go through the item sorter, into the dropper, which activates a clock, which transfers the diamonds into a chest (Or lava, but this is noisy.) The redstone triggers a command block that gives the player 1 objective called "diamond" for each time the redstone pulses (twice) and a different redstone command block array gives all players with 2 diamond objective 50$, then removes 2 diamond objective from all players with 2 diamond objective. Sorry if this is a bit confusing, and sorry for the long reply.
Rollback Post to RevisionRollBack
I have no idea what to do with my signature. This is good enough for now.
I think it was a stability issue with rapidly pressing the button. The design I posted re-activates each time you press the button (hence the AND gate). Honestly I'm not 100% sure anymore the motive behind it, because it's been a while since I've used this. I recall it being a result of me trying to derive solid numbers from combinations of cmd blocks and the scoreboard.
Edit: Ah, wait, I see what you're doing... separating the cmd blocks completely by not using comparators. This removes the need to deal with the constant output the cmd blocks might give. Interesting.
Can I ask why the cmds need to be triggered in that order?(Oh, because both of them need to check the minimum amount.) I think it would be best to swap them and take points first. Although highly unlikely, a player could disconnect at the perfect time and receive the item for free (without knowing). Very negligible, but if you could possibly swap them I'd probably recommend it just in case.
Might as well reply to this while I'm at it:
Not sure where you got the idea he was using Bukkit, or anything aside vanilla... Anyways, I sent him a PM a while ago and answered his question.
Also I'm wondering why this thread is months old and has been randomly resurrected twice now... o_o
Don't do it.
That's what I tried to do, and it didn't restart (redstone didn't turn off) unless a player with not enough money came and pressed the button.
You seem to know a bit about command blocks, do you think you could answer a question I posted? It''s here. Anyhow this post helped me a lot! +1 and to you!
Rollback Post to RevisionRollBack
Did one of my posts help you? Click the green arrow in the bottom right corner, it only takes a second!
This seemed to work fine for me
Left: /scoreboard players remove @p[score_currency_min=1] currency 1
Right: /give @p[score_currency_min=1] 4 10
It also worked with:
Left: /scoreboard players remove @p[score_currency_min=6] currency 6
Right: /give @p[score_currency_min=6] 1 10
It activates both at once so it doesn't have any problem with the button being pressed too fast activating one block more than the other. I tested it and I didn't find anything wrong with it no matter how fast the button was pressed. When I had enough points it acted as normal and when I didn't have enough points it did nothing just like it should. Don't know why you need to complicate it with Redstone Repeaters, Redstone Comparators and Redstone Torchs. This is probably as compact as it can get.
(I will put aside the fact that this topic is months old and has been brought back from the dead half-a-dozen times now...)
As far as I can remember the point behind the complication was a matter security: to ensure the player never got anything for free. This was priority. A player could, in theory, log off or lag out during any point in the redstone/execution process. With two simple command blocks and a couple of redstone like that the events are disjoint. If you're designing a single player map or something, you probably don't care about this. On the other hand, a server owner might want to make sure there is very little or no risk in giving players infinite amounts free items due to some exploit.
It's just like a piece of software: you can write something quick and dirty that can be hacked with relative ease, or you can do it the more secure, albeit complex way. There's probably something I forgot considering I designed this a very long time ago and there have been many updates since.
I'd like to share this design with the hope that some of you might find it useful for map making. It's not overly complex and is actually fairly straightforward. The main focus here is probably the compact scalable nature of the design, rather than it's fairly simple function.
Simply put, this is an item shop where players can press the button to purchase an item that will go directly into their inventory. It can be modified to use droppers/dispensers instead. It does not need to be based off of exp (although it can be), thanks to the new scoreboard system.
Example shop using "Credits" (read below for details):
Vanilla redstone view (per module/item):
This is a command-block based item shop which utilizes the scoreboard feature from the latest snapshots. It acts on a "virtual" currency which you can define with the scoreboard using the "dummy" type. In this case I used something I called "Credits", which would be purchased with kills. Also, I wouldn't share such a trivial design if there wasn't something more unique about it: notice that it is fully 1-wide scalable, and is not very large overall (1x4x5). This design can easily be tiled as long as you'd like, where each module can be placed immediately beside another without interference. It can even be crammed into a 3-wide wall for a flush look.
There are two things to note. First: the use of additional search parameters in the cmd block is recommended if you're dealing with multiple players. The only reason I excluded these in the example text was to preserve readability. Second: the 4-tick delay on the upper repeater is to ensure that the comparator receives the result of the cmd block before the piston retracts. This is important because if the piston were to retract ahead of time, it might pass an erroneous signal from the comparator, because the comparator updated slower than the piston retracted.
If you're wondering, the example text in the image illustrates a simple shop that might be used in a PvP map: the player can use 20 of their kills to purchase a Pumpkin Pie. This is worth it because Pumpkin Pie is amazing. =]
Thanks for your reply. =]
It is possible to replace the leftmost cmd block with a dropper, and then fill the dropper with any item(s) you'd like. Rather than a cmd being run, an item would be dropped. These items could be enchanted weapons, armor, or even custom potions. You might even use a tool like MCEdit to set all the stack sizes to -1 for maximum usage. I think this would cause the stack quantity to wrap around from -128 to +127 and down to 1, for total of 255 states (items). But, if you're thinking what I'm thinking, it's that the droppers would eventually run out regardless... I think what map makers really need is a way to generate custom items on the spot.
Hmm, this has me thinking. There might actually be some trickery possible involving entity spawners, where the generated items fall into a hopper that feeds into a dropper, which effectively becomes bottomless. I'm not entirely sure as to the limitations of custom data within spawners, however...
Edit: As expected, it is possible to use spawners in combination with droppers to create "bottomless" droppers. Using MCEdit with a couple of filters (thank you SethBling), I was actually able to create a few for a double enchanted renamed sword, a custom potion, and even a written and signed book. Although the modules might be quite large, this does at least mean everlasting shops with custom items are possible... =]
Funny you mention that... I tried this originally, but it proved to be very unstable. There was about a 50/50 chance that the signal would go through after the last time the player purchased something (when they were out of points), and they'd end up with either a free item or losing points for nothing. I think this was due to the instability of comparators, which has apparently been fixed in a recent snapshot since I made this design. At some point I'll have to head back and see how this design works now that I'm in 13w06a. Thanks for the input. =)
For your server, Scoreboard isn't needed. You can use Essentials and create sign shops. Read the Essentials wiki for more.
http://ess.khhq.net/wiki/Sign_Tutorial
Perhaps I dont understand this, but wouldnt this be easier?
its also 1 wide and fully tileable. Size 1x2x5
Example gives 1 Firecharge for 1 "Credit" :
give @p[score_credits_min=1] 385 1
scoreboard players remove @p[score_credits_min=1] credits 1
(Command blocks have to be triggered in this order, first give, than remove credit)
I think it was a stability issue with rapidly pressing the button. The design I posted re-activates each time you press the button (hence the AND gate). Honestly I'm not 100% sure anymore the motive behind it, because it's been a while since I've used this. I recall it being a result of me trying to derive solid numbers from combinations of cmd blocks and the scoreboard.
Edit: Ah, wait, I see what you're doing... separating the cmd blocks completely by not using comparators. This removes the need to deal with the constant output the cmd blocks might give. Interesting.
Can I ask why the cmds need to be triggered in that order?(Oh, because both of them need to check the minimum amount.) I think it would be best to swap them and take points first. Although highly unlikely, a player could disconnect at the perfect time and receive the item for free (without knowing). Very negligible, but if you could possibly swap them I'd probably recommend it just in case.Might as well reply to this while I'm at it:
Not sure where you got the idea he was using Bukkit, or anything aside vanilla... Anyways, I sent him a PM a while ago and answered his question.
Also I'm wondering why this thread is months old and has been randomly resurrected twice now... o_o
I tried to make this loooong ago, but I had 2 problems:
1. Couldn't find out how to "restart" it.
2. Wasn't so compact.
LOVE THIS! I even canceled a map project because of this.
Now I can start it again
I'll give you credit in my map.
<--- for you
I have this built on my friends vanilla server, in place of an economy plugin. For people who want to know how it works, as the video gives no explanation, if I am correct, there is an item sorter, which funnels into a dropper. This dropper has a comparator coming out from it, which outputs to a repeater, and the current then travels into the repeater, making a fast clock that ticks only while the dropper has items in it. This signal also activates a command block, which gives the nearest player to the chest either 1 currency, on a 1:1 scale, or one dummy objective, called whatever you are selling, like diamonds, or gold, or whatever. (Name doesn't matter) for ratios that I do not want to be 1:1, I then have another part which is a hopper clock hooked up to some command blocks, one that gives all players who have enough of this dummy objective a value of currency. A repeater coming off from that removes the objective. I have these lined up next to each other to be more compact on this admin shop.
So, say that the buy ratio is 2 diamonds for 50$. You put 2 diamonds in the input chest, they go through the item sorter, into the dropper, which activates a clock, which transfers the diamonds into a chest (Or lava, but this is noisy.) The redstone triggers a command block that gives the player 1 objective called "diamond" for each time the redstone pulses (twice) and a different redstone command block array gives all players with 2 diamond objective 50$, then removes 2 diamond objective from all players with 2 diamond objective. Sorry if this is a bit confusing, and sorry for the long reply.
Don't do it.
That's what I tried to do, and it didn't restart (redstone didn't turn off) unless a player with not enough money came and pressed the button.
This seemed to work fine for me
Left: /scoreboard players remove @p[score_currency_min=1] currency 1
Right: /give @p[score_currency_min=1] 4 10
It also worked with:
Left: /scoreboard players remove @p[score_currency_min=6] currency 6
Right: /give @p[score_currency_min=6] 1 10
It activates both at once so it doesn't have any problem with the button being pressed too fast activating one block more than the other. I tested it and I didn't find anything wrong with it no matter how fast the button was pressed. When I had enough points it acted as normal and when I didn't have enough points it did nothing just like it should. Don't know why you need to complicate it with Redstone Repeaters, Redstone Comparators and Redstone Torchs. This is probably as compact as it can get.
As far as I can remember the point behind the complication was a matter security: to ensure the player never got anything for free. This was priority. A player could, in theory, log off or lag out during any point in the redstone/execution process. With two simple command blocks and a couple of redstone like that the events are disjoint. If you're designing a single player map or something, you probably don't care about this. On the other hand, a server owner might want to make sure there is very little or no risk in giving players infinite amounts free items due to some exploit.
It's just like a piece of software: you can write something quick and dirty that can be hacked with relative ease, or you can do it the more secure, albeit complex way. There's probably something I forgot considering I designed this a very long time ago and there have been many updates since.