gistfile1.txt

<nallar> Will just make onDestroy(Block block) final so it can't be accidentally overriden, and have it call onDestroy(block, 1.0).
* Darsstar1 has quit (Quit: Leaving.)
<nallar> Zidane, does it need to be called VanillaBlockChangeEvent? Can't it just be called BlockChangeEvent since it's in a different package. Not sure if that's confusing.
<Zidane> BlockChangeEvent is API
<Zidane> it would be confusing
<nallar> Zidane: https://github.com/VanillaDev/Vanilla/pull/220
<Zidane> erm nallar...blockchangeevent isn't just block breaking
<Zidane> if a dirt becomes grass...that is block change
<Zidane> You need to provide an appropriate source
<nallar> Which is done when the event is used? new VanillaBlockChangeEvent(block, new BlockSnapshot(block, this, getData()), block.getSource(), drops);
<Zidane> source would be a player...
<Zidane> thats it
<nallar> That's already there.
<Zidane> You aren't getting the point...if I use a bonemeal on a sapling that is a BlockChangeEvent
<Zidane> ...yet I provide drops for this event if in Vanilla:S?
<nallar> That's why I wanted a BlockBreakEvent.
<nallar> You said no...
<nallar> "<Zidane> You mean VanillaBlockChangeEvent :P"
<Zidane> Also...you didn't compile your PR...
<nallar> f5 and that's fixed.
<Zidane> nallar: The point I was trying to prove to you above is...
<Zidane> Do what we do for HealthChangeEvent
<Zidane> provide a custom reason
<Zidane> that extends Source
<nallar> Ok.
<Zidane> BlockChangeReason.PLAYER_BREAK
<nallar> But then BlockChangeReason.PLAYER_BREAK needs a get/set drops method, so BlockChangeReason can't be an enum?
<Zidane> :/
<nallar> Where does setting/getting the drops fit in here
<Zidane> I am having trouble establishing that
* B3NW is now known as B3NW|OFFLINE
* B3NW|OFFLINE is now known as B3NW
<nallar> Zidane, could dropping be made a separate event?
<Zidane> I have come to the realization that this would be the best approach
<nallar> https://github.com/VanillaDev/Vanilla/pull/220 - I removed the event stuff since the rest was fine
<Zidane> I don't think Bukkit has a drop event
<Zidane> Which would fix their issue
<Zidane> as well
<Zidane> I believe
<Zidane> I got it nallar...
<Zidane> DropItemEvent...takes a source
<Zidane> if block is source...block broke
<Zidane> if player is source...player dropped item
<Zidane> perfect?
<nallar> It means that you need to handle multiple events to cancel dropping if there are multiple drops.
<nallar> DropItemsEvent?
<Zidane> DropItemEvent could be multiple drops :p
<Zidane> doesn't need to be *Items*
<Zidane> tl;dr make DropItemEvent handle an array of drops
<nallar> DropItemReasons.BLOCK_BREAK?
<Zidane> hmm...I was gonna say pass in block.getSource() but that would be a player when the block breaks wouldn't it :p
<nallar> Could a source have a source?
<Zidane> ItemDropEvent(Source dropper, Source reason, ItemStack[] drops)?
<Zidane> Who dropped it...for what reason...list of drops
<nallar> But what if it wasn't dropped by a player?
<Zidane> Who could mean anything
<Zidane> not just players
<Zidane> Like...
<Zidane> I could pass in....
<Zidane> (block, block, is)...block dropped it...the reason was the block...and is is my array
<Zidane> but then again that seems...odd
<nallar> the Source reason isn't really being used as a source here.
<Zidane> that above would mean that the block dropped them item and it was the reason for the drop
<Zidane> so I agree nallar...lets change to...
<Zidane> ItemDropEvent(Source dropper, ItemDropReason reason, ItemStack[] drops);
<Zidane> sound good?
<nallar> Why not make a thread in Developer Ramblings for more input? Getting events right is important.
<nallar> I would make one, but I don't have permissions.
<Zidane> Sure, make the thread and link irc log