Update README.inventory

Co-authored-by: David Leal <halfpacho@gmail.com>
This commit is contained in:
Oversword 2021-07-19 22:53:01 +01:00 committed by GitHub
parent 35d91c1f40
commit b22828ba68
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -54,7 +54,7 @@ overflow <itemstack> <count>
Tricky situation: Tricky situation:
if you have a blank spot and put say 82 torches down your pipeline, followed by 99 coal, the 82 torches will go in the chest, and the chest will see that 1 more torch can fit since that would only go to 83. Since 1 more torch can fit, no "full" message will fire off. Then when the coal hits the chest, the "fail" message will fire and the coal will bounce out. The chest couldn't predict that coal would be coming next, so it couldn't know that the chest is full, for coal, while not full for torches. if you have a blank spot and put say 82 torches down your pipeline, followed by 99 coal, the 82 torches will go in the chest, and the chest will see that 1 more torch can fit since that would only go to 83. Since 1 more torch can fit, no "full" message will fire off. Then when the coal hits the chest, the "fail" message will fire and the coal will bounce out. The chest couldn't predict that coal would be coming next, so it couldn't know that the chest is full, for coal, while not full for torches.
The inventory is also compatible with tubelib, which works in generally the same way as pipeworks, but transfers happen immediately and do not "bounce". This means that the messages should be identical to the messages sent by pipeworks, except that items will not be "lost". The inventory is also compatible with [`tubelib`](https://github.com/joe7575/techpack/tree/master/tubelib), which generally works in the same way as [`pipeworks`](https://gitlab.com/VanessaE/pipeworks) but transfers happen immediately and do not "bounce". This means that the messages should be identical to the messages sent by [`pipeworks`](https://gitlab.com/VanessaE/pipeworks), except that items will not be lost.
One oddity is that "take" messages will be asynchronous because, if an item does not fit in the chest, the event will need to be canceled. This means that it is possible (though highly unlikely) to recieve a "put" message into a slot which you have not yet recieved a "take" message for, there will not actually be two stacks in the same slot, though it may briefly appear that way until the "take" message is recieved. One oddity is that "take" messages will be asynchronous because, if an item does not fit in the chest, the event will need to be canceled. This means that it is possible (though highly unlikely) to recieve a "put" message into a slot which you have not yet recieved a "take" message for, there will not actually be two stacks in the same slot, though it may briefly appear that way until the "take" message is recieved.
TODO: TODO: