Immersiveengineering: (0.10-52) Splitter Conveyors missing one split under certain circumstances

[ConKuk]

* EDIT: See video at bottom

Issue: Under certain circumstances the items will only move in one direction on a splitter conveyor.

Noticed this first when using Direwolf20's 1.10.2 pack ( version 1.1.3 ), which contains 0.10-52 version of IE. forge 12.18.2.2171), but has a bunch of other mods.

Later tested this with fresh minecraft 1.10.2:

• Forge 12.18.3.2185
• IE 0.10-52
• SuperCircuitMaker 1.0.4 ( Just for the timer, not that good with vanilla to make timer :P )

=== The same result!

The following description concerns a branching pattern as follow:

The timer is timed so nothing will stack on the belts. even bumped to 30 ticks for these tests!
When 'precisely inserting' ( this is an important detail) items into a conveyor belt ( For example if using a hopper ), on the second split counting from the point of insertion one of the split conveyors always routes the item one way.
( Marked on the picture above )

See result of item splitting:

On the right side it goes as expected: 32, 16, 8, 4, 2...
but on the left it skips one and goes 0, 32, 16, 8.

I tried NS, SN, EW and WE directions, the only thing different is that in two occasions its the right branch and on the other 2 its the left,

Pic includes the Axis widget from F3 screen. (Unfortunately there is no ortho view in minecraft so its perspective).

Every split of the 4 looks like this, just in different direction:

There seems to be some correlation to direction of movement after FIRST split, since its always happens when the item first split to +x or +z and than had to split in opposite ( -x, -z ) direction.

Interestingly, if dropping item from vanilla dropper ( the one that spits in random directions , i.e not precise [Made a chute with glass to make sure it doesn't miss the conveyor]), than all branches work BUT it breaks the routing left/right consistency, see picture:

Its no longer binary.

Hope I didn't miss anything...

I wanted to make an autocrafting system where I order some plates and that number drops on input and splits to 4 presses, noticed that only 3 are getting ingots.....

VIDEO:
https://www.youtube.com/watch?v=9Qt4KkltfNQ

[BluSunrize]

If items stack, the splitting breaks. I can't do anything about it. Transport needs to be a bit slower, otherwise the autostacking will fudge it up.

[ConKuk]

As I stated:::::

The timer is timed so nothing will stack on the belts. even bumped to 30 ticks for these tests!

So this has nothing to do with stacking.

[BluSunrize]

Right, sorry, I must have missed that then. I'll look into it.

[ConKuk]

Items not splitting correctly was the SECOND ( and secondary ) issue I mentioned, and it is not such a big one.
The problem is the FIRST issue, when NOTHING gets sent to one of the forks.

Thank you for the reply.

I tried looking at the code, but its been so many version of minecraft since I last delved into modding that I just couldn't figure anything out :/

[ConKuk]

Right, sorry, I must have missed that then. I'll look into it.

Sorry if I came as harsh and I understand your frustration, and the reason for your first reply.
As Developer myself, I know you have to deal with people that just rush to post something that they think you HAVE to fix, without thinking first.

I only ask that you read the whole post and share your thoughts if possible, I'm also interested in to why this bug might happen. ( From code logic point of view )
Speaking of course of the bug where it misses one branch entirely and why it only happens if the item was inserted to the belt and not when dropped randomly.

[ConKuk]

Added a video to the OP

[BluSunrize]

Right so what I figured out in testing, the NBT data used to store an entities direction isn't cleared properly on certain occasions. This clearance is based on the distance of the entity from the next block it's moving into, but I find myself unable to find a distance that works, because either one conveyor has it offset a tiny bit more on its last tick, which makes it not delete the data, or it has anther tick after clearing which makes it reapply the data with a flipped side.
The results are that either, for case one, the faulty conveyor then determines the output direction of all other conveyors to follow, or for case 2, it flips at the last possible moment and shoots it out the other side.

Since neither of these options are satisfactory, I've come up with a solution that not only writes the direction to NBT but also appends the block's position (hashcode of the BlockPos, written in hexadecimal) to the key of the NBT data. That means that every conveyor adds a unique entry to the entities NBT, so it extends the size of hteir NBT data slightly, but it also remedies the issue.
Plus, it seems to be 1 or 2 in 10 conveyors that have this issue, so at maximum, it adds two extra NBT tags.
Also, note that these are added to the entity and are wiped as the Entity is removed, so when you pick it up or store it in a chest. This is not the NBT of the ItemStack, so it will not persist on the actual item itself.

Commit to fix this is coming later today along with a release.

[ConKuk]

Thank you for sharing your debug and solution process.

Than I guess that this happened constantly when using 'precise' insertion because this kind of insertion always lays the items on a precise tick timing. so the entity was always getting its direction not deleted before it went to the next conveyor.
It actually explains another thing that would occasionally happen, where it looked like items randomly decided at the last moment to switch direction, I thought it was just a sync issue for my server...