Try and fix distribution pipe hang#206
Conversation
| double horizontalRange = 16; | ||
| List<EntityWolf> list = world.getEntitiesWithinAABB(EntityWolf.class, new AxisAlignedBB(player.posX, player.posY, player.posZ, | ||
| player.posX + 1.0D, player.posY + 1.0D, player.posZ + 1.0D).grow(horizontalRange, 10.0D, horizontalRange)); | ||
| List<EntityWolf> list = world.getEntitiesWithinAABB(EntityWolf.class, new AxisAlignedBB(player.posX, player.posY + 1.0D, player.posZ, |
There was a problem hiding this comment.
Randomly noticed that this logic is slightly broken. If we want to create the bounding box centered on the player, then it should be initially created with size of 0 and centered on the player's coordinates.
|
Here's a build from this branch: additionalpipes-6.0.1.jar.zip |
|
Yeah, looks like it fixes the issue. Does seem to introduce a interesting bug/quirk. If the input is side is set (is not 0), but no other side is, or the side(s) connected are not set (is 0), it'll drop the items (Assuming this is intended behaviour). The bug/quirk happens if the input side is set, and the side(s) connected are also set. The item will try go back the input side, if it's that sides turn. Very minor thing, and if the input side is put as 0 then this never happens. But thought it worth mentioning. Other than that, looks good! |
|
So checked before the patch as I couldn't see what you changed to cause this, and it was already there. So I don't think this is a bug, and with a wooden transport pipe instead of gravity, the item goes back to the chest. I can imagine there'd be rare edge cases where this functionality would be wanted. Also this functionality can be turned off by setting input sides colour to 0. Can still fix if you'd prefer |
|
Ah yes this is intentional behavior, older versions of the mod also did this |
2 participants
This issue was very helpfully described by @Rishum-P here: #203 (comment)
I tried to reproduce it and I believe it's actually even easier to cause than described. You just need to have a distribution pipe with 0 values for all connected sides. Feeding items into that pipe is enough to cause an infinite loop and eventual crash (when running in singleplayer).
As I understand, this issue basically happens because toNextOpenSide() only tries all possible open sides once before giving up and returning. So if we are in a situation where no side is a valid destination for items, we will just get stuck in the while loop in splitStacks() forever and ever.
I added two different protections against this issue happening. First of all,
toNextOpenSide()now returns false if it cannot find a valid side, and in this situation we just set no specific destination for the item stack. This fixes the crash, and causes buildcraft to route the item stack randomly.However, I wanted un-routable items to be dropped on the ground, so I added a new
sideCheck()event handler which disallows items from going to any side that has a distribution amount of 0. This should only have one effect, which is to cause items to be dropped unless there is at least one connected side that has a distribution amount greater than 0.