Phil Schaf
Comments
Only Mojang can determine what's a bug, and what's working as intended.
if it’s unclear, yes. but in this case, it’s clearly a workaround, which i will now logically derive.
obsidian is intended to be a piston extension stopper. it had that property in the original piston mod and has it now, without being a tile entity
the other blocks (as this bug title says) all have the property of being a tile entity. we know that moving the data isn’t trivial, but not impossible because
pistons work by saving the block ids of the pushed block in their own tile entities during pushing, which makes dealing with the pushed block’s tile entities nontrivial, but
notch doesn’t think it’s difficult, and it has been implemented in the original piston mod
⇒ it’s a workaround, no gameplay decision or performance issue.
furthermore, any workaround which is clearly only in place due to difficulties in implementation is a bug unless it ascended to a feature (e.g. if the workaround would have enabled something else). the case of an “ascended workaround” isn’t given, since obsidian is the only block clearly intended to inhibit piston extension. all other blocks have that property just because they have tile entities which are difficult to move.
⇒ it’s a bug, and no ascended bug which has become a feature.
so logic demands that this bug is marked as such. if you have an actual argument that i haven’t considered, please name it. but since your only argument was “we don’t know the reason for this behavior, only mojang can tell it to us”, and i have just inferred the exact reason from the information we have, there is no argument against reopening left.
in case all this sounds arrogant or otherwise inappropriate to you, please don’t interpret it as such: i’m no native english speaker and i often come over as rude if i just want to be direct.
please reopen. just because the workaround works as intended, doesn’t mean the behavior is set in stone.
maybe it’s difficult, and the current implementation provided an easy way to implement pistons at the time, without spending too much time on a corner case like this. but it’s fact that the current behavior (with that workaround in place) isn’t a rule of nature or otherwise impossible to change, and neither has it any lore/logic demanding it. it’s possible to fix and minecraft would improve by fixing it.
so this is still a bug. maybe not one that’s intended to be fixed in the near future, but a bug nonetheless, and has to be open until it’s fixed.
but normal hoppers can output items to containers. i thought the hopper minecart could do that, too.
it makes sense if the hopper minecart is only meant to do the “sucking stuff in” functionality of a normal hopper, but it’s not obvious why it should only partly behave like a real hopper.
the image dinnerbone posted, as well as the name both imply that it does exactly what jonathan said.
however, it doesn’t DROP items, but throws them.
so how is this not unexpected behavior?
did you even read the bug report?
and if you’re positive that this works as intended, why?
so it has to be reopened anyway, because there was no reason for changing its status to “works as intended” in the first place. (default to open until we hear from mojang, since closed bugs are “off the charts” and don’t get looked at)