Closed gentili closed 12 years ago
This is a good idea. Waiting for time (or angels) to implement.
Don't need a mapping table :)
Block.getDrops() can return an ItemStack of what would be dropped from the block, although tests I've run require that I pass it a tool that I broke the block with... so I created a Diamond Pick object for 3 lines of code and used that, and Coal Ore blocks gives me Coal, Lapis Ore blocks gives me several Lapis items :)
Alternatively lodge an event to break the block naturally, and when that event comes in, catch it and put the drops somewhere else, canceling the original drop list, while this is more complicated it does pass off the event to the bukkit system again and should operate "normally" based on whatever the event does regardless of how the game changes it, which I think is reasonable?
Ofc, theres nothing stopping the overwriting of the drops with a mapping table as well, allowing customization (or in fact preventing) certain drops because the Driver ground the items to dust while it worked :)
I like either of your suggested solutions better than a mapping table. Letting the bukkit code make the decision is a great idea.
Resolved in 124eba54a81fcb27ccb3555156626658d85b9ca6 through use of Block.getDrops()
During the drill phase, whatever blocks are sitting in front of the RailDriver simply get ejected from the rear dispensers as equivalent block items.
Instead, there needs to be some kind of translation table so that ore blocks produce the expected items (coal, redstone, etc...)