Ender IO Forestry

Ender IO Forestry

954k Downloads

Block Detector output is inverted

OhiraKyou opened this issue ยท 5 comments

commented

Issue Description:

As a rule, vanilla Minecraft switches emit redstone only when activated. The Block Detector is basically a pressure plate for blocks. So, I would expect a redstone signal to be emitted only when a block is detected.

What happens:

A redstone signal is emitted until a block is detected.

What you expected to happen:

A redstone signal to be emitted only when a block is detected.

Steps to reproduce:

  1. Place Block Detector.
  2. Place Redstone near Block Detector.
  3. Observe that the redstone is active without a block being detected.

Affected Versions (Do not use "latest"):

  • EnderIO: 1.12.2-5.0.38
  • EnderCore: 1.12.2-0.5.43
  • Minecraft: 1.12.2
  • Forge: 1.12.2-14.23.5.2768-universal
  • SpongeForge? no
  • Optifine? no
  • Single player and server.

Your most recent log file where the issue was present:

latest.log

commented

This is not a bug. The detector was designed that way, just look at its model...

commented

It is not inconsistent with vanilla; the pure vanilla block presence detector (repeater through the block to detect) works the same way.

commented

It being designed that way doesn't justify the design being inconsistent with other Minecraft detector blocks. Intentionally inconsistent design is still inconsistent. It should emit redstone only when it detects something rather than when it does not. I like the block, and I'm glad it was added. But, the inverted activation condition is not intuitive.

commented

In terms of multi-block redstone structures, sure. But, this is a single block, and that's an important distinction. With pressure plates, tripwires, wood buttons (shot by arrows), and block observers all emitting redstone when something is detected rather than when not, I'm convinced that, if a block detector were implemented in vanilla, it would definitely not be inverted.

More to the point, the "this is a redstone multi-block in a can" argument doesn't hold as much water when you take into account that the user generally decides where a redstone multi-block structure begins and ends. If I were to compress a multi-block redstone block detector into a single block, I would definitely include the inverter torch that I always include anyway. For example, I used this block detector to replace an automatic door opener that triggers on detecting an elevator base, and that required fixing the incomplete single-block multi-block by adding the torch myself.

So, rather than treating this like some kind of arbitrary single-block multi-block, it should simply be treated as a standalone pressure plate for blocks.

commented

Actually, now that I think about it, a vanilla redstone contraption to detect a block also emits a signal when a block is detected unless you include the torch afterward to invert the signal. Sorry for the confusion there. But, you get my point. It's a matter of arbitrarily deciding what part of the structure is part of the single-block multi-block rather than intuitively following conventions for standalone detectors.