Mikeware

Agree would see the interaction of hoppers with the chiseled bookshelf as a stack and not a queue, The books placed in the initial slots shouldn't change as things are pulled in/out. i.e. the last book placed in should be the first one out so order is maintained.

I still think it's odd that adding/removing from the same slot outputs the same signal. Since there's only 6 slots and 15 possible redstone signals, there's a lot of possibilities here. I still think it'd be interesting to have different strength signals for adding vs. removing from a slot. For instance 1-6 being added to that slot last, 7-12 removed from that slot last, or 1 & 2 being added/removed for slot 1, signal-strength 3 & 4 added/removed for slot 2, etc...

Yeah, I could see knowing the last slot interacted with being interesting if you could interact with specific slots and add/remove books from any position. I was hoping that was the case when it was first announced. It certainly makes for more interesting decoration options and puzzle possibilities that way.

As is, it seems really hard to be useful for anything Redstone related as the same action of adding/removing a book from the first and last slots results in the same result.

I think it'd work better if you could interact with individual slots to add or remove the specific books from any of the 6 specific positions. Then have Redstone outputs of 1-6 and 7-12 to represent book added and book removed respectively (or 1-2 be add/remove for slot 1, 3-4 be add/remove for slot 2, etc...). This way you could track a sequence of steps with some RSNOR latches, and AND gates to detect a sequence like 3, 8, 4 meaning book added to slot 3, book removed from slot 2, and book added to slot 4, and reset the latches on any other inputs. Similar to existing combination lock systems today that use item frames.

Pulling out and detecting add vs. remove would help in puzzle/escape room options as well, especially as needing to take a specific book out means that the specific books could contain the instructions needed for the next piece of the puzzle. Since the books could have different instructions, pulling out the specific one needed from the shelf as dictated by an earlier puzzle clue is an interesting addition.

If it remains that you have to put the books in and take them out in order, then it should probably work like all the other containers and just output the signal strength of how many items it contains.

Otherwise, if we can pull books out in any order based on which slot we're looking at, then it'd be cool to have a different system to detect more complex interactions. Default would probably be 0 for when it's empty, but I don't think once books are added it'd ever go back. As if you remove the last book, you want the specific signal strength to detect which slot that book was removed from and not that it's empty again. Unless the bookshelf outputs the specific signal strength and then after a few ticks goes back to zero if the shelf is empty. (Not sure if knowing the shelf is completely full with a strength of 13 in a similar fashion would be useful, but a possibility as well, but again after an initial delay of knowing the signal strength of the specific slot where a book was added.)

Related to this bug for Java edition here: MC-256486

There's a bit more discussion over there, but agree that this is really bizarre and makes it difficult to be useful as you can't detect a change to the first/last slots. Knowing the last interacted book would only be interesting if you could interact with individual slots.

Thanks @NeunEinser, but I would hope the new functionality of the honey block would have removed the need for a Minecart in a flying machine, as they can be bumped off the flying machine by the player.  Since one of the features of the honey block is that entities stick to them, it'd be nice to see this work still with a spike.

I've seen this occur without a server involved too just on local single player too, so there is some sort of desync happening somewhere.

Thanks violine, I had searched, but didn't think of the transparent block connection, just had searched for slime and transparent, so that other one didn't come up.  I posted my screenshot of the Minecart in that thread on the main bug.

Seen here with Minecart as well on top of a slime block.

I can confirm I've experienced this in 19w42a as well.  If you use amplified terrain generation to peg the GPU, you'll exacerbate the issue.

You can see this occur on the stream I did last night here just after 3:09:36: https://www.twitch.tv/videos/495712598?t=03h09m36s

Everything is fine until about 3:09:51 when everything freezes for a second and the flying machine I'm on pauses.  When the lag spike ends, the machine goes 'double-time' to catch-up to where it should be, and I'm left behind.  I'd expect the accelerated updates from the lag to still move me along as I would have been when no lag had occurred.

