Open corylulu opened 4 years ago
I also thought about this idea. Should be fairly easy because I am calling the onInventoryMoveEvent() after adding the items to the new chest. I will implement it and make it toggleable in the config.yml.
basic implementation is now ready. There is one big flaw though: You can create a loop which results in a server crash! This bug has to fixed before a release version can be published. This is unfortunately not easily fixable.
This could either be made optional for those who might consider this kinda cheating, or a parameter could be added to require Receivers be within X amount of blocks of the Sender.
This whole plugin is kind of cheating to be honest. Maybe I will add a costly crafting recipe and some kind of wear to the item.
basic implementation is now ready. There is one big flaw though: You can create a loop which results in a server crash! This bug has to fixed before a release version can be published. This is unfortunately not easily fixable.
If it's possible to get a list of all the sender and receiver chests in a chain when a new sender/receiever chest is made for example:
A sends to B and C C sends to B B sends to D
Player tries to make D send to C (which would create infinite loop D -> C -> B -> D ... The check returns the list of the entire sender/receiver chain for C, which includes the chains for its chains
-> A (sends to here)
-> B (receives from here)
-> A (sends to the above B)
-> D (receives from the above B)
Since D exists in this list, the creation should be disallowed. Though this would require storing that list somewhere or creating an evaluator for it.
basic implementation is now ready. There is one big flaw though: You can create a loop which results in a server crash! This bug has to fixed before a release version can be published. This is unfortunately not easily fixable.
If it's possible to get a list of all the sender and receiver chests in a chain when a new sender/receiever chest is made for example:
A sends to B and C C sends to B B sends to D
Player tries to make D send to C (which would create infinite loop D -> C -> B -> D ... The check returns the list of the entire sender/receiver chain for C, which includes the chains for its chains
-> A (sends to here) -> B (receives from here) -> A (sends to the above B) -> D (receives from the above B)
Since D exists in this list, the creation should be disallowed. Though this would require storing that list somewhere or creating an evaluator for it.
Yes of course. But getting that list is not as trivial as you think. B does not know it is receiving items from C using the current data structure. Getting all the children is not the problem, but the parents. To implement this nicely you would have to use a data structure fitting graphs better than the current. Another option would be to implement some kind of backlinks (which chests are pointing towards me?). And searching up (through the parents) and down (through the children).
Feel free to implement one of the solutions or one of your own. I'd be happy to merge :D
Relevant
Would be nice to allow the ability to daisy chain chests together so you can have a Sender chest send to a remove Sender chest and then sorted into that Sender's Receiver chests.
This could either be made optional for those who might consider this kinda cheating, or a parameter could be added to require Receivers be within X amount of blocks of the Sender.