minetest-mods/digilines
1
0
Fork 1
mirror of https://github.com/minetest-mods/digilines.git synced 2025-06-30 07:20:29 +02:00
Code Issues Releases Wiki Activity

Send messages from digiline chest when items are moved with tubelib (#73)

Browse Source 
Sends the same events from tubelib interaction as would be sent from pipeworks

 * Moved the tube_can_insert and tube_insert_object callbacks out of the node definition so they can be re-used in the tubelib registration
 * Optionally required tubelib and registered callbacks for pushing and pulling
 * Used "speculative pull" variable to only send a "take" event if tubelib's unpull is not called after a pull - this happens when it tries to take an item but there is no room, so it fails
This commit is contained in:
Oversword
2021-07-21 14:07:15 +01:00
committed by GitHub
parent a055b5045a
commit f03cd02854
4 changed files with 191 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
README.inventory
View File

@ -54,6 +54,9 @@ overflow <itemstack> <count>
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.
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 send the "lost" message when they cannot fit.
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:
- make chest.lua a mixin that gets both default and locked chests
- digiline aware furnaces