Seemed to happen to me on 1 out of every 3-4 trips or so, but I didn't notice it as much in my original flat testing world, so definitely a CPU/GPU bound sort of issue with the lag, which was more prevalent here in amplified, but seems like it'd be a good indicator that this problem could arise in multi-player as well.  In my case I was just playing single player on my own machine.

I was only able to get custom recipes working in the 1.14 beta AND by turning on experimental features (in single player).  Otherwise they seemed to be ignored.

Nathan, this can be expected based on how portals work: https://minecraft.gamepedia.com/Nether_portal

Can you provide more details on your particular issue if it's something different?

Thanks for updating the version. I don't think it has as much to do with chunk loading as rendering. Because you'll hear the mob still, so it knows it's there, you just can't see it.

I tested this out in multiplayer too. On your own machine, you get stuck and the horse is invisible. But if you see someone do it, you'll still see them on the horse (though sometimes it takes a bit or you have to look around a bit, probably related to MC-65040). Of course, since they're stuck, you won't see them moving.

Leads me to believe it's a local-client issue as if another player sees things properly then the server must have the proper info.

I just hit the horse teleport bug MC-44514, it seems like the two would be related?

After teleporting a mob 100 blocks (assuming it's probably 80 like I saw with the horse), I see this.

F3+A did not reload the mob for me, I had to relog or move around a bit to get it to appear.

Render Distance at 32 chunks.

Tested the Y direction, works fine.

Also tried teleporting other mobs long distances and discovered that they disappear too! At least until the player moves/looks around a bit. For instance if I teleport a Spider Jockey 100 blocks away into the daylight near my position now, I'll hear him burning, but until I move a bit, I won't see him.

Seems like another bug or maybe related to this same issue? Maybe related to MC-65040

It also appears that the horse teleports visually before the player does, I see the horse for a brief instance in the distance before I move, but then the horse is invisible.

As a player, you're stuck on the horse and get snapped back to its location if you try and move. You can dismount, but the horse is still invisible.

It looks like in 14w10c (the same issue occurs at the same distances) that if I dismount the horse and move a couple blocks away the horse reappears, this is not the case in 1.8.3.

Duplicate of MC-44514.

It seems there's a certain distance that triggers it for me it was about 80/81 blocks depending on +/- in X or Z dimension.

Pretty annoying as I was making a teleporter to let me ride horses through it. Thought it was going to work fine until I increased the distance and hit this bug.

I see this as well in 1.8.3, it occurs if you teleport the horse too far while riding it:

/tp @e[type=EntityHorse] ~81 ~ ~
OR
/tp @e[type=EntityHorse] ~-80 ~ ~

Anything less than those distances works fine as intended.

After teleporting, you can move but slowly and you'll hear your horse but it is invisible and you'll be back at ground level. If you dismount, you can move fine, but your horse will be invisible until unknown conditions occur (or relogging). Staying on the horse and relogging shows you fine on the horse.

I was bashing my head around for a while trying to figure out why it wasn't working right. Certainly would be nice to see in the future at some point.

Is this a duplicate of another issue?

I was trying to use fill replace to get rid of a chest for my map, but that doesn't work either.

Pascal, that's the problem though. Players should be ejected at different spots as well. You don't want to have to change the design of your build based on what direction you build it in the world, but in relation to the tracks you're building it on.

I'll have to look at the screenshot and try with mobs, but ideally everything should just eject the same way based on the direction of track/movement and not the orientation in the world.

This is related to MC-51987. Ideally all entities players or mobs should eject based on the direction of travel. When you make contraptions, you don't want to have to think about the direction it's oriented in relation to the world in order to tweak the design. You want to have the same design for the build based on the orientation of the rails (direction of travel). This would let you memorize the pattern to build it once and apply it wherever and in whatever direction you choose without worry.

Stumbled upon a video demonstrating this bug here: https://www.youtube.com/watch?v=iq2Rg_SAOGQ

According to the video's creator it occurs on chunk boundaries. You can see him demonstrate the glitch with the item frame entity and mobs.