How Does The Mod Work
It is helpful to describe what the mod does in order to visualize what we can do with the API. This page will contain information on how the mod works.
The API is all wrapped in BossRushAPI namespace. This is to prevent any conflicts with other mods that may have the same class names. To easily access the code from the API, simply add using BossRushAPI; in a .cs file.
using BossRushAPI;
namespace MyMod;
public class MyModItem : ModItem
{
// ...
}The BossRushSystem is a class that inherits from tModLoader's ModSystem. It is the main class that handles the boss rush event. It is better treated as a singleton class. tModLoader handles the instantiation so it is not important to worry about it. To access the instance of the class, use BossRushSystem.Instance. There is also a shorter version for it: BossRushSystem.I.
The system relies on states. We have different states represented in byte. They determine how the system will behave.
| State | Description |
|---|---|
Off |
The system is off and not active. |
On |
The system is initializing. This is where bosses are actively inserted into a Queue<BossData> before commencing the boss rush event. |
Prepare |
The start phase of a stage. This phase is responsible mainly for spawning the next boss in the queue. |
Run |
Depicts that the system is currently running with players fighting the boss of a stage. In this phase, the system actively checks if players are all dead, bosses have despawned, or bosses are defeated properly. |
End |
Marks the end of the event. The system will clean and revert to initial values. |
Below is a state machine of how the states would change from one to another based on major events that can happen in the system.
The Boss Rush System has limited accessors. It only exposes readonly fields through properties to avoid direct manipulation of the system to prevent unforeseen issues. It has public methods to easily manage the system; the rest can be left to the inner workings of the system.
In that regard, the system is not really flexible to its inner workings. The flexibility the API highlights is more on the wide support for modded bosses which can be covered by BossData struct.
The mod is safely wrapped around proper accessors. However, nothing is impossible; if necessary, reflection can allow direct manipulation of the system. This is not recommended, though. If there is valid reason, then please raise an issue in the repository. It will be accounted for.
The API uses structs to store different kinds of data. The main struct that will be fed into the system is called BossData. It contains all the necessary information for the system to spawn a boss in each stage. One BossData can be treated to as one stage.
Inside BossData are more structs and other data types. Check the page about adding bosses in Boss Rush Event for more information about this.
The API is designed to work in multiplayer. The system only runs on the server. The server will send packets to the clients when the server's boss rush system changes states. This is to prevent desync issues. Even when only the server is runnng the boss rush system, the clients will still have the synchronized fields for checking; meaning, there is no need to use ModPacket for checking server variables. Client-sided code may also check the local boss rush system's fields and properties without issues.
It is important to note that this is not related to desync issues that may happen in certain boss fights, especially the modded ones. This is a different issue that is not related to the API. All vanilla bosses are by default multiplayer-compatible.