Fredoscar, there's no need to disable mob drops and use players' experience to store data. That technique was used by mapmakers to store data before the scoreboard commands were introduced. Now that you can create dummy variables to manipulate as you please, that method is no longer needed.
I answered your question on another forum, but in case someone else here is interested:
Try setting up the following objectives:
Type.....Name
totalKillCount...k1
playerKillCount...p1
dummy...processing
dummy...sum
First make a command block with the command:
/testfor @p[score_processing_min=1]
Have a clock activating that block. Run the output of that to an inverter, which will then power this block:
/scoreboard players set @r[score_processing=0] processing 1
Now add this chain of command blocks to the clock:
/scoreboard players remove @p[score_processing=1,score_p1_min=1] p1 1
And a comparator to that powering this:
/scoreboard players remove @p[score_processing=1] k1 1
Connect another pair of command blocks to the clock:
/scoreboard players remove @p[score_processing=1, score_p1=0, score_k1_min=1] k1 1
And a comparator for that would power this:
/scoreboard players add @a[team=<team name>] sum 1
Finally you need to make the player as done being processed by putting this on the clock too:
/scoreboard players set @p[score_processing=1, score_k1=0] processing 1
What that all should do is flag a random player for processing, then decrease both the kill count and player kill counts of that player until the player kill count is 0, at which point the kill count will represent only mob kills. Then the kill sum shared by all players will be incremented by the number of mob kills that player had.
Using that system and some minor tweaks to the specifiers, you could process multiple players simultaneously by having additional sets of those command blocks, but with the "processing" value set to 2 or 3 or whatever. The idea is to be able to uniquely identify a player until we're done running commands on that player.
Note that with this system, a player's "sum" score will represent the total number of mob kills by all players made only while that player was playing. Maybe that will work for you. If not, there are some other options. It could be made that one named player is the official scorekeeper, and only kills made while that player was on counts. Or you could count kills made while the scorekeeper was offline, but then you'd need the players who made kills to be on at the same time in order to process their data. A different option would be to, instead of incrementing a player "sum" score, replace that command block with a dropper. It can feed items into a chest (or chain of chests and hoppers) and you will be able to look inside the chest to see how many kills were made. You could also make a binary counter out of redstone (or any kind of counter).
1. Have the cart on a loop, periodically passing over the detector rail rather than sitting on it. When full, activate a switch track.
2. Use a piston to push the cart from the detector rail onto a powered rail, or to switch the track under it.
3. Put the detector rail on a hill and use a piston to block the cart from falling. Retract the piston when the cart is full.
Option 1 might be no good if you want it to sit under or over a hopper.
This sounds pretty unlikely, and from a quick look at WeightedRandomChestContent.java and some related classes, I don't see anything that would appear to cause this. I still have to step through it, but nothing stands out to me yet.
People are so easily taken in by small sample sizes, how many chests did you look at, really? And how many unremarkable ones were there that you just forgot? There are several cognitive biases in play here.
First you want to work toward getting an Efficiency IV or V diamond pick, which speeds things up tremendously. You'll never want to go back to an unenchanted pick. If you're really determined, you can get a beacon and put it on Haste.
Most "obsidian farms" are a waste of time I think. Just find a pool of lava and pour a water bucket over the top. Then mine away a block of stone on the side of the obsidian layer and fill it with water. Mine away the obsidian starting from there, and the water will move in to freeze the lower layers of lava before it toasts your obsidian drops.
The only way to go faster is to build a semi-automatic farm where you just hold down left-click and keep mining obsidian, but that's not an easy build. You could make one where you place down redstone and have it converted, then get moved along by a piston conveyor belt to mine them one by one.
Actually, I'm forgetting Wither based obsidian farms, that's a thing now isn't it. Properly designed, that would be the fastest. But without building a complex farm, that water+lava pool method I explained works pretty well.
The desynched clock method isn't going to work for exactly 50 seconds. That's 500 redstone ticks, which has a prime factorization of (2^2)*(5^3). The 2^2 = 4 can be done by setting all the repeaters to 4, but you can't cut down on the 125 repeaters it would take to meet the 5^3 requirement.
There are other clever ways to make clocks, but I figured I'd point out not to explore that route.
If you want to make a good one, there's a lot to know. This tutorial is long, but it is thorough, accurate, and up to date:
Except for one change, which is that mobs tend not to die anymore if they fall into water streams. It breaks their falls better now. The most popular solution to that seems to be a row of hatches extended by a tripwire above them. You could also have pistons make the item collection stream intermittent, or have pistons push around the floor to let items sift through. There's an example of the hatch thing here:
That's a great design. I can't imagine how the items/h could be improved except to move some of the wiring to a different level so that there's a few more air blocks around the spawn floors, but there's already plenty so it would be a very small improvement.
As for the other mobs, I believe the game just adds witches to the spawn list around the witch huts, and doesn't remove the other mobs. I haven't looked at the code for 1.4 yet, but from your observations I think it's safe to say that's true.
If you want to control villager breeding, the easiest way it seems to me would be to have pistons that block the skylight over the wooden doors, reducing the "house" count until the maximum village population is at or below the current population.
It's possible to distinguish carts with players or mobs inside from empty/storage/powered carts. Empty and storage carts have a much lower momentum cap, so even if you speed them up with a ton of powered rails, they will quickly come to a stop. Try this:
PDRRR...RRRS
A powered rail, followed by a detector rail, then several regular rails (you'll have to experiment with how many), then a switch track. The detector rail operates the switch track, with some number of repeaters to act as a pulse sustainer if necessary. Occupied carts will quickly reach the switch and go one way, but storage carts will have slowed down slightly, and the track will have switched by then.
A pistonless 1-tick pulse limiter is typically made by putting the input through an inverter and a repeater set to a 3-tick delay, then putting those outputs through a NOR gate. But why isn't that a 2-tick pulse emitter? Why isn't it a 2-tick delay on the repeater that makes a 1-tick pulse emitter?
Imagine a pulse diagram. At time 0, the input is low. At time 1, it becomes high, but neither the inverter (redstone torch) or repeater respond immediately. At time 2, the torch goes low. If the repeater is set to 2 ticks, it should still be low now. Then at time 3, the second redstone torch ought to blink on, since both inputs were low. But for some reason it does not unless the repeater is set to 3-ticks.
So why does the game do that? Would you call it a bug? I would.
0
0
Try setting up the following objectives:
Type.....Name
totalKillCount...k1
playerKillCount...p1
dummy...processing
dummy...sum
First make a command block with the command:
/testfor @p[score_processing_min=1]
Have a clock activating that block. Run the output of that to an inverter, which will then power this block:
/scoreboard players set @r[score_processing=0] processing 1
Now add this chain of command blocks to the clock:
/scoreboard players remove @p[score_processing=1,score_p1_min=1] p1 1
And a comparator to that powering this:
/scoreboard players remove @p[score_processing=1] k1 1
Connect another pair of command blocks to the clock:
/scoreboard players remove @p[score_processing=1, score_p1=0, score_k1_min=1] k1 1
And a comparator for that would power this:
/scoreboard players add @a[team=<team name>] sum 1
Finally you need to make the player as done being processed by putting this on the clock too:
/scoreboard players set @p[score_processing=1, score_k1=0] processing 1
What that all should do is flag a random player for processing, then decrease both the kill count and player kill counts of that player until the player kill count is 0, at which point the kill count will represent only mob kills. Then the kill sum shared by all players will be incremented by the number of mob kills that player had.
Using that system and some minor tweaks to the specifiers, you could process multiple players simultaneously by having additional sets of those command blocks, but with the "processing" value set to 2 or 3 or whatever. The idea is to be able to uniquely identify a player until we're done running commands on that player.
Note that with this system, a player's "sum" score will represent the total number of mob kills by all players made only while that player was playing. Maybe that will work for you. If not, there are some other options. It could be made that one named player is the official scorekeeper, and only kills made while that player was on counts. Or you could count kills made while the scorekeeper was offline, but then you'd need the players who made kills to be on at the same time in order to process their data. A different option would be to, instead of incrementing a player "sum" score, replace that command block with a dropper. It can feed items into a chest (or chain of chests and hoppers) and you will be able to look inside the chest to see how many kills were made. You could also make a binary counter out of redstone (or any kind of counter).
0
And those bronies will just be so goddamn happy about it. Man, I hate them, they ruin everything.
0
1. Have the cart on a loop, periodically passing over the detector rail rather than sitting on it. When full, activate a switch track.
2. Use a piston to push the cart from the detector rail onto a powered rail, or to switch the track under it.
3. Put the detector rail on a hill and use a piston to block the cart from falling. Retract the piston when the cart is full.
Option 1 might be no good if you want it to sit under or over a hopper.
0
People are so easily taken in by small sample sizes, how many chests did you look at, really? And how many unremarkable ones were there that you just forgot? There are several cognitive biases in play here.
0
Most "obsidian farms" are a waste of time I think. Just find a pool of lava and pour a water bucket over the top. Then mine away a block of stone on the side of the obsidian layer and fill it with water. Mine away the obsidian starting from there, and the water will move in to freeze the lower layers of lava before it toasts your obsidian drops.
The only way to go faster is to build a semi-automatic farm where you just hold down left-click and keep mining obsidian, but that's not an easy build. You could make one where you place down redstone and have it converted, then get moved along by a piston conveyor belt to mine them one by one.
Actually, I'm forgetting Wither based obsidian farms, that's a thing now isn't it. Properly designed, that would be the fastest. But without building a complex farm, that water+lava pool method I explained works pretty well.
0
There are other clever ways to make clocks, but I figured I'd point out not to explore that route.
0
Except for one change, which is that mobs tend not to die anymore if they fall into water streams. It breaks their falls better now. The most popular solution to that seems to be a row of hatches extended by a tripwire above them. You could also have pistons make the item collection stream intermittent, or have pistons push around the floor to let items sift through. There's an example of the hatch thing here:
0
0
As for the other mobs, I believe the game just adds witches to the spawn list around the witch huts, and doesn't remove the other mobs. I haven't looked at the code for 1.4 yet, but from your observations I think it's safe to say that's true.
0
1
PDRRR...RRRS
A powered rail, followed by a detector rail, then several regular rails (you'll have to experiment with how many), then a switch track. The detector rail operates the switch track, with some number of repeaters to act as a pulse sustainer if necessary. Occupied carts will quickly reach the switch and go one way, but storage carts will have slowed down slightly, and the track will have switched by then.
0
0
0
Imagine a pulse diagram. At time 0, the input is low. At time 1, it becomes high, but neither the inverter (redstone torch) or repeater respond immediately. At time 2, the torch goes low. If the repeater is set to 2 ticks, it should still be low now. Then at time 3, the second redstone torch ought to blink on, since both inputs were low. But for some reason it does not unless the repeater is set to 3-ticks.
So why does the game do that? Would you call it a bug? I would.