Randal Jones
- randalonel
- randalonel
- Europe/Stockholm
- Yes
- No
MC-7961
This issue has not been fixed as of 13w07a. The screenshot from 05/Feb/13 might show that the comparator has not updated. My set-up is shown in two new pictures. The chest is half-full so the comparator should be lit-
which it is when the chest is not blocked from opening. Next I place a block above the chest and the comparator remains on. But if I force the comparator to update by momentarily applying a signal to it's side the lights go off and stay off. When I remove the block above the chest the comparator output remains off until I either push the button again or simply open and close the chest-then the comparator lights up again. Because of the long redstone path, pushing the button when the chest is not blocked makes no difference because the low signal strength from the button is less than the signal from the half-full chest. Pushing the button only serves to force the comparator to update.
The block above the chest prevents the comparator from reporting that it is not empty.
This issue has not been fixed as of 13w07a. The screenshot from 05/Feb/13 might show that the comparator has not updated. My set-up is shown in two new pictures. The chest is half-full so the comparator should be lit-
which it is when the chest is not blocked from opening. Next I place a block above the chest and the comparator remains on. But if I force the comparator to update by momentarily applying a signal to it's side the lights go off and stay off. When I remove the block above the chest the comparator output remains off until I either push the button again or simply open and close the chest-then the comparator lights up again. Because of the long redstone path, pushing the button when the chest is not blocked makes no difference because the low signal strength from the button is less than the signal from the half-full chest. Pushing the button only serves to force the comparator to update.
This issue has not been fixed as of 13w07a. My set-up is shown in two new pictures. The chest is half-full so the comparator should be lit-
which it is when the chest is not blocked from opening. Next I place a block above the chest and the comparator remains on. But if I force the comparator to update by momentarily applying a signal to it's side the lights go off and stay off. When I remove the block above the chest the comparator output remains off until I either push the button again or simply open and close the chest-then the comparator lights up again. Because of the long redstone path, pushing the button when the chest is not blocked makes no difference because the low signal strength from the button is less than the signal from the half-full chest. Pushing the button only serves to force the comparator to update. (The screenshot from 05/Feb/13 makes it appear that the problem was fixed but it might simply be that the comparator has not updated.)
When player (or mob) is in a block of water (source or flowing) and that block is touching the end of an 8-block flow of water and under certain conditions depending on the direction of the flow and world quadrant
, it may be that individual can not exit the water from that block (except by flying in creative mode) or it may be that one can't exit toward the incoming stream but can in other directions. In still other cases, it is possible to exit as expected. The pictures and world download makes it clearer.
In the pictures the orange plus is centered on 0,0 (See Pic 1). In each of the four test areas, a central source block of water flows in four directions for eight blocks and stops at the edge of a 1x1 hole with a source block of water in it. The demo would also work if instead of a hole, there was a perpendicular flow of water (as shown in Pic 8). In some cases the hole is surrounded by red blocks meaning there is no way to jump out in survival mode (Pic 3). In two cases, no escape is possible even from an adjacent block if the hole is enlarged to 1x2 in the particular direction shown (Pic 5). A zombie has discovered the problem in Pic 6. In other positions escape is possible in any direction as expected (Pic 2). In some orientations, one can not jump into the end of the feeding stream, but can turn around and jump out (Pic 4).
A common Minecraft setup (Pic 7, 8) involves an area of flowing water that stops at the edge of a collection stream. Items dropped in the large area flow over the edge and continue to a collection point. Sometimes depending on the orientation of the flow and the signs of the x and z coordinates, one can not jump up one block from the collection stream to the edge of the flowing water.
This problem might even be useful as a trap (Pic 6) if it was not dependent on one's location in the world.
I've uploaded a demo world for testing: See Water Trap Demo.zip
This issue is clearly related to
MC-and I was inspired to check the effect of the world quadrant and flow direction, and even to use colored wool to illustrate the problem, but my setup is very different: it works when exiting deep water or flowing water and and I'm not entering a source block of water blocked by a sign and in general it seems like a more practical or common setup. Please don't dismiss it as a duplicate; let both related issues remain open until the problem(s) is/are fixed and both set-ups are tested. The fix for one may not fix the other.3510When player (or mob) is in a block of water (source or flowing) and that block is touching the end of an 8-block flow of water and under certain conditions depending on the direction of the flow and world quadrant
In the pictures the orange plus is centered on 0,0 (See Pic 1). In each of the four test areas, a central source block of water flows in four directions for eight blocks and stops at the edge of a 1x1 hole with a source block of water in it. The demo would also work if instead of a hole, there was a perpendicular flow of water (as shown in Pic 8). In some cases the hole is surrounded by red blocks meaning there is no way to jump out in survival mode (Pic 3). In two cases, no escape is possible even from an adjacent block if the hole is enlarged to 1x2 in the particular direction shown (Pic 5). A zombie has discovered the problem in Pic 6. In other positions escape is possible in any direction as expected (Pic 2). In some orientations, one can not jump into the end of the feeding stream, but can turn around and jump out (Pic 4).
A common Minecraft setup (Pic 7, 8) involves an area of flowing water that stops at the edge of a collection stream. Items dropped in the large area flow over the edge and continue to a collection point. Sometimes depending on the orientation of the flow and the signs of the x and z coordinates, one can not jump up one block from the collection stream to the edge of the flowing water.
This problem might even be useful as a trap (Pic 6) if it was not dependent on one's location in the world.
I've uploaded a demo world for testing: See Water Trap Demo.zip
This issue is clearly related to
MC-2324and I was inspired to check the effect of the world quadrant and flow direction, and even to use colored wool to illustrate the problem, but my setup is very different: it works when exiting deep water or flowing water and and I'm not entering a source block of water blocked by a sign and in general it seems like a more practical or common setup. Please don't dismiss it as a duplicate; let both related issues remain open until the problem(s) is/are fixed and both set-ups are tested. The fix for one may not fix the other.
My report (
MC-8849) is said to be a duplicate of this one but in includes crash reports from 13w04a, FYI.After inventing things with hoppers for a week or so, I've decided that I like this behavior as a feature and I hope you don't fix it. A sticky piston can be used to stop the flow of items though a series of hoppers and chests and that might prove useful in a system. If trapped chest don't have this limitation (per
MC-7543), all the better. Then we have a choice.Whether in the ocean or a one-block-deep pool, baby chickens die within a minute. Baby pigs and cows sink and die almost immediately in the ocean. Baby villagers survive to adulthood while bobbing in the ocean – animals should dos the same. [Notes from MC 9492]
I suggest checking to see if this is an unintended consequence of shrinking the hit boxes of the babies. Perhaps they share code for swimming and don't float high enough to breathe.
Death occurs even if there is a solid block in a corner, which does not present a wall-face to the chickens. In other words, a 4x4 enclosure can be made with 8 wall blocks and 4 optional corner blocks. Adult chickens die if even one of the corner blocks is solid. This applies only to the first course of blocks sitting on ground level. Second-story blocks (above the chicken's eye-level) may be solid without causing a problem.
Does the fact that my bug report was flagged as a duplicate mean that I wasted my efforts to experiment, understand, and document the problem? I feel that my report is more detailed and helpful than the one it "duplicates" to the programmers who will try to fix the problem. I want to be helpful, not waste my time.
Thanks for the respect from ChrisvA who was first with this issue and moderator Tails who reopened my report. I would have added my thoughts in a comment on ChrisvA's original report if I had been certain that my observations would be considered a duplicate but since I wasn't "pushing" the chickens, I thought it might be a separate issue and it may be that fixing the problem I reported will still leave solid blocks deadly if you push the chickens into them. I hope not.
Perhaps the workflow needs another designation such as "additional info" or "suplimentary", which, like "duplicate", indicates that the report is not first but notes that it contains more information that might be of interest to the community or helpful for the bug-fixers. Unlike a "duplicate", "suplimentary" reports should not be marked "resolved", but remain open gathering comments and such until the problem is actually fixed--as I noted above, it may be that an issue that was marked "suplimentary" remains problematic when the "original" is repaired.
It's not just chickens. Cows and pigs die if there is a solid block at their head-level. They might be pushed into a block by others or they might wander into it themselves. Another, probably related, issue is that occationally mobs escape their cage for no apparent reason. They dream of walking free and sometimes they don't return. As a result, cows and pigs wander around the ranch and I frequently find their meat items dropped near solid blocks where they have died own their own. In my opinion this is a serious and frustrating issue that should be resolved before the next update. We can live without the lighting improvements but not being able to build enclosures with solid blocks is nearly unacceptable.
This issue has not been fixed as of 13w07a. My set-up is shown in two new pictures. The chest is half-full so the comparator should be lit, which it is when the chest is not blocked from opening. Next I place a block above the chest and the comparator remains on. But if I force the comparator to update by momentarily applying a signal to it's side the lights go off and stay off. When I remove the block above the chest the comparator output remains off until I either push the button again or simply open and close the chest; then the comparator lights up again. Because of the long redstone path, pushing the button when the chest is not blocked makes no difference because the low signal strength from the button is less than the signal from the half-full chest. Pushing the button only serves to force the comparator to update. (The screenshot from 05/Feb/13 makes it appear that the problem was fixed but it might simply be that the comparator has not updated.)
As I noted in my description, I knew that my report is related to
MC-2324. I made a sincere and diligent effort to search for and understand related issues and I concluded that the differences are significant and I think both reports should remain open. Baring that, do you recommend that I add all my notes and pictures toMC-2324so they can help solve the problem? I don't want my work to be lost in the garbage-can of duplicate issues.There seems to be some inconsistency in the death-rate for chickens caged by solid blocks and surprisingly, fewer deaths occur when it's very crowded. More details on request.
Three bugs force the design of chicken and other animal farms in this version to be very different from those of the past the past: Animals living in and "leaking" through transparent blocks, dying because of solid blocks and babies dying in water. I am amazed that it seems these bugs are not assigned nor being addressed before the next release. These bugs are illogical and seriously detrimental to gameplay and they will break many currently working farms and complicate any new redstone designs that are attempted. Mojang--are you listening?
Three bugs force the design of chicken and other animal farms in this version to be very different from those of the past: Animals living in and "leaking" through transparent blocks, dying because of solid blocks and babies dying in water. I am amazed that it seems these bugs are not assigned nor being addressed before the next release. These bugs are illogical and seriously detrimental to gameplay and they will break many currently working farms and complicate any new redstone designs that are attempted. Mojang--are you listening?
Comparators do not cause droppers to fire continuously in 13w09c. Is this the same bug?
Oh no! I loved that "feature". It's very useful: A hopper, a comparator output and a power source all attached to a dropper or dispenser made it fully-automatic to empty all of it's contents without a clock--at three per second it is (was) faster than a clock can run, in fact. I'm sure I read that listed in the wiki as a feature/use of a comparator with a dispenser or dropper but there is no mention of it now. It worked yesterday when I was using 13w07a and now you are saying it has been "fixed?!" That's unfortunate.