Using the EventAPI

EventAPI - additional events.

List of additional events

The current list of additional events:

• PVPEvent - when two players engage in PvP
• ExplodeEvent - when something explodes
• VillagerHealEvent - when a player heals a resident
• WorldInteractEvent - when a player interacts with the world
• WorldSelfDestructEvent - when the world tries to self-destruct (under someone else's influence)
• BlockClickEvent - when the player clicks on a block

And the less important ones:

• AncapHeartbeatEvent - called every second
• FastTimerTenSecondsEvent
• FastTimerTenMinutesEvent

CommandAPI Event:

• IncorrectArgsEvent
• NotEnoughArgsEvent
• NotEnoughPermsEvent
• UnknownCommandEvent

Usage

AncapFramework's optional inventions can be used for a variety of purposes, but here are the main uses:

Use for code reduction

Many of the inventions generalize to a large number of specific Bukkit inventions. For example, WorldInteractEvent summarizes about 20 player interaction with the world. Using AncapFramework's EventEvent allows you to handle only 1 event instead of 20.

Using as a bridge between plugins to achieve less cohesion between individual plugins

The use of generalized inevents allows plugins to communicate only with the AncapFramework, without communicating with each other or knowing anything about each other at all.

Suppose the following situation: you have a privates plugin, and a ships plugin. The privates plugin allows players to defend their territory, and the ships plugin allows players to build ships. The privates plugin knows nothing about the ships plugin, and the ships plugin knows nothing about the privates plugin.

If both of these plugins work with Bukkit API, then the following problem could arise - you can create ships from the second plugin inside territories protected by the first plugin, because the first plugin does not know about creating ships and cannot restrict it. The solution to this problem would be to add to the first plugin an additional listener specifically for creating ships from the second plugin. However, this solution is obviously not the best - after all, you can't foresee everything. Especially hell begins in real life - when the number of plugins on the server alone can be in the hundreds, and there are millions of them written.

However, if both plugins worked with Event API (plugin for ships threw WorldInteractEvent by itself, and plugin for privates listened to it) - there wouldn't be such a problem. This is the advantage of low connectivity, achieved by bridging in the form of events.