Description

The fix for the wireless terminal/cells no longer being "redrawn" from PR #2690 introduced a small issue when you scroll in your hotbar from it to an item that does not have any special handling or rendering.
For example to a block or torch. Scrolling to something like a tool or something else "breaks" the chain.
It will look like you're still holding the wireless terminal in your hand. When you go into third person it'll be the correct item, but revert to the wireless terminal when you go back to first person.

It extends to weird behaviour in which it looks like can place the tool.

Screenshot : https://i.imgur.com/7BndmAf.png
https://i.imgur.com/z2Ul9vc.png

As you can see in the screenshot the item doesn't even have to be in the hotbar any more for it to "work".
Scrolling to an empty hand will also "reset" it to the corect behaviour.

Screenshot of third person (showing the correct item) : http://i.imgur.com/VNG1J0C.png

Environment

• Minecraft Version: 1.10.2
• AE2 Version: a14cf22
• Forge Version: 12.18.3.2185

This is in a private selft-built modpack and haven't tested yet if it also happens with just AE in the pack.
I will append to the issue report when I've done that.

Apparently it does not happen when it's just AE2 in the pack. Looks like another mod is to blame.

The code in forge has even a big // FIXME above. So maybe it is even a forge or vanilla bug.

It only happened when I was in my base so it took some time to check every mod individually (damn loading times) but after I removed Blood Magic it seems the issue went along with it.
I'll crosspost this to the BM github as well.

I didn't have too much setup from the mod, only an altar (tier 5) and a well of suffering beneath it.

Looks like I was wrong. It was the permanent "Haste II" effect I had from a botania blood pendant.
In my completely "vanilla" AE2 test world (and clean pack) I made a beacon with haste II and had the same bug occured.

Haste 1 doesn't seem to trigger it, Haste 2 for whatever reason does.

I can reproduce it with a Haste II beacon. But it really looks like a bug with forge or vanilla and it not being able to detect that the selected slot has changed and thus not passing the correct condition to our handler.

All other implementations I have seen, actually compare the itemstack, so it might never been caught.
There is no reason to compare the whole item, if they also pass a slotChanged.

Thus closing for now (until there is a reason why it might not be a forge bug)