If by "night", you mean "day", yes. That happens. To prevent it, you can either have opaque blocks above blocks on which zombies will be, or you can just give them a hat. Could be a diamond helmet, leather helmet, wool block, whatever. To make the zombies have non-helmet items as hats, you have to use some third-party software to modify the entities to have special items as hats.
Also, for something trivially objective and obviously catalogued, like block IDs, try the Minecraft Wiki. 53 is Stairs, you may have mistyped something. If you pinpoint a specific problem after many tries, give details on it. Otherwise, you may have made a mistake.
Oh yes, and you'll need to set tile data on spawners to get them to spawn what you want. I believe you definitely need third-party software for that.
On my Creative world where I do huge builds and hate seeing mobs as the cherry on top? Where I've got 10 FPS? Yes. But this isn't in the Creative section. This is...
On Survival. Hell no. Hard or nothing. Your stuff gets blown up? Part of the experience. Take it and move on.
However, since this is Minecraft and not reality, you can have whatever you like.
I was too lazy to read this whole magic but I read the ending: How to make it count the failiures and dedect it?
Pressureplates and pistons? Make a pressureplate counting the fail of hitting the zombie and the pressureplate also triggers the piston to push the zombie off. I advise you use MCedit to make custom spawners for the zombies. You can make them have block heads or some armor to prevent them from despawning. I hope I'm talking about the right thing and not messing up real bad.
If you had read the bolded parts, you would see that this is for Survival Vanilla. Merely looking at the images and the titles attached to them would give you enough of an idea. Therefore, using MCedit is not an option. Armor would prevent them from despawning (pumpkins would suffice). Having a custom spawner would negate the purpose of most of what I'm describing. However, your pressure plate idea, although it would limit the space of the recycling chute, could work. The main problem with this idea can be posed by the following questions: How would I detect if a mob fell on two pressure plates? How would I differentiate that from two mobs falling at once onto different pressure plates?
Thanks for the suggestion though, I hadn't actually considered pistons for pushing them off, since I was thinking of tripwire in any case.
I'm wondering if it is possible to pulse sunlight in, by opening and closing openings in the ceiling, to trigger the zombies hide from sunlight mechanic without actually lighting them on fire. That way they could be herded progressively toward the player without anything actually on the playing field. If it is possible, you could have pressure plates on the floor that would trigger the pulse system to open and close only the sunlight openings behind the lead zombies.
Interesting idea. Although I'm also a bit confused as to how I'd do this. This would imply that I could not use water to push them forwards out of the sorter, as they would be attracted back to that water by the sunlight.
I was initially considering "shooting the zombies will make them all mob you". But there's the problem of them all bundling together in an easy-to-hit crowd, rather than proceeding uniformly across the field with relatively even distribution. The same problem probably applies with villagers. Having dividers between lines is not an option, as it limits diagonal shooting and makes the mobs move in a pattern that is too predictable. Also, it heavily impacts space constraints on the playing field.
I would like to add that I am planning on having a stage that I can change the look of. I might also want to try out Soul Sand and see how that affects stuff. Could try block-swappers, but I figure that the effect won't be so significant as to merit that much.
I definitely agree with the player lowering the difficulty that they're playing on. If you can't take the heat, turn it down. The kitchen is great though, so don't get out of it.
These mob features make them a lot more interesting and unique, especially that zombie one (wonder how a grinder with a couple hundred zombies and a player would fare in a toss-up...Splash potions of healing needed, maybe). Of course, that feature is still being refined.
I have never used, nor agreed, with the concept of switching difficulty from Hard at any point. Have to say though, those skeletons can actually hurt you now, if you don't have a weapon.
As everyone has already said, experimenting is the best way to learn.
The very best way to make that happen is to have a logical objective in mind when building the circuitry, so you actually have a reason to make the thing work, and a place to apply it. You can always come back to that objective and focus your build.
Tutorials can also be helpful, as they often expose some of the features of redstone. Namely, game mechanics that are somewhat obscure that can be used in circuitry.
When the mobs fall through the trap door, make some rivers that flow into mob elevators, where pistons control the flow of zombies (hopper clocks or detec. rails and minecart with cobwebs for long timing?) That should work.
What do you mean by the bit after the second comma? Do you mean like for releasing recycled mobs in a longer, more continuous game? I was seriously only really thinking playing a few waves, but I guess I didn't consider the length of the games, and options for that... The experience would feel a bit diminished if you used less mobs at any point though.
Do you mean you want negative pulses, where you have deactivated torches punctuated with occasional bursts of being on?
Doesn't sound possible. (To my limited knowledge)
The best you can get is just a circuit you can trigger with a button or whatever that would burn the torches out after several rapid pulses , but this has the disadvantage of reversion to the on-state.
I guess you could make the torch on-signal trigger the circuit that would burn the torches out.
You could also tell us what function you're attempting to create, in which case there might be a better alternative to what you're currently doing.
Actually, if you make the system high enough, the Zombies won't be affected by the Testificate.
Also, if your afraid they'll despawn, you could use MCEdit or the new feature of MC: Name Tags, I presume?
Not the sort of thing available in Survival, and Name Tags supposedly don't work on Villagers, although MCEdit will. I figure that a system without a testificate will work just as well.
I assume that the upper portion is what you're taking to be the playing field, where the mobs will move down and be recycled upwards. This system seems reasonable, but I have a few questions about it, namely:
1). Won't mobs still be attracted to the testificate down below, and thus try to move against the current of the upper system?
2). I'm not planning on having the field be a conveyer belt of water. I only want the out-of-sight lower part (recycling area) to be that way. It is possible that I might retain this design, but replace much of the upper part with dry land, and have the remaining water bits concealed.
3). Is there a better motive force than water for making the mobs move across dry land (e.g: I want them to move from their starting point towards me without being prompted by arrows)? Won't the mob AI make them all track me the instant I start shooting them, slowing the recycling system?
I have been making a shooting range recently, but require some assistance.
Updates: Recycling is no longer a problem. After thinking for a few seconds, I just used a repeater and powered the block from the side to invert the torch. Now I just need an instant repeater, or something. If anyone could spare some of their time to look over how to compact this, I'd be really grateful. Saves me redstone, building time, space, etc.
When I say shooting range, I mean that player(s) will stand on an elevated platform and shoot at zombies approaching from the opposite end of the playing field. If the zombies reach the player-side, they'll drop through some opened trapdoors (which they mistake as a full block) into a net of tripwires, incrementing a counter. I would also like to recycle any mobs that get through, but that's optional and probably difficult.
An even more optional and difficult thing would be to make the mob processing ENTIRELY automated. That would entail settings for timing how many mobs you want (based on dropper-clocks, maybe?), then timed pulses to each of the functions I've built below.
If you REALLY want to get in-depth and can commit to some serious assistance across the board, I can provide you with the map. Otherwise, I'm just going to provide screenshots.
I have no background in logic, Redstone, and aesthetic design. I make no claims as to what my abilities are. Actually, no, I do. They are of someone who has no idea what he's doing and is learning as he goes along.
This is designed with Survival Vanilla in mind. Creative mode and Mods render the design obsolete. It is also being designed to actually be used in my Survival world, which uses neither of those things.
This contraption will have four main parts:
1). Spawning area
2). Mob Armory
3). Mob Storage
4). Game
Overview:
I've got the first three of those four parts laid out, but the game field itself hasn't been made because I have to consider balance and positioning. I'd also prefer to finish the mechanics before even attempting to make the GUI, and the first three things that I've named are the mechanics behind the GUI, which is the game as players will see it. Note that restocking has NOT been implemented yet. I will be using chained hoppers for restocking and extended storage (potions, armor), as they automatically move items without a redstone signal (unlike droppers).
The top bit is the spawner. It's 9x9, so there's a hole at the center that the mobs can funnel into. Pretty simple. The platform just beneath it houses four manual controls, which I will discuss shortly. The boxy thing beneath that platform has three manual controls, and is for armoring mobs up. I could do that manually and more simply, but I'd rather not. The bit beneath that is for storing 'waves' of mobs, for the game itself.
Spawner Area and General Functions:
I do hope that these images are automatically re-sized, like I've seen them in other forums. Anyways, this is a horrible back-view of the 'four functions' panel I mentioned earlier. Here are the four functions:
1). Lights to enable/disable spawning. Simple, and you can't really compact it more than I have.
2). Lava to make the zombies kill-able with a punch or two. This is mostly for EXP farm purposes and for leaving only armored mobs behind. I've done this via comparators, two pulses.
3). Potions. One Splash Potion of Healing, two Splash Potions of Harming II. This kills off unarmored mobs handily (after lava) and leaves armored ones standing. The harming pots restore the health of the armored mobs.
4). Drop chute. Just retracts the platform that mobs are standing on, dropping them from this processing center into the next phase.
I've already built all of these components and it's fairly compact. I'm showing this for completeness sake, so anyone who wants to help can get a better idea of what's going on.
Ideally, the game will have two settings: One, any mobs go. So you don't need lava unless if you want to EXP farm zombies, and you don't need potions at all. Two, armored mobs only. This is just a time-saving measure for skipping the armoring phase, but stocking up takes a while, so I figure that recycling is necessary if this setting is enabled.
I haven't built either of these settings into an automatic process. I have created NO automation in this whatsoever, everything is currently manual. Again, automating this would be a very big boon to me.
Mob Armory:
The most horribly annoying part of all of this, in my mind. This is the mob armoring system. In the background is the cutaway of the first processing center. As you can see, it's got four options (one is obscured by the vertical redstone used for the lights).
What happens is that once the mobs drop through the first processing center, they land on a single block in a three-way intersection. Most of them will immediately violently move into the three tubes, because compressed mobs tend to spray everywhere.
Some of them will remain standing on this 'intersection' like bit. The middle block of this T shaped intersection can retract to move mobs into another intersection, this one with two tubes.
These tubes correspond to armor types. The first three tubes are leather, chain, and gold, because I've got those in spades from spawners. The other two tubes are iron and diamond, which are far rarer and of greater durability and strength. Naturally, less mobs get into the last two tubes.
Here are the main functions of this system:
1). Release mechanism. This just retracts the block that caps all five tubes simultaneously, moving all mobs in the armoring tubes into the next area. This is most of the backside (shown in the second image)
2). Armoring mechanism. Five dispensers comprise the tubes that mobs get dropped into. I hook up all five tubes to an 8-tick clock (again, comparators, and the y-axis is one block) and let it run for a bit to armor some mobs. This is MOST of what you're seeing in those images.
3). Separation mechanism. Simply activates the piston at the T-intersection to retract a block, allowing access to the iron and diamond tubes. You can see it looping behind in the back of the second image.
Here are the problems with this system:
1). I've had to reduce fall damage as much as possible. The way I've designed this, the mobs don't ever get grouped together again for me to splash damage them again and heal them of any fall damage they've taken. As such, I've got to consider water placement and signs all the time.
2). I can't move the mobs from the T-intersection into the two-way intersection. Due to the pathfinding AI of zombies, they won't fall into pits when passive (as triggered by the third function). In other words, it's unlikely that they'll get iron and diamond armor. I can't use water to move them around in the current configuration, because this will merely push them into the three tubes, rather than down into the second intersection.
3). The busses are really overly complicated. Compacting them is one of my priorities. I will admit that one factor adding to this is the fifth dispenser, which I was doing for...weapons? Except that the zombies will NEVER get a chance to hit you, rendering weaponry useless. So I'll probably remove this. This design might get used for skeletons or something though, in an Arena minigame or whatever...
4). Seriously. The busses. Getting everything to connect was horrible. If you can redesign this, I'd be incredibly grateful. I want all of the functions to remain, naturally, because simply having one non-separated zombie tube is dull. No use in making an mini-game if I don't have maximum functionality, no matter the excess.
Mob Storage:
Third up is the storage system for waves of mobs.
I haven't even got around to making a function that will pulse pistons in sequence (e.g: Storage (1st row, 2nd row, 1st row) and Release (3rd row, 2nd row, 1st row), simply because of those two pistons you're seeing in the first row there. But I've fixed it, so now I'll commence with those sequences. Maybe. I'm using an inversion method, since torches are cheaper than repeaters. So my main problem is going to be compacting this stuff.
Playing Field:
Finally, I've got the game itself to consider. Creating the field for it is probably going to be a simple matter.
The redstone functionality of the field component, however, rests in the recycling system and the scoreboard system. What if two mobs drop simultaneously? How will I create an incrementing counter for the number of failures the players have had?
Thank you for your time, and assistance if you're offering it.
You only need downward facing pistons in the corners? Then that's not too hard. All you have to do is to power the downward pistons when the sideways facing piston next to it is extended.
You'll have pistons arranged like this:
([>] represents a piston; the arrow points to where the piston is facing)
[v]
[>] <- there's TNT missing here.
[v]
[>] --| <- piston extends, and pushes the TNT away. Right after that, the upper piston tries to extend, but can't, because there's a piston arm below.
[v]
[>] piston retracts and a new block of TNT is placed. The TNT ring is now complete.
[v]
[>] the sideways facing piston tries to extend, but fails (you'll have to place a block that can't be pushed by pistons there, like a furnace).
[v]
[>] | the downwards facing piston pushes the TNT down.
All you have to do is place furnaces (or something similar) to prevent the pistons from pushing the TNT away and power the downwards facing pistons about 2 or 3 ticks after the sideways facing pistons.
Edit: God, drawing that was a pain. Thanks, minecraft forum.
That has yet to formally designated. I, however, intended for it to be at the piston that fires first (closest to the monostable circuit).
Also, for future reference, glass=TNT placeholder.
0
Also, for something trivially objective and obviously catalogued, like block IDs, try the Minecraft Wiki. 53 is Stairs, you may have mistyped something. If you pinpoint a specific problem after many tries, give details on it. Otherwise, you may have made a mistake.
Oh yes, and you'll need to set tile data on spawners to get them to spawn what you want. I believe you definitely need third-party software for that.
Hooray, threads like this...
0
On Survival. Hell no. Hard or nothing. Your stuff gets blown up? Part of the experience. Take it and move on.
However, since this is Minecraft and not reality, you can have whatever you like.
0
Otherwise, you can just make your arena directly below a mob spawner, or something.
0
If you had read the bolded parts, you would see that this is for Survival Vanilla. Merely looking at the images and the titles attached to them would give you enough of an idea. Therefore, using MCedit is not an option. Armor would prevent them from despawning (pumpkins would suffice). Having a custom spawner would negate the purpose of most of what I'm describing. However, your pressure plate idea, although it would limit the space of the recycling chute, could work. The main problem with this idea can be posed by the following questions: How would I detect if a mob fell on two pressure plates? How would I differentiate that from two mobs falling at once onto different pressure plates?
Thanks for the suggestion though, I hadn't actually considered pistons for pushing them off, since I was thinking of tripwire in any case.
Interesting idea. Although I'm also a bit confused as to how I'd do this. This would imply that I could not use water to push them forwards out of the sorter, as they would be attracted back to that water by the sunlight.
I was initially considering "shooting the zombies will make them all mob you". But there's the problem of them all bundling together in an easy-to-hit crowd, rather than proceeding uniformly across the field with relatively even distribution. The same problem probably applies with villagers. Having dividers between lines is not an option, as it limits diagonal shooting and makes the mobs move in a pattern that is too predictable. Also, it heavily impacts space constraints on the playing field.
0
0
0
These mob features make them a lot more interesting and unique, especially that zombie one (wonder how a grinder with a couple hundred zombies and a player would fare in a toss-up...Splash potions of healing needed, maybe). Of course, that feature is still being refined.
I have never used, nor agreed, with the concept of switching difficulty from Hard at any point. Have to say though, those skeletons can actually hurt you now, if you don't have a weapon.
0
The very best way to make that happen is to have a logical objective in mind when building the circuitry, so you actually have a reason to make the thing work, and a place to apply it. You can always come back to that objective and focus your build.
Tutorials can also be helpful, as they often expose some of the features of redstone. Namely, game mechanics that are somewhat obscure that can be used in circuitry.
0
What do you mean by the bit after the second comma? Do you mean like for releasing recycled mobs in a longer, more continuous game? I was seriously only really thinking playing a few waves, but I guess I didn't consider the length of the games, and options for that... The experience would feel a bit diminished if you used less mobs at any point though.
0
Doesn't sound possible. (To my limited knowledge)
The best you can get is just a circuit you can trigger with a button or whatever that would burn the torches out after several rapid pulses , but this has the disadvantage of reversion to the on-state.
I guess you could make the torch on-signal trigger the circuit that would burn the torches out.
You could also tell us what function you're attempting to create, in which case there might be a better alternative to what you're currently doing.
0
Not the sort of thing available in Survival, and Name Tags supposedly don't work on Villagers, although MCEdit will. I figure that a system without a testificate will work just as well.
0
I assume that the upper portion is what you're taking to be the playing field, where the mobs will move down and be recycled upwards. This system seems reasonable, but I have a few questions about it, namely:
1). Won't mobs still be attracted to the testificate down below, and thus try to move against the current of the upper system?
2). I'm not planning on having the field be a conveyer belt of water. I only want the out-of-sight lower part (recycling area) to be that way. It is possible that I might retain this design, but replace much of the upper part with dry land, and have the remaining water bits concealed.
3). Is there a better motive force than water for making the mobs move across dry land (e.g: I want them to move from their starting point towards me without being prompted by arrows)? Won't the mob AI make them all track me the instant I start shooting them, slowing the recycling system?
0
Updates:
Recycling is no longer a problem.
After thinking for a few seconds, I just used a repeater and powered the block from the side to invert the torch. Now I just need an instant repeater, or something.
If anyone could spare some of their time to look over how to compact this, I'd be really grateful. Saves me redstone, building time, space, etc.
When I say shooting range, I mean that player(s) will stand on an elevated platform and shoot at zombies approaching from the opposite end of the playing field. If the zombies reach the player-side, they'll drop through some opened trapdoors (which they mistake as a full block) into a net of tripwires, incrementing a counter. I would also like to recycle any mobs that get through, but that's optional and probably difficult.
An even more optional and difficult thing would be to make the mob processing ENTIRELY automated. That would entail settings for timing how many mobs you want (based on dropper-clocks, maybe?), then timed pulses to each of the functions I've built below.
If you REALLY want to get in-depth and can commit to some serious assistance across the board, I can provide you with the map. Otherwise, I'm just going to provide screenshots.
I have no background in logic, Redstone, and aesthetic design. I make no claims as to what my abilities are. Actually, no, I do. They are of someone who has no idea what he's doing and is learning as he goes along.
This is designed with Survival Vanilla in mind. Creative mode and Mods render the design obsolete. It is also being designed to actually be used in my Survival world, which uses neither of those things.
This contraption will have four main parts:
1). Spawning area
2). Mob Armory
3). Mob Storage
4). Game
Overview:
I've got the first three of those four parts laid out, but the game field itself hasn't been made because I have to consider balance and positioning. I'd also prefer to finish the mechanics before even attempting to make the GUI, and the first three things that I've named are the mechanics behind the GUI, which is the game as players will see it. Note that restocking has NOT been implemented yet. I will be using chained hoppers for restocking and extended storage (potions, armor), as they automatically move items without a redstone signal (unlike droppers).
The top bit is the spawner. It's 9x9, so there's a hole at the center that the mobs can funnel into. Pretty simple. The platform just beneath it houses four manual controls, which I will discuss shortly. The boxy thing beneath that platform has three manual controls, and is for armoring mobs up. I could do that manually and more simply, but I'd rather not. The bit beneath that is for storing 'waves' of mobs, for the game itself.
Spawner Area and General Functions:
I do hope that these images are automatically re-sized, like I've seen them in other forums. Anyways, this is a horrible back-view of the 'four functions' panel I mentioned earlier. Here are the four functions:
1). Lights to enable/disable spawning. Simple, and you can't really compact it more than I have.
2). Lava to make the zombies kill-able with a punch or two. This is mostly for EXP farm purposes and for leaving only armored mobs behind. I've done this via comparators, two pulses.
3). Potions. One Splash Potion of Healing, two Splash Potions of Harming II. This kills off unarmored mobs handily (after lava) and leaves armored ones standing. The harming pots restore the health of the armored mobs.
4). Drop chute. Just retracts the platform that mobs are standing on, dropping them from this processing center into the next phase.
I've already built all of these components and it's fairly compact. I'm showing this for completeness sake, so anyone who wants to help can get a better idea of what's going on.
Ideally, the game will have two settings: One, any mobs go. So you don't need lava unless if you want to EXP farm zombies, and you don't need potions at all. Two, armored mobs only. This is just a time-saving measure for skipping the armoring phase, but stocking up takes a while, so I figure that recycling is necessary if this setting is enabled.
I haven't built either of these settings into an automatic process. I have created NO automation in this whatsoever, everything is currently manual. Again, automating this would be a very big boon to me.
Mob Armory:
The most horribly annoying part of all of this, in my mind. This is the mob armoring system. In the background is the cutaway of the first processing center. As you can see, it's got four options (one is obscured by the vertical redstone used for the lights).
What happens is that once the mobs drop through the first processing center, they land on a single block in a three-way intersection. Most of them will immediately violently move into the three tubes, because compressed mobs tend to spray everywhere.
Some of them will remain standing on this 'intersection' like bit. The middle block of this T shaped intersection can retract to move mobs into another intersection, this one with two tubes.
These tubes correspond to armor types. The first three tubes are leather, chain, and gold, because I've got those in spades from spawners. The other two tubes are iron and diamond, which are far rarer and of greater durability and strength. Naturally, less mobs get into the last two tubes.
Here are the main functions of this system:
1). Release mechanism. This just retracts the block that caps all five tubes simultaneously, moving all mobs in the armoring tubes into the next area. This is most of the backside (shown in the second image)
2). Armoring mechanism. Five dispensers comprise the tubes that mobs get dropped into. I hook up all five tubes to an 8-tick clock (again, comparators, and the y-axis is one block) and let it run for a bit to armor some mobs. This is MOST of what you're seeing in those images.
3). Separation mechanism. Simply activates the piston at the T-intersection to retract a block, allowing access to the iron and diamond tubes. You can see it looping behind in the back of the second image.
Here are the problems with this system:
1). I've had to reduce fall damage as much as possible. The way I've designed this, the mobs don't ever get grouped together again for me to splash damage them again and heal them of any fall damage they've taken. As such, I've got to consider water placement and signs all the time.
2). I can't move the mobs from the T-intersection into the two-way intersection. Due to the pathfinding AI of zombies, they won't fall into pits when passive (as triggered by the third function). In other words, it's unlikely that they'll get iron and diamond armor. I can't use water to move them around in the current configuration, because this will merely push them into the three tubes, rather than down into the second intersection.
3). The busses are really overly complicated. Compacting them is one of my priorities. I will admit that one factor adding to this is the fifth dispenser, which I was doing for...weapons? Except that the zombies will NEVER get a chance to hit you, rendering weaponry useless. So I'll probably remove this. This design might get used for skeletons or something though, in an Arena minigame or whatever...
4). Seriously. The busses. Getting everything to connect was horrible. If you can redesign this, I'd be incredibly grateful. I want all of the functions to remain, naturally, because simply having one non-separated zombie tube is dull. No use in making an mini-game if I don't have maximum functionality, no matter the excess.
Mob Storage:
Third up is the storage system for waves of mobs.
I haven't even got around to making a function that will pulse pistons in sequence (e.g: Storage (1st row, 2nd row, 1st row) and Release (3rd row, 2nd row, 1st row), simply because of those two pistons you're seeing in the first row there. But I've fixed it, so now I'll commence with those sequences. Maybe. I'm using an inversion method, since torches are cheaper than repeaters. So my main problem is going to be compacting this stuff.
Playing Field:
Finally, I've got the game itself to consider. Creating the field for it is probably going to be a simple matter.
The redstone functionality of the field component, however, rests in the recycling system and the scoreboard system. What if two mobs drop simultaneously? How will I create an incrementing counter for the number of failures the players have had?
Thank you for your time, and assistance if you're offering it.
0
This seems to work. Thanks.
What's so inefficient about it?
And it's for some kind of TNT thing I am making. It shoots things.
0
That has yet to formally designated. I, however, intended for it to be at the piston that fires first (closest to the monostable circuit).
Also, for future reference, glass=TNT placeholder.