What happens:
testfor returns true when rxm <= player_rotation <= rx
What should happen:
if rxm <= rx then
(returns true when rxm <= player_rotation <= rx)
else
(returns true when rxm <= player_rotation OR player_rotation <= rx)
With this change, it is appropriate to rename rxm and rx from minimum/maximum x rotation to leftmost and rightmost angle.
This change will not alter any outputs for current usage where rxm <= rx
This will allow arbitrary sectors to be used for testing, regardless of whether the sector intersects with the discontinuity in the north direction. This will allow me to use less red stone circuitry when testing if I am looking in the north direction from 110 to -110. Currently I would have to use two command blocks to split up the sector: -180 to -110 and 110 to 180.
A similar change may be made with the y rotation which would allow an arbitrary vertical angle to wrap from the bottom to top. However, since the mechanics has a discontinuity rather than just the model, it would be more difficult to intuitively describe the bounds in documentation than it would be for the x rotation.
Comments 6
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.
Bug: A mistake in a software project. Any observed reproducible behavior not consistent with the behavior intended by the developers may be classified as a bug.
The current behaviour is clearly intended.
I see your point about the +180° / -180° wrap around on the x axis, but your proposal remains a feature request.
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.
This site is for bug reports only. For feature suggestions or changes please see: Minecraft Suggestions on Reddit.