Leaderboard

It does exist Client side, but it is never saved there. If the player logs out, or the server restarts, the client's data will reset. If you want to reliably do things Client-Side, you will need to send packets from Server->Client with the data.

(Welcome!) You can use the PlayerEvent.BreakSpeed event to adjust the time taken to break a block. Also, you might be better off using HarvestDropsEvent to edit the drops from a block based on the harvesting tool. That way you don't have to cancel and re-do the block break itself, you can just alter the items being dropped.

PlayerTickEvent is fired for all players (even on the client side), not just the client player. If you want to do something every tick on the client, use ClientTickEvent.

Awesome Thanks! I'm still trying to wrap my head around why using a WeakReference is necessary though. So why I'm using a WeakReference variable in the entity rather than a StrongReference, such as, private EntityLivingBase caster; Is because of possible memory leak. Does this mean that even if the entity is setDead() and in World::updateEntities() , I believe this is where the entity is removed if Entity::isDead, the entity is removed but may not be set up so it can be GC'd? Another way to put this is, shouldn't any variables/references inside the entity, weak or strong, and the entity itself be set to be GC'd when it is removed?

For example: Imagine both player use the spell that holds the reference to the other. These two EntityPlayer objects now have hard references to each other. Both players then log out. The garbage collector comes along and sees that EntityPlayerA holds a reference to EntityPlayerB and EntityPlayerB holds a reference to EntityPlayerA. Both objects still reference the other and therefor cannot be GC'd without potentially breaking something, so GC leaves them alone. GC has no way to determine that this is a closed and isolated loop due to the space-time complexity of making that determination. See: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting Both players log back on again and repeat the process. Every time they do, it allocates two new EntityPlayer objects that can never be GC'd.

A WeakReference points to an object that can be collected by the GC. Storing the player object directly, even after the player logs out, keeps it in memory, when it is no longer required. As such, overuse of this practice can and will lead to "memory leaks".

You need to create a WorldGenerator object for your ore and call generate() on it - either construct an instance of a vanilla class (WorldGenMinable is used for most vanilla ores so could be fine for your purposes) - or make your own implementation for specific generation rules. Take a look at the vanilla WorldGen___ classes to see how they work (they're in net.minecraft.world.gen.feature)