Timothy Swan

I built a base on my friend's server. He does have some plugins, but we think that it may be this bug. If it helps with the debugging process, we can let you investigate on the server. There is a pen that consistently keeps losing sheep. Maybe there is a way to observe what is going on and pinpoint the issue. It appears to happen when I stand within a few chunks of them for a long time and I am still online when it occurs. Also note, sometimes all the sheep disappear and sometimes just most leaving one to three. One time, when I returned to the pen, only 1/4 of the pen had sheep, like a perfect square. The entire pen seems to lie flush with a chunk though.

How is this a duplicate of an invalid issue due to optifine being installed when I don't have it installed?

It's okay, I'll just go ahead and stop giving you development advice and move on to implementing my ideas elsewhere. It is clear to me that everyone at Mojang still has their heads stuck in an aquarium and doesn't understand how important it is to design things correctly from the top down.

Perhaps this is not a bug at the code logic level, but maybe it does exist at the development level.

I've notices there are many bugs that seem to come from the design level, for instance, redstone mechanics could be designed to be directionally and positionally independent but they are not. The previous state of some circuit should be the only predecessor to what happens to the next state. However, in minecraft, the redstone is updated serially so it matters what gets updated first. Each block should have its original state before the tick as well as any proposed changed state in order to correctly calculate further adjacent blocks. A good example of this well defined mechanic would be Conway's Game of Life. The rules themselves involve no actual implementation or rarely even psudocode, yet it easily can be mathematically shown to be correct, symmetric, etc. The same can be done for something like redstone base mechanics or block update propagation.

It is true that the developers may have implemented a linear model for the variable defining what direction is to be faced, but at the higher level this model should not even exist. I would expect a hierarchy to look something like:

Logical Behavior: "A system for defining an arbitrary horizontal view sector." =>
Model: "-180 < x < 180, xr=max(xr), xrm=min(xr)" =>
Functional Implementation: "if xrm < xrot < xr return true"

The bug exists as a mistake in the project between the stages "Logical Behavior" and "Model" rather than between the stages of "Model" and "Functional Implementation." Although no mistakes were made between the bottom two stages, bugs from these stages can arise if they are expected to fulfill the "Logical Behavior" level when conflicts arise between this and other "Logical Behavior" branches.

Consider the following development:
Logical Behavior: "A system for defining an arbitrary horizontal view sector." =>
Model: "-180 < x < 180, xr=max(xr), xrm=min(xr), directive for functionality: continuity must be assumed from 179.9_ to -180" =>
Functional Implementation: "if rxm <= rx then (returns true when rxm <= player_rotation <= rx) else (returns true when rxm <= player_rotation OR player_rotation <= rx)"

As you can see, the model change itself does not change any code until the implementation level arrives, however, it correctly represents the intended logical behavior by putting a necessary restriction on implementation. This is a common in all mathematics. A simple example is the division function. If it was neglected to state that the denominator parameter cannot equal zero, then it simple to come up with a contradictory proof that 1=2, so the directive must be enforced.

I don't understand why the original post wouldn't be considered a bug. This solution is almost strictly better than the previous with the only exception that contraptions already using command blocks with rxm > rx may receive outputs. To fix such a contraption, that command block can be replaced with a dirt block since it never outputs anyway.

I have come across a situation where (rxm, rx) is switched with (rym, ry).

Block types represent what damage occurs when walking off block height into the tube with water 6 blocks above the ground.
Redstone: death
Spruce: 0 heart
Lapis: -1/2 heart
Sandstone: -1 heart

This issue still has not been fixed. I played with the snapshot because I wanted to develop my mob system. With a water source 6 blocks above the ground, fall damage is some non-increasing function of height, however, it is consistent. Every time I fall 55 blocks above the ground (49 above the water) I get 1/2 half heart of damage. If I fall 60 blocks in the same set up, I get 1 heart of damage. However, if I fall 61 blocks, I always get 0 damage. 62 blocks, always 1 heart. 63 blocks, 0. 64, 1. 65 blocks, always death. 66 blocks, always 1 heart. 68 blocks, always no damage. 70 blocks, death.

Tested and updated. Same thing happens in 1.6.2

By the way, because the water buckets all are dispensed the first time, but not retracted the second time is proof that the behavior difference is not dependent on the location but the status of the dispenser.

After replicating your setup, it looks like you are using buckets in the row under the grass blocks.

I disagree that the bug is the same as MC-11193
The new bug would be that the dispensers have different behavior when they dispense and retract water. This is true even if there is quasi-power updates and source blocks being created in front of the dispensers. Although the bug only occurs at certain locations which makes it sound like a location dependent bug like MC-11193, the difference in behavior of the two dispenser events is not a result of them being at different locations. MC-11193 displays a bug which shows different behavior because of different locations. This bug with dispenser behavior, of course, doesn't depend on the location, since given the same location, the same dispenser acts differently when retracting water as opposed to dispensing water. Even if quasi-powered in a strange order, the input and number of clicks should be the same in both events.

Actually, I don't think this can be the same bug as MC-11193. That one depends on location. This one doesn't, in fact, I am about to report a bug showing that I don't have to break any redstone blocks or copy anything to multiple locations and the behavior in the same place for the same redstone is different depending on whether the dispenser is dispencing water or retracting it.
My report: MC-22926

I really want this to get fixed because I make my farms in circular shapes and they have a lot of north-west fence corners in it.