Fighter

Fighter is a simple, alias based PVP system for Achaea. The Fighter Engine is of a simplistic design and only handles managing and automating pvp actions. It does not send actions to the game on your behalf. Your specific Class Engines will do this. This package consists of the Fighter engine itself and two additional scripts demonstrating how to create PVP systems for different classes. The requirements for each vary and are explained in further detail below.

Fighter Engine

Base Components

The Fighter Engine consists of all code in the aliases folder (automatFight, callAction) and the primary engine script (fighter.lua) under scripts. These components have no other plugin requirements. They only require Mudlet OR that gmcp data is exposed via a variable named gmcp. Even then, that sole requirement only comes up under the callAction script and is easy to remove if unwanted.

Example PVP Scripts

alchemist.lua and psion.lua are two example PVP scripts that demonstrate how to create a PVP decision engine that works with the Fighter Engine. These two example scripts are available for Legacy and Orion depending on which curing system you use. Additionally, this implementation relies on AK 8.5 and Romaen's Limb Tracker 1.3. Other versions of Romaen's Limb Tracker will probably work as long as they don't change how limb damage is accessed (IE: limbs[target].hits[limb]). AK on the other hand is a large, varied script and I can't guarantee any compatibility with other versions.

Additionally, each script demonstrates different use cases and implementations. Psion relies heavily on limb damage and shows how you might change your actions based on that. On the other hand, the alchemist example demonstrates how one might handle multiple balance timers.

Creating Your Own Class Engines

While I've included an example alchemist and psion class engine, you might not have the same priorities as me. You might also want to add other classes. It is easy to do so.

Step 1 - Write Your Class Engine

Create a new script with a name that helps you identify it. In that script, you will write your entire Class Engine. This file is responsible for deciding what actions to take, managing affliction reporting, sending the commands to the game, storing and managing data specific to the classes implementation, and managing any created temporary objects such as timers, triggers or aliases. Your Class Engine has to follow four rules but can otherwise be written however you want.

1. You must have a decideAction() function. decideAction() is the primary function called by the Fighter Engine to generate a pvp command string.

2. You must have an isReady() function. isReady() is responsible for making automation work. The isReady function should determine when a new action should be taken and then kill the temporary event handler spawned by decideAction and recall decideAction to generate a new command.

3. When designing your Class Engine, enclose everything in a single table which will act like a class. You can see an example of this in both example scripts where functions are held within a table. This makes it easier for Fighter to manipulate the implementations and call the Class Engines.

4. Every Class Engine should be written in such a way that when fighter.Setup() is called it is able to rebuild itself. fighter.Setup() is designed as a basic hot reload function and will recreate Fighter and all sub-components each time. This allows you to force Mudlet to update any changes you make to the Fighter Engine or Class Engines.

Step 2 - Add it to fighter.lua

Open up fighter.lua and at the top you'll see two tables that we need to modify slightly for your new Class Engine to work.

This table is responsible for noting which Class Engines are available for us to use. This is an important distinction as you can have a Class Engine listed under implementations for testing, but leave it out of implemented so Fighter won't call it during PVP.

fighter.classes.implemented = {
    "Psion",
    "Alchemist"
}

This table is responsible for holding references to each Class Engine. The names on the left should be the same as the class name reported by gmcp.Char.Status.class since that is the variable used to pull the implementation. The Fighter Engine works by calling these references to reach the functions and data contained within. Please note that there are no quotes here. This syntax is not an error. This is how lua defines tables with named keys instead of standard indexes.

fighter.classes.implementations = {
    Psion = psion,
    Alchemist = alchemist
}

Step 3 - Profit

That's it. You've added your custom Class Engine. Now when you type fight (the default alias to call the next action) while switched to this new class, Fighter will automatically call the decideAction() function under the correct Class Engine for you.