Module

A **module** is a data pack which hooks into the Nexus infrastructure through special function tags and the version verification system. It can be something as simple as a couple basic functions to something as elaborate as akin to a large mod pack. A module is also how a user interacts with the Nexus infrastructure and uses it. An arbitrary number of modules can hook into the Nexus simultaneously, and if they are designed properly, will offer no compatibility issues.

## Setting up a module

### Types of modules

Four broad categories of modules exist depending on how they are implemented and what they contain.

* *Lite modules* integrate themselves very loosely. They don't necessarily use version verification and reference functions and function tags somewhat liberally. These are acceptable for maps and for private use but should not be distributed as standalone data packs.
* *Proper modules* integrate themselves properly with the version verification system and don't cause compatibility issues with other modules, and even other data packs outside the Nexus.
* *Complete modules* follow the internal standards throughout as laid out by the Template Module.
* *Library modules* add advanced functionality directly to the Nexus namespace. They would otherwise be included in the Nexus directly but were excluded from it due to size.

### Namespaces

All proper modules have 3 namespaces:

* `minecraft`
* `nexus`
* `<module>`

Each namespace serves a certain purpose: the `minecraft` namespace contains the tick and load function tags; the `nexus` namespace contains the function tags and entity tags which your module hooks into; and the `<module>` namespace is where your module's custom code will go and can be called anything you desire (e.g. `temp`).

### Version verification

To ensure that your module is using the correct version of the Nexus, and to ensure that duplicates of a module are not active simultaneously, a version verification system is used. When the Nexus is loaded, it will run the function `nexus:verify/main` which is contained in the Nexus and every module. This function runs two function tags which reference functions in the module in order to list every data pack which is loaded and check that the proper set of data packs are loaded. If any dependencies are missing or if any duplicates exist, it will throw an error and will not let the Nexus install.

The Nexus verification system must follow a strict blueprint in order to be a proper module as there cannot be any collisions with the function files.

### Module ID

Each module is assigned a 4-digit module ID which is used in various places:

* Custom model data in resource packs, making each model reference unique and avoid collisions between modules. 6 digits are used, the first 4 are the ID and the last 2 are the model within the module.
* Custom death messages use the module ID to have a unique value for every possible damage source, with the first 4 digits representing the module from which that damage was caused.
* Function trees use them to determine which module to execute functions from when it reaches the end.

The list of taken module IDs can be found here.

### Function tags

Various function tags are used by the Nexus which execute at certain times and events. This is the primary way to hook your module into the Nexus pipeline. They range from player login events and entity ticking functions to more elaborate events such as advancement triggers and function tree execution.

### Entity tags

The Nexus classifies entities into tags as well with special tags reserved for things like ticking entities, damage sensors, vehicles, etc. A module can add entities to these tags for their various needs.

## Function categories

There are a number of broad categories of functions and features used for various purposes in Nexus modules.

### Setup

The setup functions install the module by adding all the scoreboard objectives, teams, and bossbars etc., and assigning all the constants. They also configure the feature booleans to activate certain features that the Nexus uses. Additionally, the installation function will only run once until the *last modified* parameter is updated, signaling that there were changes to module installation.

### Player

The player functions execute as all players every tick. The root player function in the Nexus handles ID assignment, detecting logins, vehicle management, respawn detection, health management, among other things. Within modules, the player functions can run arbitrary functions as the player for the purposes of the module.

### Generic

Generic functions usually implement some algorithm or mathematical formula for general-purpose use across the Nexus or a module. The Nexus has its own set, and a module can have a set as well. Certain functions in the Nexus pass execution back off to the module like the function tree system. These functions are generally placed in the `generic` folder.

### Entity

The entity system uses a ticking entity, which is under the `#nexus:generic/system` entity tag, and which has one of the ticking tags (e.g. `nexus.entity.ticking`). They are sorted by the module they belong to (e.g. `temp.entity`) as well as the type of entity they are (e.g. `temp.entity.type.spider_brain`). Generally the root entity will run its respective function every tick, but will actually slow down the tick rate to preserve server TPS. This is done with the time manager system. A custom entity may use multiple entities (e.g. a marker, some area effect clouds, some armor stands, a pig as a damage sensor, etc.), each of which sharing an ID on the `nexus.id` scoreboard objective. The root entity executes the function, and the child entities are linked to it. During execution, if the entity has IDs enabled, all entities in the rig will be given the tag `nexus.entity.target` so that they may be referenced at arbitrary points in the function and used by the entity.

What an entity does once it executes the functions in the module is completely arbitrary, but there is a standard format using modes, animations, and assembly as outlined by the Template Module.

### Object

Objects are similar to entities except instead of ticking perpetually until termination, they are designed to process a definite amount of information before termination, and only one object is allowed to tick at once, allowing them to use fakeplayer values without collision with other objects. Also unlike entities, which are designed to take as little time as possible to tick, an object will take as much time in a tick as it possibly can (without going over 50 milliseconds) so that it will complete its operations in as few ticks as possible. An example of an object might be a Perlin noise chunk generator.

### Tick

The tick functions simply run every tick and perform generic tasks for the modules. They run near the end of the tick after entities, objects, and chunks process.

### Uninstall

At any point, the user can uninstall a module or the Nexus and all the modules at once. Uninstalling a module will remove all scoreboard objectives, teams, bossbars, etc. as well as any tags on players and entities. It will also terminate all entities belonging to that module.

## The Template Module

The Template Module implements a handful of random features to demonstrate how to implement various mechanics intended to be reverse engineered. The Template Module follows the internal Nexus standard for organization and formatting, and can be modified in any way the user desires for the purposes of experimentation.

## Creating modules automatically

The Module Manager can be used to create blank module templates automatically, complete with version verification and feature assignments.