Hartspoon
Comments
Still a concern in 14w08a. And it should clearly be marked as confirmed.
There is clearly a bug. I think there is a confusion in the term used in this thread, @unknown talked about hopper #2 pulling while there is clearly nothing to pull from. But there is indeed a bug, and it is quite easy to reproduce:
It seems that when hopper #2 receives an item from a push by hopper #1, it become unable to push during the next tick, even if there are already items in it. If you put a stack of 64 items in the chest, you can see hopper #2 stocking the whole stack before starting to empty itself. I also noted that the bug is inconsistent. While happening most of the time, sometimes it doesn't. Put a new stack and it happens again.
I also tried to pass six stacks in this system. Once hopper #2 is filled, it isn't able to accept more items, and start pushing them. But not being full again, hopper #1 will push an item into it, preventing it from pushing again. So hopper #2 will basically alternate constantly between accepting and pushing an item, halving it's normal rate without any apparent reason.
Items will start to pile up in hopper #1 because hopper #2 clearly can't push them at a rate of 2.5 items per second. And once hopper #1 is empty, hopper #2 meets the normal rate again.
I'm unable to reproduce this bug. Despite having tested every orientation (just in case) and in 14w06b as well.
I'd also like to add that the expected behaviour for the hopper below is to pull an item from the hopper above every 4 redstone tick, not always.
My guess is that you actually put a whole stack directly in the hopper above your filter. In consequences, the filter pull an item from that hopper every 0.4 second, and the said hopper push an item in the next hopper of the chain every 0.4 second too. Halving the number of items actually pulled by the filter. If this is what you did, then it's a perfectly normal behaviour. You can't put a whole stack directly in the hopper above your filter. You have to feed that hopper only one item at a time too.
If this is what you did: Work as Intended.
If not: Cannot reproduce, please provide a world save or a better explanation.
Oh, you're right, the game doesn't actually bind char codes but key codes to the control, therefore not changing depending on your layout (which is also a problem, in my opinion. If I have a qwerty layout on my azerty keyboard, I expect the game, as any other software, to recognise the qwerty layout. But it's a problem that many game engines share so I'm pretty sure it's way harder to fix than it seems, and since Minecraft allows us to rebind the keys, it's not even needed. But I digress.) So, my bad, that's not a layout problem.
However, those layouts are based on real keyboard configurations, so it's pretty much the same. There has to be other keyboards than the three cited here.
Still a concern in 14w08a.
If birch and spruce leaves not being coloured by foliagecolor.png isn't a bug, how come leaves_birch.png and leaves_spruce.png aren't coloured in the first place?
It doesn't really make sense to use a greyscale image, allowing the game to recolour it dynamically, if the said colour is then hardcoded in the game.
This should be marked as unresolved and confirmed.
Still a concern in 14w08a. I am not, however, able to reproduce the behaviour described by @unknown.
Still a concern in 14w08a.
Also note that the characters cited here correspond to only three keyboard layouts, from only three language, and only for the numeric keys of the keyboard. It can almost be anything depending on that layout, and there is at least a dozen of layouts for every language, and the player is actually free to bind keys which aren't even amongst the numeric ones.
To put it simply, the game needs to support any possible character, not only ASCII ones.
I believe it works as intended. Minecarts carrying empty containers have less inertia than a minecart carrying a player. Empty minecart are the exception, slowing down faster to prevent them from going wild and forcing players to run after them at the first occasion.
It's seems unlikely since you're feeding the system with hoppers, but are you sure you're not providing items to that "filter" hopper faster than 2.5 items per seconds?
Could you provide a world save with that system? I made many sorter and they all worked well without skipping items like that. I'd like to see it happen to understand where is the problem.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
Still a concern in 14w08a.
I just tested this in many versions from 1.6.2 to 14w08a, with 200 chickens in a 1x1 pit. Not even one chicken died when growing up. Can someone who noticed the bug before can test it on a recent snapshot?