- Feature/api (#3777)
API Note this is a longer post, Orion.
Well here it is. After fixing my last attempt and completely redoing a lot of other things that came in contact with now moved abstract classes, we have a fully working API.
Features Full abstraction layer for almost all core functions of the mod: Citizens Jobs Buildings GuardTypes Entities Mobs (Separation between Archer / Melee / Chief, as well as Pirate / Barbarian) Most of the registries have been overhauled: Some registries have been turned into ForgeRegistries: Jobs (via JobEntries) Buildings (via BuildingEntries) GuardTypes (via IGuardType) Others have been completely rewritten to fulfill their specific needs: Mob AI PathNavigate ModelType DataManagers that take over part of the functionality the old registries performed and now mainly interact with the new registries to provide backwards compatibility. Complete removal of reflection. Replaced with the java Function lambda interface call, using the same parameters, but now much more flexible. Component description: Accessing the API components Before I start listing all the changes and how they effect us, I wanted to take a look at how to access the components. Virtually all components have a static getInstance()-method on their interface that can be used to access the components current implementation registered in the API.
This is done so that most people can use their existing learned names and keep on programming without a big shift. Examples are:
IColonyManager.getInstance() IBuildingRegistry.getInstance() These methods are of course just wrappers around their API container parts and are equivalent to: IMinecoloniesAPI.getInstance().getColonyManager() IMinecoloniesAPI.getInstance().getBuildingRegistry() A quick note on some of these endpoints (in particular the API endpoints which are IForgeRegistries): Some of these endpoints are defined by external sources, like forge. As such we are not able to ad...