So priority takes an important role, I haven't seen anyone on the pmmp forums talk about priorities, I've only seen threads that include it in their code but no explanation, but some people may not understand what it is, the purpose of this thread is to explain such matters. I've gathered some information to assist all of you guys. When you register events in PMMP, you can assign it a priority. Most people use Priority NORMAL without knowing because that's the default priority until you define it, and that just makes sense, right? Normal's normal. Until you think about other plugins. There are 6 priorities in PMMP (Just like Bukkit/Spigot) Those are: Highest High Normal Low Lowest Monitor They're actually called in this order: Lowest low Normal High Highest Monitor They look sane, right? Except for that obvious bolded "Monitor" one which just sticks out. Not just because it's bold. Really. I'll get to that in a second. The theory behind this system is, every plugin gets a say in what happens, and every plugin must get a chance to know the outcome of an event. So, we pass events to plugins even after they've been canceled. A plugin can actually uncanceled an event after another plugin canceled it. This is where priorities become really important. Let's say a BLOCK_PLACE event is being handled. The lowest priority listener is called to get its say in whether it should be canceled or not. Then the low priority listener is called to see if it wants to override the low, etc. Eventually, it hits monitor, and at this point, nothing should change the outcome of the event. The monitor should be used to see the outcome of an event, without changing any aspect of it. If we have three plugins enabled; one is a basic area protection plugin, one is a fancy plugin using signs, and another is a logging plugin. The protection plugin listens on Priority::LOWEST. It says they can't place blocks in this area and cancels the event. The fancy sign plugin listens on Priority::NORMAL. It says they can place signs here, and un cancels the event. The log plugin listens on Priority::MONITOR. It seems that the event was actually allowed, and logs it. If you want to choose a priority for an event just add this just before it (replace <PRIORITY> with priority name): Code: /** * @priority <PRIORITY> */ Basically, if you want to change the outcome of an event, choose very carefully from LOWEST to HIGHEST. I'd suggest generalized protection plugins on lowest, more specific plugins on normal, and override plugins on high. If you want to act when an event happens, but not change the outcome, use monitor. It's really really important that you use the monitor, or an event might get canceled after you've acted from it, and it's even more important that you don't change the outcome of the event on the monitor or it'll break other plugins. I could explain this better, but I'm hoping you'll get the idea. Any questions or comments?