Skip to content

Platform Implementations

Daniel V edited this page Jun 13, 2023 · 3 revisions

Platform Implementations

In this section, we'll go over what exactly goes into platform implementations. Believe it or not, it's more than just "Please add support for ."

Library Requirements

Beyond the internal TNE classes that need to have platform-specific implementations, there are a few libraries that need to have support added too.

The New Item Library

This library handles all the platform-specific item-based actions, such as item comparisons, and inventory actions, such as item adding/removal.

URL: https://github.com/TheNewEconomy/TheNewItemLibrary

The New Menu Library

This library handles all the menus inside TNE. If it's in TNE and it's a menu, it goes through this library.

URL: https://github.com/TheNewEconomy/TNML

Lamp

This library handles the commands for TNE.

URL: https://github.com/Revxrsal/Lamp

Adventure

This handles all the cool message functionality in TNE.

URL: https://github.com/KyoriPowered/adventure-platform

Events

In TNE, events are all handled internally through the handlers package. The only thing that we need to do on the platform side is to add the event listener and send each TNE handler the proper parameters, which vary depending on the handler.

Events

Since all platforms name their events differently, I'm just going to write out what the handler does, and then you may piece the pieces together with each platform.

Please note: This list may change as features are added to the core of TNE.

  • Entity Dropping Experience(usually on death)
  • Entity Dropping Item(usually on death)
  • Player closes their ender chest
  • Player Joins the server
  • Player leaves the server
  • A region/world is loaded

Commands

Commands go through the Lamp library. This is a place that is ever-changing since I can't make up my mind on what library to use. This has gone from a custom library to ACF to Lamp. Check back in case this changes again. The only real additions here will be to implement Lamp's platform-specific actor, TNE's CMDSource class(which will probably be going away in the near future), and add the Lamp command handler to the platform Core file.

Scheduling

TNE uses a custom internal scheduling class. This requires two implementation classes.

Chore<?>

The Chore class is a class that is essentially the equivalent of a platform's Task class. The parameter is the platform's Task class equivalent.

Scheduler<?>

The Scheduler is the class that will handle scheduling each Chore. The parameter, in this instance, is the platform's Chore class.

Inventory Classes

Thanks to item currencies, TNE has to add support for each platform's inventory system. Beyond TNIL, we have two classes responsible for the core of this.

Item Calculations<?>

This class extends the ItemCalcuations class and has a parameter, which should be the platform's inventory object. You won't usually need to override any methods in this class, but it's included just in case.

InventoryProvider

Due to the intertwining of TNML, this class extends the Inventory Object from the library, as well as implements the InventoryProvider class from TNE's Core. This helps reduce redundancy. This class will really only need to override the getInventory(boolean ender) method. Everything else comes from the TNML Platform class.

LogProvider

This is just a class to implement the TNE logger for each platform. Nothing exciting here, but it's a requirement.

CMDSource

The class that will probably cease to exist soon. This class just acts as a bridge for a command source. It takes a Lamp Actor class as the parameter.

PlayerProvider

This class is used to handle all methods that need to access the platform's player object. This includes online checks, location searches, messaging, and experience-based methods.

ServerProvider

This class points to the various classes and provides miscellaneous utility methods such as replacing message colors, registering crafting, and finding players by UUID.

TNECore

This is the brain of everything. This is where you'll need to initialize your listeners and register your commands. This can be the same class as your main plugin class for each platform or a separate one.